Buy vs. Build Revisited: 3 Traps to Avoid

Many enterprises anchor their IT strategy on buy vs. build decisions: what software packages or systems they buy versus which ones they prefer to build themselves. Buy over build is the default for most organizations, which is a sensible approach when considering that the majority of the IT estate doesn’t differentiate the business. For example, an accounting system will favor uniformity and compliance and hence should be bought. Many enterprise software packages, such as ERP (enterprise resource planning), are highly customizable, providing some middle ground between buy and build: configuration allows adjusting the software to specific needs without having to build the whole system from scratch.

On the other end of the spectrum are the so-called digital giants to whom enterprises often look as models for highly agile organizations. These companies develop a large portion of the software they use in house, often leading enterprises to conclude that these companies are technology companies as opposed to their “regular” business. This, of course, is a fallacy—very few of the digital disruptors sell technology. They usually disrupt an existing industry, be it advertising, insurance, e-commerce, hospitality, or transport, all of which would surely qualify as “regular” businesses. The difference is indeed that these companies have chosen to do much of their software development in house as opposed to relying on third-party software.

Based on these two data points, many enterprises conclude that the decision on what to buy and what to build can be reduced to a simple equation: you should build the software that differentiates your business and buy all else. Although this guideline is perhaps a good starting point, it’s certainly not the end of the story. IT strategy has never been quite so simple.

“You should build the software that differentiates your business and buy all else” is a useful starting point but certainly not the end of the buy vs. build decision.

Having been part of many buy vs. build discussions, I have seen organizations miss some of the more nuanced trade-offs involved in this deceptively simple decision, and often they were not happy with where they ended up. In this post I’ll share the top three considerations when deciding what to buy and what to build.

1. You Pay in Opportunity Cost

Many proposals to build software instead of buying it originate from a claim that “we can build this for less.” Naturally, one should wonder how an internal team would be able to build a one-off solution cheaper than a software vendor who can amortize the investment across hundreds or sometimes thousands of customers.

No developer would claim to be able to build an enterprise-strength relational database for less than the comparable license fee. However, I have seen enterprises acquire sophisticated packaged software solutions out of which they only utilize a small fraction. You could compare this to buying an exotic sports car you only use to get groceries. By acquiring such software, the enterprise also pays for the vendor overhead like cost of sales, corporate offices, lawyers, and Finance. Lastly, they’ll also pay for customization and configuration of this overly complex product, often in the form of high-priced external consultants.

One can imagine building a one-off go-kart or trolley cart that gets your groceries at a lower cost than the sports car. However, when comparing internal development cost with the cost of acquiring a license, many enterprises make one major mistake: setting aside developers to work on a piece of software doesn’t just cost you in the developers’ loaded salaries. Rather, you pay in opportunity cost. The engineers building this solution would otherwise be available to build things that provide significant value to the business. Assuming your business and your IT run well, this opportunity cost should be a multiple of the actual cost—your IT surely delivers more value than it costs.

Developers building a custom solution would otherwise generate business value. Hence, you need to account for that opportunity cost, which is often a multiple of the monetary cost.

Despite favoring build over buy, so-called digital companies nevertheless consider their developers’ opportunity cost very carefully. Many years ago when I was building online advertising solutions, the number circulating as opportunity cost was over $1,000 per developer hour. So, you better have your engineers work on the most valuable stuff.

Increasing developer productivity, for example with automated build and test pipelines, is a great way to make building solutions more attractive. Ironically, though, it’d also increase the developers’ opportunity cost because now they could generate more business value. So, more productive developers don’t make rebuilding already available solutions “cheaper.”

2. Value Is the End of the Rainbow

As indicated above, organizations lean toward building software systems that help them differentiate; that is, those that provide a unique business value. And this makes good sense: having full control over your core business systems can be a major asset. The story goes that many decades ago MCI’s Friends & Family discount plan rapidly gained market share in the US long-distance business because AT&T’s systems couldn’t support a change in rates based on a customer’s “calling circle.”

No business wants to be caught with its back against the IT wall, so building critical systems in house seems a good way to deliver value to the business. Or does it? Building systems in house definitely gives you the flexibility to prioritize features according to your specific situation instead of having to wait until sufficient demand for a feature motivates the vendor to add it to the roadmap. In a way, needing sufficient demand to include a feature in a packaged piece of software would exactly preclude you from gaining a competitive advantage: you’d have to wait for everyone else to have the same great idea.

However, being able to code features at your will doesn’t suffice to deliver value and gain competitive advantage. Value is generated along the proverbial value chain, an apt metaphor to remind us that the chain is broken if any link is missing. For example, if your organization is lacking data on your software’s usage or customer behavior patterns, then even if you are able to turn your software delivery machine on a dime, you’re nevertheless flying blind. Likewise if your supporting back-end systems have a much slower rate of change than your front-ends, your software engineers will be spinning their wheels because their feature delivery depends on those systems. Lastly, cumbersome approval and decision processes can be major impediments to swift value delivery.

Prioritizing features alone doesn’t deliver value to the business. You also need a matching ecosystem of transparency, support systems, and agile processes.  

One could say that your organization—IT and business side included—has to learn, and earn, the ability to benefit from custom-built software. Rapid end-to-end delivery and high levels of customer feedback make building software in house worthwhile for digital companies despite their high opportunity cost. So, if you want to share the same success, you need to copy the whole ecosystem. Just starting to build custom software won’t be sufficient.

3. You’re Still Locked In

Lastly, one frequent argument toward building software is the danger of being locked into a purchased solution. Many a company who has tried to migrate off their ERP or CRM system felt like they were in a hostage negotiation with tens of millions of dollars to be paid in ransom. If we had only written the software ourselves….Not so fast! If you build a major system in house, you are very much locked into that solution. Yes, you have direct influence over the feature backlog, but that doesn’t mean your software will always do what you want it to. For example, platform technology evolves constantly and brings new capabilities. If your application hits scalability limits but is a traditional monolith backed by a giant relational database, a move to more scalable container or serverless technology in the cloud might be difficult. In the worst case you might feel held hostage by in-house developers who are threatening to leave the company.

Migrating off your own solution might be as difficult, or worse, than migrating off a commercial solution. You are still locked in. 

The very flexibility offered by in-house development often leads to complexity and technical debt, which slow down your delivery velocity. There isn’t a magic solution—you can’t just switch over to another product just because you built this one in house. Complete rewrites of in-house applications have provided some of the juiciest disaster stories in IT history. So, you’re still locked in, albeit to your own solution.

Better Decisions for Better Results

There are no obvious choices in IT. What appears as common sense, like “I build it if it’s cheaper or differentiates me” is subject to interpretation and important nuances. For example, the ways you calculate cost and the value of differentiation will have a substantial impact on your decision. A sensible strategy will take these considerations into account and lead to better decisions than simply proclaiming “buy over build.” It’ll require you to invest a bit more into thinking about your choices, but in my experience, thinking is the activity with the highest ROI anywhere in IT. And it’s best done in house!

Next up: Drawing the Line.

—Gregor
Twitter | LinkedIn | Blogs | Email

More on this topic

Don’t Outsource Thinking, Gregor Hohpe

Time to Rethink Build vs Buy, Ishit Vachhrajani