Build vs. buy: a decision framework that accounts for the second year

The standard build-versus-buy analysis compares an engineering estimate against a first-year licence quote. That comparison is wrong in both directions and predictably so: it understates building, because the estimate excludes the maintenance tail, and it overstates buying, because the licence excludes integration. Correcting both usually flips the answer at least as often as it confirms it.

Here is a framework that accounts for the second year — and the fifth.

Start with the differentiation question

Before any arithmetic, answer one question: would this capability appear in your pitch?

If a customer would choose you because of how this thing works, it is differentiating and building deserves serious consideration. If it merely has to work — authentication, billing, log aggregation, e-signature, error tracking, scheduling — then no amount of excellence in it will win you a customer, and the only thing building buys you is a system to maintain.

Most organisations already know which category a capability falls into, and most build decisions that go wrong were made about capabilities everyone knew were commodity. The framework's first job is to make that knowledge explicit before the interesting technical discussion starts.

What should a build-vs-buy model actually compare?

Three-year total cost of ownership, both sides, with nothing omitted because it is awkward to estimate.

Two rows do most of the damage when they are missing. Integration is absent from nearly every "buy" estimate, and it is not a rounding error: for enterprise software touching several internal systems, integration commonly costs as much as the first year of licence and sometimes several times more. Opportunity cost is absent from nearly every "build" estimate, and it is usually the single largest number in the whole model.

How do you estimate the maintenance tail?

Use 15–25% of the original build cost, per year, forever, as a planning figure. That covers dependency upgrades, security patching, bug fixes, and the changes forced on you every time an adjacent system changes.

Push toward the top of that range — or above it — when the system touches authentication, payments, personal data, or anything under a regulatory regime. Those areas generate mandatory work on someone else's schedule, and the work does not stop when the roadmap moves on.

The critical discipline is applying the figure for the life of the system rather than for one budget cycle. A tool built in year one is still consuming engineering attention in year six; a model that stops at year three has quietly made a decision that year six will pay for.

Software you build is not an asset that appreciates. It is a liability with a useful side effect, and the liability compounds annually whether or not anyone is looking at it.

Opportunity cost: the number nobody writes down

If four engineers spend a quarter building an internal tool, the cost is not their salaries. The cost is whatever they would otherwise have shipped, and for a product team that number is usually much larger than the loaded cost of the time.

You do not need a precise figure. You need the comparison to be stated: "this build consumes roughly one quarter of the platform team, which is the same capacity as the reporting overhaul we deferred." Once expressed that way, build-versus-buy decisions tend to resolve themselves without further modelling, because everyone can now see what is actually being traded.

When does building genuinely win?

Three cases cover most defensible build decisions:

1. Real differentiation. The capability is a reason customers choose you, and a vendor implementation would make you the same as everyone else using that vendor.
2. No adequate vendor. Nothing on the market covers your workflow without customisation so heavy that you would be maintaining the customisation anyway — with less control and a licence fee on top.
3. Integration cost approaches build cost. If adopting a vendor requires as much engineering as building the thing, the vendor's main remaining advantage is their roadmap, and you should be explicit about whether you actually want it.

Reasons that are not on that list, despite appearing in many business cases: the team finds it interesting; the vendor quote looked expensive against a single budget line; "we could build that in a sprint"; and a general preference for control. The last one is real but should be costed, not asserted.

When does buying genuinely win?

• The capability is commodity and the market is mature, so vendors compete on price and you inherit their improvements for free.
• The domain carries compliance burden you would otherwise absorb — payments, identity, tax calculation. Buying transfers a category of risk, not just work.
• Time to value matters more than fit. A vendor live in six weeks at 80% fit frequently beats a perfect internal tool in nine months.
• The capability is outside your team's competence and hiring for it would mean building a discipline, not adding a person.

The hybrid that usually wins

Framing the question as binary is itself often the error. The strongest answer is frequently: buy the substrate, build the thin layer that differentiates.

Buy the identity provider and build the permissions model your product needs. Buy the payments infrastructure and build the pricing logic that is genuinely yours. Buy the data warehouse and build the metrics definitions. You get the vendor's maintenance burden and compliance posture on the commodity part, and you keep ownership of the part customers notice.

This split is also the cheapest to reverse. If the vendor fails you, the thin layer survives; if you had built the substrate too, replacing it means replacing everything.

A one-page decision record

Whatever you decide, write it down in a page with five headings. It costs twenty minutes and repays them the first time someone asks why.

1. The capability and whether it is differentiating.
2. Three-year TCO both ways, with the assumptions visible.
3. The largest uncertainty in each estimate.
4. The decision and the single fact that most drove it.
5. What would change our mind — the trigger that should prompt a revisit.

That last heading is the one people skip and the one that matters most. Build and buy decisions are not permanent; they are correct for a set of conditions. Writing down which conditions makes the revisit a scheduled conversation rather than a crisis.

If the decision hinges on a cost you cannot yet estimate — model spend on an AI feature, say — that is a costing exercise to run first, not a number to guess at inside the framework.