Build-or-buy questions reach your desk long after the teams have formed opinions. One team has already prototyped an internal tool over a weekend; another has sat through three vendor demos and is ready to sign. Both arrive with a spreadsheet that proves their case. Your job is not to pick the better spreadsheet. It's to make a call that still looks sensible in three years, when the people who argued for it have moved on and someone else is maintaining the result.
Why these decisions go wrong
The same failure modes come up again and again:
- Year-one framing. Building looks cheap because the comparison stops when version one ships. Buying looks cheap because the comparison stops at the license price.
- The evaluators are the interested party. The team that would build the thing runs the evaluation, and finds the vendor products lacking. Or the team that wants to stop maintaining something finds every vendor wonderful.
- "We only need 20% of it." True on day one. A year later you need the other 80% too, either from the vendor or from your own backlog.
- Nobody plans the exit. Bought systems accumulate data, integrations and habits. By the time you want to leave, leaving is a project nobody will fund.
- Capability is assumed. The decision to build assumes you can run what you build, on call, for years. The decision to buy assumes someone will own the vendor relationship. Often neither is true.
Start with core and context
Geoffrey Moore's distinction between core and context, set out in Dealing with Darwin, is the most useful first filter. Core is work that differentiates you in the eyes of customers. Context is everything else you have to do well enough to stay in business but that doesn't make anyone choose you over a competitor. Moore's point is that companies should pull resources out of context and put them into core, and that what is core today tends to become context over time.
Applied to engineering, the test is a single question: if a competitor had exactly this capability, would customers notice any difference between you?
- Your pricing engine, if pricing is how you win deals: core. Customers feel the difference.
- Your identity provider, ticketing system or feature-flag service: almost always context. Customers notice only if it fails.
Context isn't unimportant. Some context is mission-critical: payroll, authentication, backups. That's exactly why it often belongs with a vendor whose core it is; for you it would be a side project with a pager.
The trap runs the other way too. Teams sometimes buy something that is genuinely core, then discover that the vendor's roadmap now sets the pace of their differentiation. If the capability is what customers pay you for, you need to control how fast it changes.
Five questions to answer before deciding
Core versus context gives you a default. These five questions test whether the default holds.
| Question | Points toward building | Points toward buying |
|---|---|---|
| Does it differentiate us? | Yes, and we need to change it faster than any vendor would | No, or only slightly |
| How well do available products fit? | Real requirements that no product meets without heavy customization | A product meets the important requirements as it is |
| What does it cost over three to five years? | Lifetime cost of building and running is clearly lower | Lifetime cost of license, integration and administration is lower or similar |
| How hard is it to reverse? | Building keeps options open; the data model is ours | We can export data and leave within a quarter if we must |
| Can we run it? | We have, or will fund, a team to own it for years | We don't, and we'd rather spend engineers elsewhere |
There's a third option the table hides: adopt a mature open-source project. It moves the build cost to zero and keeps the data with you, but not the running cost. You still need people who can upgrade, patch and operate it. Treat it as "build" for the "can we run it?" question and as "buy" for the "how well does it fit?" question.
Dan McKinley's essay Choose Boring Technology is a useful check here. He argues that a company has only a few "innovation tokens" to spend on new, unproven technology, and that everything else should use well-understood tools. A custom-built internal system spends one of those tokens. Make sure it's being spent on something core.
Cost the whole life, not the first year
Here's a hypothetical worked example. Say you need an internal experimentation platform, and a fully loaded engineer costs your company $180,000 a year.
Build: three engineers for six months to reach a usable first version (1.5 engineer-years), then 0.75 engineer-years a year to maintain, extend and support it.
Buy: $60,000 a year in licenses, about 0.5 engineer-years to integrate in the first year, and 0.2 engineer-years a year after that for administration and upgrades.
| Year 1 | Year 2 | Year 3 | Total | |
|---|---|---|---|---|
| Build | $270,000 | $135,000 | $135,000 | $540,000 |
| Buy | $186,000 | $96,000 | $96,000 | $378,000 |
The numbers are invented, but the shape is typical: building usually costs more up front and keeps costing, because maintenance doesn't stop. Two adjustments make the comparison honest:
- Add the opportunity cost. Those 1.5 engineer-years in year one are not spent on the product. Ask what the roadmap would have delivered with them. That's often the deciding argument, and it's the one executives understand best.
- Stress-test the buy side. What happens to the total if the license price rises 30% at renewal, or you outgrow the tier you priced? If buying only wins under the vendor's current price, it doesn't really win.
Show ranges, not single numbers. "Building costs $450,000–650,000 over three years; buying $350,000–480,000" is more honest and easier to defend than a precise figure everyone knows is a guess.
Plan the exit before you sign
Every bought system you depend on is a system you may one day need to leave. The time to make leaving possible is before signing, when you still have leverage.
- Data. Confirm in the contract that you can export all your data, in a documented format, at any time and at contract end. Then actually try an export during the trial.
- Contract terms. Look at renewal price caps, notice periods and what happens if the vendor is acquired. A short initial term with an option to extend is often worth a higher price.
- Integration layer. Where switching is a real possibility and the integration touches many services, put a thin interface of your own in front of the vendor. Don't do this everywhere: every wrapper is something you build and maintain.
- An exit estimate. Write down roughly what it would take to leave: weeks of work, which teams, which data. If nobody can answer, you don't understand the dependency yet.
For build decisions the exit question is different but just as real: what would make you replace this with a product later, and who would decide?
Run the evaluation so it can be trusted
How you evaluate matters as much as the criteria.
- Write the requirements before seeing demos. Rank them into must-have and nice-to-have. Demos are designed to make you want features you didn't need.
- Put someone neutral in charge, or pair the team that would build with someone from a team that would only consume the result.
- Time-box it. Two to four weeks is enough for most decisions. An evaluation that runs for a quarter has usually become a way of not deciding.
- Prove it with your own data. Run a short proof of concept on a real use case, not the vendor's sample data.
- Talk to existing customers at a similar scale, without the vendor on the call. Ask what they'd do differently and what support is like at 2 a.m.
Write the decision down
Use a short decision record, in the spirit of the architecture decision records many teams already keep. It costs half an hour and saves the argument from being reopened every time someone new joins.
Decision: Buy / Build / Adopt [capability]
Date and owner:
Core or context: one sentence on why
Requirements: must-haves (ranked), nice-to-haves
Options considered: at least one build and one buy option
Three-to-five-year cost: ranges for each option, incl. opportunity cost
Exit: how we would reverse this, rough effort
Who runs it: owning team, on-call or vendor contact
What we're giving up:
Revisit when: specific triggers (below)
Decide what would change your mind
Build-or-buy decisions are not permanent, and pretending they are is how organizations end up maintaining a homegrown system long after good products appeared, or locked into a vendor long after they outgrew it. Set revisit triggers when you decide, so reopening the question is routine rather than political:
- The license cost passes a set threshold, or the vendor is acquired.
- Maintenance of a built system takes more than a set share of the owning team's time.
- A product appears that meets all the must-haves.
- The capability moves from context to core, or the other way around, because the strategy changed.
Review the list once a year alongside your technical strategy, so build-or-buy calls stay connected to what the organization is actually trying to win at.
Before you decide
Ask yourself one question: in three years, who will be maintaining this, and will they thank you? If the answer is "a team that would rather be working on the product", buy it. If it's "the team that makes us different, and they'll want full control", build it. If you can't name anyone, you're not ready to decide.
Build versus buy is one of the architecture and strategy areas covered in the PTME study guide, alongside total cost of ownership and vendor risk.