Build a Build-versus-Buy Presentation Without Treating Development as a Purchase Price

The slide had two numbers on it. Building the equipment-booking tool: 9,800. A vendor's configured service doing the same job: 12,100. Building was cheaper by 2,300, the room agreed, and the meeting moved on to who would staff it.

Neither number was a lie. They just weren't answering the same question. Every figure in this article is an invented placeholder, set up on paper to show the shape of the comparison — nothing here is a quote, an estimate from real work, or a recommendation about what anyone should buy.

The first number is 14 person-weeks of engineering multiplied by 700. The 700 is not on the slide. At 900, the same 14 weeks cost 12,600 and the subscription becomes the cheaper option by 500. The slide's conclusion was decided by a rate nobody in the room could see, and it would flip if that rate changed. That is a real problem, and it is the smaller of the two.

The second problem is what each number buys. The 9,800 buys a first release: software that runs on the day it is finished. The 12,100 buys twelve months of an operated service — the vendor hosts it, patches it, upgrades it and answers the phone between nine and five. One number stops at handover. The other is a year of somebody else's continuing work.

A build-versus-buy presentation compares the same useful capability over the same period, including the obligations that continue on both sides once the acquisition is over. That is the whole method. The rest of this is about applying it without claiming to know more than you do.

Define the capability before you define the software

Start with the job, not the artifact. Name the task, the people who do it, the conditions it has to survive, and the period the comparison covers. In the invented example: about 120 lab staff across three sites reserving shared instruments, over the twelve months from go-live. Sign-in runs through the company's identity provider. A nightly export to the finance system lets instrument time be charged back to departments. Same-day repair is acceptable, so nobody needs overnight cover — a condition that quietly changes how much the built route has to carry.

Then decide what belongs in the comparison and what does not. A dashboard nobody asked for is decoration; leave it out of both columns. The finance export is different. If chargeback is mandatory, an inability to export means nobody can use the capability at all, so it stays in both columns even though neither route has priced it. The test is simple: without this piece, does the thing work? If not, it is not an optional feature, it is part of the capability.

Two things that look like evidence and are not. A working prototype shows that a hard part is feasible; it does not show that the operation runs. A vendor's feature list shows what the product can do in general; it does not show that your configuration of it will fit your sign-in groups and your export format. Both routes still have to be demonstrated against the defined capability, and at this stage neither has been.

Follow each route past the handover

Most build-versus-buy decks stop at the moment the thing becomes available. That is the moment the interesting differences start.

Buying does not hand over every obligation. The vendor hosts, patches and upgrades, and its helpdesk covers business hours. Your organization still administers users, still maps identity-provider groups, still answers the first-line "I can't see my booking" question, and still owns the finance export — which the vendor's product does not provide in the configuration being considered.

Building does not end at the first release. The company hosts, patches, backs up and monitors the application. There is no helpdesk. The same user questions arrive at the people who wrote the code, and they arrive forever, not for the length of a project. When the identity provider changes its connection format, the built route has to be revisited, and so does the purchased one, but in different places and by different people.

The useful split is between transition work and continuing work. Setting up a vendor service is transition work; it happens once. Running either route continues for as long as the capability is needed. If the deck has one row called "cost," the transition figures will be read as the whole story, and the continuing work will look like a rounding error.

GOV.UK's guidance on defining a purchasing strategy, read in September 2026, treats build/buy decisions as including full lifecycle costs — upgrades, improvement and retirement, not just the initial purchase or development. That is UK public-sector technology procurement guidance. It supports the shape of the comparison here; it is not a rule for private organizations, and it says nothing about the right answer in any particular case.

Make the work visible, including the work you cannot price

Existing salaries do not make internal time free. The 14 person-weeks in the example have to come out of somebody's year. Name the work that stops or slips to make room for it, or write down that you do not yet know. "We already pay the engineers" is not a cost argument; it is a way of not having the argument.

Keep the shelves separate. A dated written quote with a defined scope is evidence. A record of the thing operating somewhere, for someone, under conditions you can describe, is evidence. A reasoned guess about internal effort is an estimate, and it should say so on the slide. An unknown is blank, not zero — and a zero on a comparison table is a claim, not an empty cell.

Owning the code does not guarantee the capacity to maintain it. If the two engineers who built the booking tool leave, the capability and the obligation both remain, and the second one is now attached to nobody. That is a dependence on a small number of people, and it belongs in the same conversation as depending on a supplier.

Support offerings rarely include every integration you need. Check what the subscription actually covers before comparing its price to anything: the hours, the channels, the response times, and whether the export your finance team requires is inside the product or project work on your side.

Show control and change as consequences

Control is a real decision dimension. It is not automatically worth any price, and it is not automatically free.

Ask how a change would actually happen. On the bought route, changes that fit inside the product are configuration, and changes that don't are requests whose priority and delivery date the vendor sets. On the built route, changes are made by whoever already holds the work, competing with everything else they hold. There is no external queue to wait in, and there is no external capacity to absorb a busy quarter either.

Ask who decides priorities, and ask what leaving involves. Cancelling a subscription means exporting booking history and rewriting the finance export if it reads the vendor's field names. Leaving a built application means nothing to cancel, plus a decommissioning: archive or migrate the data, unwind the connections, and keep carrying the obligations until that is finished. Both exits have a cost, and only one of them looks like an exit.

Then say why the difference matters for this capability, at this scale. "More control" on its own is a slogan. "We can add a second site's instrument list in a week rather than waiting for a vendor release" is a consequence someone can check.

The same two routes, twelve months wide

Here is the repaired slide. Same capability, same 120 users, same twelve months from go-live, same requirement to export to finance nightly.

What is priced: the vendor's subscription of 9,600 for the year and a 2,500 implementation fee, as quoted in this invented example. What is estimated: the identity mapping and the ongoing engineering attention, both labelled. What is unpriced: the finance export on either route, the hosting for the built application, and the cost of the exit on either side.

Notice what the top line no longer does. The original slide compared 14 person-weeks against a year of operated service. The revised version compares obligations to obligations, and the money that appears is money with a source. The two routes are not declared equal and no winner is announced, because the deck does not yet have the evidence to announce one.

What the repaired slide still does not know

Four gaps, and the deck should name them rather than sum over them: what the finance export costs on either route; whether the three hours a week is anywhere close; whether the identity provider changes annually or more often; and whether the two engineers in the build estimate exist without something else stopping.

That last one is the smallest, and it is the one worth asking first. If the two engineers do not exist without cancelling committed work, the built route is not expensive — it is unavailable, and no rate changes that. It is a question with a short answer that a person can give this week.

This is a way to frame a comparison, not advice about what your organization should procure. Real figures, dated quotes and a named person who has confirmed the availability of the work have to come from your own teams. What the presentation can do before any of that arrives is show the routes at the same width, mark every estimate as an estimate, and put the unknowns on the slide where everyone can see them.

When the rate behind a total is hidden, the total is an opinion wearing a number's clothes. Show the rate, or leave the total off.

Frequently asked questions

Why did the original build-versus-buy slide's conclusion depend on a hidden rate?

The build figure was 14 person-weeks multiplied by 700, but the rate was not on the slide. At 900, the same 14 weeks cost 12,600 and the subscription became cheaper by 500. The conclusion was decided by an invisible rate that would flip it.

What continuing obligations remain on each route after handover?

Buying does not hand over every obligation: the vendor hosts, patches, upgrades and runs a business-hours helpdesk, while the organization still administers users, maps identity groups, answers first-line questions and owns the finance export. Building does not end at first release: the company hosts, patches, backs up and monitors, with no helpdesk, and the same user questions reach the people who wrote the code.

How should internal engineering time be treated in the comparison?

Existing salaries do not make internal time free. The 14 person-weeks must come out of somebody's year, so the deck should name the work that stops or slips, or say it does not know. 'We already pay the engineers' is not a cost argument; it is a way of avoiding the argument.

What should the repaired comparison show about priced, estimated, and unpriced items?

It should compare obligations to obligations and show money with a source. Priced items include the vendor subscription and implementation fee as quoted in the invented example; estimated items include identity mapping and ongoing engineering attention; unpriced items include the finance export on either route, hosting for the built application, and exit costs on either side.

What four gaps does the repaired slide still have?

What the finance export costs on either route; whether three hours a week is close; whether the identity provider changes annually or more often; and whether the two engineers in the build estimate exist without something else stopping. The article says the last is the smallest and worth asking first, because if those engineers are unavailable, the built route is unavailable, not merely expensive.

Further reading

• Build an Internal Decision Deck Around the Choice That Is Still Open — Read this when the comparison is ready but the room still needs to know what it is deciding, who can decide it, and what alternatives the slides support.