Every growing business eventually faces this question: should we build custom software or buy an existing solution? It sounds like a straightforward evaluation, and people tend to have strong instincts about the answer. Engineers lean toward building. Finance teams lean toward buying. Both sides have reasonable arguments, and both sides routinely underestimate the costs of their preferred option.

The build-versus-buy decision is one of the most consequential technical choices a business makes, and it deserves more rigour than a gut feeling. Get it right, and you gain either a competitive advantage through custom technology or speed and reliability through proven platforms. Get it wrong, and you spend years paying for a decision that looked sensible at the time.

This is a framework for thinking through that decision clearly.

Why This Decision Is Harder Than It Looks

The obvious framing is simple: building costs development time, buying costs licensing fees. Compare the two numbers, pick the smaller one. This framing is wrong, and it leads to bad decisions in both directions.

The real comparison involves at least a dozen variables, many of which are difficult to quantify and most of which change over time. A buy decision that makes sense at your current scale may become untenable as you grow. A build decision that seems prohibitively expensive today may be the only viable path once your requirements diverge far enough from what off-the-shelf solutions support.

The difficulty is compounded by asymmetric information. When you evaluate a buy option, the vendor controls the narrative. Their sales team will show you the best-case scenario, the smoothest integration, the happiest customer. When you evaluate a build option, your own engineering team provides the estimates, and engineers are notoriously optimistic about how long things will take and how clean the implementation will be.

Neither side is lying. They are both telling you what they genuinely believe. The problem is that both sides are systematically biased, and you need a framework that accounts for those biases.

The Real Costs of Buying

Organisations that default to buying typically underestimate several categories of cost.

Integration Costs

Off-the-shelf software rarely works in isolation. It must integrate with your existing systems — your CRM, your accounting platform, your authentication system, your data warehouse. Vendors will tell you their product “integrates seamlessly” with everything. In practice, integration is where most of the hidden cost lives.

Every integration point is a potential failure mode. Data formats do not quite match. Authentication flows require custom middleware. Reporting needs data from three systems that were never designed to talk to each other. You end up building custom integration code that is just as complex as the feature you were trying to avoid building, except now it must also accommodate the vendor’s architectural decisions, update schedule, and API quirks.

Customisation Constraints

Your business processes are not identical to the vendor’s assumptions. Every off-the-shelf product embeds a model of how work should flow, and that model will diverge from yours in ways that range from minor inconveniences to fundamental incompatibilities.

Minor gaps lead to workarounds. Staff learn that the system “doesn’t really support” certain workflows, so they develop informal processes that exist alongside the official system. These workarounds are invisible to management, fragile, and nearly impossible to document or transfer when employees leave.

Fundamental incompatibilities are worse. You discover that the product cannot support a workflow that is central to your business. At this point, you face an unpleasant choice: change your business process to fit the software, invest in expensive customisation that may not survive the vendor’s next major update, or abandon the platform entirely and absorb the switching costs.

Vendor Lock-In

The longer you use a platform, the more your data, processes, and institutional knowledge become entangled with it. Switching costs increase with time. Vendors know this, and their pricing models are designed to take advantage of it. Initial licensing fees are often reasonable. Renewal prices less so.

Lock-in also manifests in less obvious ways. Your team develops expertise in a specific platform. Your hiring pipeline filters for candidates with experience in that platform. Your processes are documented in terms of that platform’s features and terminology. Even if a better alternative emerges, the switching cost — measured in disruption, retraining, and migration effort — may be prohibitive.

Ongoing Licensing

SaaS pricing scales with usage, often in ways that are difficult to predict. A platform that costs two thousand pounds per month at your current scale may cost twenty thousand at the scale you are planning for. Per-seat pricing, per-transaction fees, storage tiers, API call limits — these costs compound as you grow, and they compound in ways that your internal build costs would not.

Run the numbers at your projected scale three years from now, not at your current scale. The economics of build versus buy look very different when you account for growth.

The Real Costs of Building

Organisations that default to building have their own blind spots.

Development Time

Engineering estimates are wrong. Not occasionally — systematically. Study after study confirms that software projects take two to three times longer than initial estimates. This is not because engineers are incompetent but because software development is fundamentally uncertain work. Requirements change. Dependencies introduce unexpected constraints. Edge cases multiply. Integration with existing systems reveals assumptions that do not hold.

When you build, you are not just paying for the initial development. You are paying for the discovery process: the work of learning exactly what the requirements are through the act of trying to implement them.

Maintenance Burden

Software does not age gracefully. Dependencies need updating. Security vulnerabilities require patching. Operating systems, browsers, and APIs evolve, and your custom software must evolve with them. A system that works perfectly today will require ongoing investment simply to continue working at the same level.

This maintenance burden is easy to ignore during initial planning because it is not dramatic. It is a slow, persistent tax on your engineering capacity. Typically, maintenance consumes twenty to thirty percent of the engineering effort that built the system in the first place, every year, indefinitely.

Opportunity Cost

Every engineer working on internal tooling is an engineer not working on your product. For companies whose competitive advantage lies in their technology, this trade-off is obvious: build the things that differentiate you, buy everything else. But the line between “differentiating” and “everything else” is not always clear, and teams routinely over-estimate how much of their software truly constitutes competitive advantage.

Building your own email delivery system, for example, is almost never justified. Building your own billing system is very rarely justified. Building your own analytics platform is occasionally justified. The question is not whether you could build a better version, but whether the improvement matters enough to justify the investment.

The Decision Matrix

Here is a practical framework for evaluating whether to build or buy.

Build When:

The capability is a core differentiator. If the software directly enables something your competitors cannot easily replicate, building makes sense. This is your competitive moat. Buying a commodity solution for a differentiating capability means your competitors can buy the same solution and eliminate your advantage.

Your workflow is genuinely unique. Not “slightly different from the default” — genuinely unique in ways that no off-the-shelf product can accommodate without extensive customisation. If you find yourself evaluating a buy option and the customisation estimate is more than forty percent of the build estimate, you are effectively building anyway, just with worse architecture.

You have the team to maintain it. Building without the engineering capacity to maintain what you build is a recipe for technical debt. If your team is already stretched thin, adding a custom system that depends on them for every bug fix and feature request will make things worse, not better.

The long-term economics favour it. Model the total cost of ownership over three to five years, including maintenance, opportunity cost, and scaling. If building is cheaper at your projected scale, and you have confidence in those projections, the economics support the investment.

Buy When:

The function is commodity. Email, payments, authentication, analytics, CRM — these are well-solved problems with mature, reliable products. Building your own version of a commodity function is a poor use of engineering talent unless you have very specific requirements that no existing product can meet.

Time-to-market is critical. If you need the capability in weeks rather than months, buying is almost always the right choice. You can revisit the decision later if the bought solution proves inadequate, but shipping matters more than perfection in most competitive environments.

The market is well-served. When dozens of mature products exist in a category, the market has had years to solve the hard problems. Your custom build will encounter the same hard problems and will not have the benefit of thousands of customers’ edge cases to learn from.

You lack the team to build and maintain it. Honest assessment here. Not whether you could hire the team, but whether you have the team today and whether they have capacity. Building on a promise of future hiring is high-risk.

The Hybrid Approach: Buy the Platform, Build the Differentiators

The most effective strategy for most growing businesses is neither pure build nor pure buy. It is a deliberate hybrid: buy the platform, build the differentiators.

This means choosing proven platforms for commodity functions and building custom capabilities on top of or alongside them. The platform handles the undifferentiated heavy lifting — the parts that are important but not unique — while your custom development focuses exclusively on the things that make your business different.

Case Example: E-commerce

Consider a growing e-commerce business. The buy decision for the core platform is clear: Shopify Plus provides checkout, inventory management, payment processing, and order fulfilment workflows that have been refined across millions of merchants. Building these from scratch would take years and produce an inferior result.

But the differentiators — a custom product configurator, a proprietary pricing algorithm, a personalised recommendation engine built on your specific customer data — these are worth building. They create competitive advantage that buying cannot replicate. The platform handles the ninety percent that is commodity. Your engineering effort focuses on the ten percent that matters.

Case Example: Operations

A mid-market logistics company needs to manage customer relationships. The buy decision: a standard CRM platform handles contact management, pipeline tracking, and reporting. These are commodity functions with excellent existing solutions.

The build decision: a custom route optimisation system that accounts for their specific vehicle fleet, delivery constraints, and customer SLAs. This is their competitive advantage — the thing that lets them offer better service at lower cost than competitors. No off-the-shelf routing solution accounts for their specific constraints, because their constraints are what make them competitive.

Making the Decision Stick

Once you have decided, commit. The worst outcome is a half-built custom system alongside a half-implemented platform, with data split between them and nobody quite sure which is the source of truth. This happens more often than anyone admits, usually because the initial buy decision was not given enough resources to succeed, or the initial build decision was not given enough time to mature.

For buy decisions: invest properly in integration, training, and process adaptation. Budget for customisation. Assign an internal owner who is accountable for getting value from the platform, not just implementing it.

For build decisions: plan for maintenance from day one. Document architectural decisions. Build with the assumption that someone other than the original developer will need to understand and modify the system.

For either decision: revisit the evaluation periodically. Markets change, businesses evolve, and the right answer today may not be the right answer in two years.

Getting the Framework Right

The build-versus-buy decision is ultimately about understanding where your business creates value and investing your limited engineering resources there. Everything else should be bought, integrated, and forgotten about.

If you are facing this decision — particularly for platform-level choices that will shape your technology landscape for years — it is worth investing time in getting the framework right. A few weeks of rigorous evaluation can save years of living with the wrong choice.

We work with growing businesses on exactly these decisions as part of our digital strategy engagements. Not to push a particular answer, but to make sure the question is being asked correctly and that the analysis accounts for costs that are easy to overlook.