‘Build’ and ‘buy’ options are not mutually exclusive. Many companies operate well by both developing their own software when desired and buying in pieces of tech when needed. The bigger your company is, the more choice you have.
The strategic reasons this topic comes up are clear – technology procurement decisions are all about growth, and growth often requires change. When you reach a stage where your underlying technology can’t support that growth, you have to stretch. If your database server can’t move fast enough to facilitate an influx of new registrants to your dating app, for example, it is time to confront the question.
That answer can be difficult to nail down. On the one hand, if off-the-shelf software does not serve your purpose, you have to write your own infrastructure. On the other, big vendors like Oracle have the customer base and heft sufficient to respond to customers’ demands for new growth features – meaning answering the question is like continually chasing your tail.
It is an issue I have faced several times over the last eight years, whilst serving as CTO at various companies. Whilst at Network 18, a massive media conglomerate, we saw the opportunity to ramp up online ad sales and the need to improve our ad-serving capability. Should we build our own ad server?
It was a question we asked every year. Improving capabilities would lead to more clicks and higher margin. So we evaluated and prototyped our own ad server stack. But, in the end, we decided to buy out-of-house for a clear reason – an ad server is not just a standalone technology; it is a marketplace that depends on connections to outside demand sources. We could build the tech, for sure, but reinventing the wheel would be harder.
Here at CleverTap, we made the opposite call. Providing a real-time solution for both behavior analytics and user engagement is intensive. We assessed everything we could find on the shelf – RedShift, Amazon DynamoDB, Hadoop, multiple time-series databases – and, finally, concluded we couldn’t pick anything off the shelf to meet the needs of the service and the scale we envisaged.
In fact, picking an existing product would have expedited our launch to market in a segment that was moving fast. Deciding on a custom solution added 12 to 18 months of development time before we could get out the gate. But we decided building our custom solution would give us a proprietary product that would be more robust, scaleable, and differentiated.
I am not alone. If you are a CTO, this is the decision you are paid to make – and the stakes have never been higher. So, how do you think about where to place your money?
Go-to-market strategy
Weigh up the long-term benefits of the time taken to build an in-house custom solution, which may delay launch by many months, against the traction it will be possible to get by using off-the-shelf technology tomorrow. Only if the code you write will give your business a massive competitive advantage, then go long. A faster time to market typically is a killer advantage to any business.
Survey the landscape
The vendor ecosystem is moving fast and constantly evolving. The timescale between product launches and upgrades is shrinking fast. A smart CTO is always expertly surveying the entirety of the landscape, scoping out new products, checking what’s out there, assessing demos, and generally testing the options – long before the next strategic decision has to be made.
Can you commit?
For your engineering team, the first few months of building out a new product feel sexy – bringing a creation to fruition is exciting. But, as that product sees light of day and gets released, the thing goes into maintenance mode, and maintenance is harder to excite people about over the long term. In the future, you will need to add features and make fixes. Suddenly, you’re not agile anymore – the shine wears off and your stack becomes the 800lb gorilla that nobody wants to touch. If your organisation is setup to work this way, it is not a problem – but not all companies are geared for fixing and maintaining.
What fits your flow?
Every company has its own workflow. When you examine technology off the shelf, don’t just look at features – check for whether it fits the way your company, and its existing systems, work. If you have only ever built technology, it may be difficult to plug in a third-party product but, if your DNA is to buy and assemble different components, you may be best sticking with the open market. These days, most vendors want their products to be as open and interconnected as possible – and the choices you have are incredible.
Do you have the talent in place?
There is a lot of tech talk about machine learning and artificial intelligence these days. But companies embarking on building out solutions like these need to ask themselves – can they attract the people with the right skillset? For many, the answer may be “no”. Some of these engineering roles come with some of the highest salaries in the business; and these developers are in short supply. So, whilst Uber or Amazon may have little problem building out the next machine learning-powered solution, smaller companies may want to look at buying instead.
Are you CTO enough?
Every CTO or VP of engineering goes through the ‘build or buy?’ runaround. But many of them emerge out the other side with varying degrees of success. The lesser-skilled leader typically does not build – he or she has too little confidence that they can actually pull off the build. So less experienced IT execs tend to buy in – no-one ever got fired for buying in IBM or Oracle. Buying like this helps you in another way – when someone else built your product, there is always someone else’s neck to choke when things go wrong.
Does your IT need IP?
Technology companies are not just valued on their user base or customer count. The originality of your product or service depends on whether it is repeatable by a rival. Creating and registering your own intellectual property will create extra intrinsic value within your organisation that may come in handy at sale or IPO time, meaning a better exit for all. Of course, that may be a long time off – so, if delivering to customers is a more pressing necessity, you may weigh buying in software more highly.
At the end of the day, the ‘build’ and ‘buy’ options are not mutually exclusive. Many companies operate well by both developing their own software when desired and buying in pieces of tech when needed. The bigger your company is, the more choice you have.
But the very different outcomes of, and reasons for, choosing either route – at any given point in time – will radically reshape how you make your next big software procurement choice.