Build vs buy software: a decision framework for founders and CTOs

The short answer

• There are four options, not two: buy, buy and extend, assemble, or build.
• Build only what differentiates the business and where the market does not offer a good fit. Buy everything else that the market already does well.
• Compare the total cost of ownership over the whole horizon. Building has a maintenance tail; buying has integration, customisation and exit costs.
• Decide how you would get out before you get in. Reversibility is the most underrated criterion.

The real question behind build vs buy

Every engineering team has a limited amount of attention. Each capability the company builds and maintains in-house consumes some of it, permanently. Each capability it buys consumes money, integration work and some control. The build-versus-buy question is therefore not “which is cheaper?” but “where should our engineering attention go, and what are we willing to depend on?”

Framed that way, most decisions become clearer. Billing, authentication, analytics and internal tools are rarely where a company wins. The part of the product customers choose you for usually is.

Four options, not two

Option	What it means	Fits when
Buy	Use a commercial product or service largely as it comes	The need is common and the market solves it well
Buy and extend	Buy a platform, then configure or extend it through its supported interfaces	The core need is common, but you have specific requirements at the edges
Assemble	Combine open-source components or services with your own integration code	No single product fits, but the building blocks exist
Build	Design, develop and run it yourself	The capability differentiates you and the market cannot provide it

Many bad decisions come from treating these as two options. A team that rejects “buy” because one requirement is not met often skips straight to “build” without considering whether to extend or assemble.

The five questions

1. Does this capability differentiate the business?

Ask whether a customer would choose you, stay with you or pay you more because of how this capability works. If the honest answer is no, the capability is likely infrastructure for the business rather than a source of advantage, and the default should be to buy.

Be strict. Teams tend to describe everything they care about as differentiating. A useful test is whether you would be comfortable if a competitor used the same commercial product for it.

2. How well does the market fit the need?

List your requirements, then mark each as essential or preferable. Compare candidate products against the essential list only. A product that meets every essential requirement and most preferable ones is a good fit, even if the team would design it differently.

Watch for requirements that exist only because of how the current process works. Sometimes the cheaper change is to the process, not the software.

3. What is the full cost of ownership over the horizon?

Compare costs over a realistic horizon, typically three to five years, and include everything. The checklist below covers the items most often missed.

Total cost of ownership: what to count

Checklist

If you build

• Initial design and development
• Ongoing maintenance, upgrades and security patching
• Hosting, monitoring and on-call support
• Documentation and onboarding of new engineers
• Features you will be asked to add once it exists
• The product work that does not happen while the team builds this

If you buy

• Licences or subscriptions at expected future scale, not today's
• Integration with your systems and data
• Configuration, customisation and the skills to maintain them
• Price changes and renewal negotiations
• Data migration in, and eventually out
• Internal ownership: someone must run the vendor relationship

The most commonly underestimated items are the maintenance tail of a build and the integration cost of a buy. Both are permanent.

4. What risks does each path carry?

Each path has its own risk profile. Building carries delivery risk (it takes longer than planned), key-person risk (one engineer understands it) and the risk of an under-maintained system. Buying carries vendor risk (pricing, roadmap changes, acquisition, discontinuation), data and security risk (your data in someone else’s system), and lock-in.

Write the main risks for each path side by side, with how you would mitigate them. A risk with no mitigation is a cost you have not priced.

5. How do you get out?

Before committing, describe the exit. If you buy, how would you export your data and move to another product, and how long would it take? If you build, could you replace your system with a commercial product later, or will the rest of the platform depend on its internals?

Prefer the option that keeps future choices open. Isolating the capability behind a clear interface, whichever path you take, is the cheapest insurance available.

The decision matrix

The first two questions do most of the work. Plot the capability on them before arguing about cost.

Build vs buy: differentiation against market fit

Decision matrix

Strategic differentiation →

• Differentiating · poor fitBuildThis is where your engineering attention belongs. Keep it focused and isolate it behind clear interfaces.
• Differentiating · good fitBuy the core, build the edgeBuy a platform and build the differentiating layer on top through supported extension points.
• Not differentiating · poor fitAssemble, or change the requirementCombine components, or challenge the requirements that rule out standard products.
• Not differentiating · good fitBuyUse the market. Spend the saved attention on what customers choose you for.

Poor market fitGood market fit →

A weighted scorecard

For decisions that need a written record, score each option against weighted criteria. The weights are a leadership judgement and should be agreed before anyone scores the options, so the scoring cannot be reverse-engineered towards a preferred answer.

Criterion	Example weight	Score 1 means	Score 5 means
Strategic differentiation	30%	No customer would notice	Core reason customers choose you
Fit to essential requirements	20%	Major gaps	Meets every essential requirement
Total cost of ownership over the horizon	20%	Highest of the options	Lowest of the options
Delivery and operational risk	15%	High and hard to mitigate	Low or well mitigated
Reversibility	15%	Exit would take a major project	Exit is straightforward

Score each option from 1 to 5 per criterion, multiply by the weight and add up. Treat a close result as a sign that either option is defensible, and let the risk and exit questions decide.

Common traps

• “We can build it in a sprint.” The first version may take a sprint. The maintenance takes years.
• Customising a product until it becomes a build. Heavy customisation of a bought platform combines the costs of both paths and the flexibility of neither.
• Comparing today’s licence price with tomorrow’s build cost. Compare both at the scale you expect over the horizon.
• Ignoring the integration. Many bought products are cheap to license and expensive to connect.
• Not deciding at all. A team that builds a workaround while the decision is pending has quietly chosen to build.

Running the decision

Name one decision owner, usually the CTO or the most senior technology leader. Gather the inputs above, decide, and record the decision with its context, the options considered and the conditions under which you would revisit it, such as a price change, a new requirement or a growth threshold. A short written decision record is enough; architecture teams often call it an ADR.

If the decision is significant and the team lacks either the time or a neutral view, it is a good candidate for a scoped engagement. Comtau’s CTO consulting takes a single question like build versus buy and returns a written recommendation with the options and their consequences. When the decision is one of many shaping the next year, it belongs on the technology roadmap instead.