Build vs buy is rarely about cost against control. Ask where you differentiate, then use five factors and a one-page template to decide and explain it.

Under deadline pressure, a build vs buy decision tends to be settled by whoever speaks first. One camp says 'we can build that in a sprint'. The other says 'someone must already sell this'. Both instincts skip the same step: asking what the capability is actually for.

This article offers a way to slow that moment down without slowing the team down. You will find five factors to weigh, some openly hypothetical examples, a one-page template for a decision meeting and a checklist of questions for vendors. A small dry observation first: 'a sprint' is rarely the real size of anything that has users.

Why 'cost versus control' is the wrong frame

The usual framing sets cost against control. Buying is cheaper but you give up control. Building costs more but you keep it. It sounds tidy, and it is why so many of these decisions end up as a spreadsheet argument.

The trouble is that it ignores what the team is for. Control only matters where you need to change behaviour that customers care about. Everywhere else, it is a lot of responsibility for very little return.

Cost is also easy to underestimate on both sides. Teams undercount the upkeep of what they build and the integration and exit costs of what they buy. Comparing two shaky numbers gives you false confidence, which is arguably worse than having no number at all.

A better lead question is this: is this where we differentiate?

Start with differentiation: product or plumbing?

Differentiating capabilities are the ones customers choose you for. Plumbing is what they expect to simply work.

Here is a practical test. If a competitor had the same capability tomorrow, would your customers notice or care? If the answer is 'not really', you are probably looking at plumbing. If the answer is 'that would hurt', you are probably looking at product.

Treat this as a strong first filter, not a law. There are exceptions, such as unusual regulatory or performance requirements that no off-the-shelf option meets. And plumbing that you buy still needs an owner inside the team, someone who understands how it works, watches how it behaves and talks to the vendor.

The real cost of building

The first release is usually the smaller part of what something costs over its lifetime. The rest arrives quietly:

• Maintenance: bug fixes, dependency upgrades, and the odd change nobody planned for.
• Security updates: someone has to track vulnerabilities and patch them, indefinitely.
• Monitoring and documentation: the unglamorous work that keeps a system understandable to people who did not write it.
• On-call: when it breaks at 3am, someone on your team is now responsible.
• Opportunity cost: whatever the team did not build while looking after this.

Building is an act of ownership. That is worthwhile where the capability is core to what you offer, and wasteful where it is not.

The real cost of buying

Buying shifts cost rather than removing it. The bill just arrives in different forms:

• Integration effort: connecting your data, identity, events and workflows to the vendor's model of the world.
• Customisation limits: you either adapt your process to the product, or discover later that it cannot do what you need.
• Pricing changes: at renewal, or as usage grows, and sometimes in ways your original budget did not anticipate.
• Roadmap dependence: your priorities now sit alongside everyone else's on the vendor's list.

Buying also creates its own technical debt. Workarounds accumulate, bespoke glue code grows around the product's edges, and there is a migration cost you have not yet paid but will, one day, if you leave.

Lock-in is best thought of as a spectrum. Rather than asking whether you can leave, ask how costly leaving would be, and whether that cost is one you can live with.

The five-factor framework at a glance

For each capability, work through these five prompts:

1. Differentiation: does this set the product apart?
2. Ongoing ownership cost: what will we carry for years, whether we build or buy?
3. Integration effort: how much work to fit it into our systems and workflows?
4. Exit options: how hard is it to change our minds later?
5. Team capacity: do we have the skills and time to do this well without starving other priorities?

Treat these as prompts for conversation, not a formula that produces the answer. Their value is in surfacing assumptions that would otherwise stay buried until it is expensive to change them.

Where the answer flips: three hypothetical scenarios

The scenarios below are illustrative, not case studies and not universal rules. They show how the same framework gives different answers when the context differs.

Authentication versus a core workflow feature

Imagine a team building a project-planning tool. Authentication is security-sensitive, well understood, rarely a reason customers pick the product, and costly to get wrong. Buying usually wins. It leans towards building, or heavy customisation, only when requirements are unusual.

Now take the feature that defines how customers plan their work, such as how tasks relate to each other. That is the reason people choose the product. Even if a vendor offers something close, building is usually justified, because the detail of the behaviour is the point.

Same framework, opposite answers, and the difference is differentiation.

A content management system

For a small team publishing marketing content, a bought or open platform is often sensible. Editing pages is plumbing, and nobody chooses the company for its admin screens.

Now imagine a product where the editing experience is the product, such as a tool for creative teams to compose and publish. Differentiation shifts, and the answer may well change. In borderline cases, integration effort and team capacity tend to decide it.

A recommendation feature over time

Early on, buying a recommendation service lets you test whether recommendations matter to your users at all. That is a cheap way to learn.

If the feature becomes central to the product's value, and the vendor's model starts to limit what you can do, building may become justified. The point is that the decision is a point in time, not a permanent verdict.

Designing an exit route without over-engineering

You do not need an elaborate escape plan for every vendor. Two modest habits go a long way:

• A thin abstraction layer: an internal interface that the rest of the codebase calls, so the vendor sits behind one door rather than being scattered through everything.
• Regular exports of your own data in a usable format, so that leaving is a project rather than a crisis.

Scale the effort to how critical and how replaceable the capability is. Over-abstracting for a vendor you will probably never leave adds complexity of its own, and that complexity has to be maintained too.

It also helps to write down the decision and the assumptions behind it, briefly. Some teams use architecture decision records for this, but a short note that people can find is better than a perfect format nobody uses.

A one-page scoring and conversation template

The template below fits on one page and works well in a 45-minute meeting with product and finance. For each factor, note the lean (towards build, towards buy or unclear) and write one sentence of reasoning.

• Factor: Differentiation | Lean: | One-sentence reasoning: | Confidence: | Assumption that would change the answer:
• Factor: Ongoing ownership cost | Lean: | One-sentence reasoning: | Confidence: | Assumption that would change the answer:
• Factor: Integration effort | Lean: | One-sentence reasoning: | Confidence: | Assumption that would change the answer:
• Factor: Exit options | Lean: | One-sentence reasoning: | Confidence: | Assumption that would change the answer:
• Factor: Team capacity | Lean: | One-sentence reasoning: | Confidence: | Assumption that would change the answer:

Then use it like this:

• Ask product to challenge the differentiation row. They know what customers value.
• Ask finance to challenge the cost assumptions and the pricing exposure.
• Use the scores to expose disagreement, not to settle it automatically. Two people scoring the same row differently is the useful bit.
• End the meeting with a decision, an owner and a review date.

Questions to ask vendors before committing

This checklist is a starting point. Ask for answers in writing where you can.

• Pricing: how does the model change with usage, seats or data volume? What happens at renewal?
• Contract: how long is the term, what are the notice periods, and what are the termination terms?
• Data: what export formats are available, how quickly, and at what cost?
• API: how much of the product can be reached programmatically, and what are the rate limits?
• Reliability: what uptime and support commitments are offered, and how are incidents communicated?
• Security and compliance: what documentation is available for your team to review?
• Roadmap: how transparent is it, and how are customer requests handled?
• Continuity: what happens if the vendor is acquired or shuts down?

Vague answers to these are information in themselves.

Treat it as time-bound: what to revisit and when

Write down revisit triggers at the time you decide, while the reasoning is fresh. Typical triggers for bought software include:

• pricing changes, or usage crossing a scale threshold you flagged earlier
• the vendor changing terms or direction
• customisation limits blocking product goals

For software you built, watch for:

• maintenance load crowding out roadmap work
• the capability becoming a commodity
• a mature product now meeting the need well enough

Schedule a light review, perhaps once or twice a year, rather than waiting for a crisis to force one.

Framing the recommendation for non-technical stakeholders

Finance and product colleagues rarely need the architecture. They need to understand three things:

• Risk: security, delivery risk and vendor dependency.
• Speed: time to value, and what it does to team capacity.
• Strategy: where the company wants to be distinctive, and where it does not.

State your assumptions explicitly and say what would change your mind. Translate technical debt into business terms: future cost, reduced flexibility and a delayed roadmap. And present options with their trade-offs rather than a single verdict dressed up as fact. People trust a recommendation more when they can see the alternatives it beat.

A closing thought: buy plumbing, build what you are known for

The right question is not whether building is cheaper than buying. It is where you differentiate, and the honest answer will shift as the product and the market change.

Try the one-page template on a decision your team is weighing right now, then get in touch if you would like to compare notes on how it played out.