How do you make a build-vs-buy decision for a significant capability, and which factors are most often underestimated?
answer
- core vs context; commodity → buy
- TCO over 3–5 years, not year-one licence
- opportunity cost is the missing number
- exit cost + data gravity, not lock-in fear
- anti-corruption layer + dated decision record
basics
~20 sBuild only what differentiates you from competitors; buy or use open source for everything else. Compare total cost over several years — not just licence versus salary — including integration, operations, upgrades, and the cost of switching or exiting later.
solid answer
~50 sStart by classifying the capability: is it a competitive differentiator that customers pay for, or undifferentiated plumbing (auth, billing, email, observability, feature flags)? Differentiators are candidates to build; commodity is bought or adopted from open source. Then compare total cost of ownership over three to five years on both sides: build includes design, delivery, on-call, security patching, upgrades, documentation and the opportunity cost of the team not building product; buy includes licence or usage fees at projected scale, integration and data-migration work, customisation limits, vendor operational risk, compliance and data-residency review, and exit cost. Weigh time-to-value, since buying usually wins on speed. Manage lock-in with an anti-corruption layer and a documented exit path rather than by refusing to buy. Prefer reversible experiments, and revisit the decision when scale, price, or the strategic value of the capability changes.
go deeper
Say build what makes you different, buy the rest, and compare full ongoing cost rather than just the purchase price.
Add concrete TCO components on both sides, time-to-value, and lock-in mitigation via a wrapper interface and data export.
Bring in core-vs-context classification, opportunity cost, the 90%-fit problem, vendor and compliance risk, exit cost, and a dated decision record with review triggers.
Position it as portfolio capital allocation: where engineering attention creates advantage, evolution stage of the capability, contract levers, organisational capacity to operate, and the governance that forces periodic re-evaluation.
### Framing the question correctly The real question is not "can we build it?" (usually yes) but **"is this the best use of our scarcest resource — engineering attention — for the next three years?"** Every capability you build is a capability you must also operate, secure, upgrade, document and staff forever. Useful classifications: - **Core vs. context** (Geoffrey Moore): *core* activities differentiate you and win customers; *context* is everything else that must merely be done well enough. Invest engineering in core; buy or outsource context. - **Evolution stages** (Wardley mapping): genesis → custom-built → product/rental → commodity/utility. Building something already at commodity stage (identity, mail delivery, object storage) is almost always value-destroying; building something at genesis stage is where advantage comes from. - **Differentiating vs. table-stakes**: would a customer ever choose you because of this capability? If not, it is not worth bespoke code. ### The comparison Do a **total cost of ownership (TCO)** comparison over a realistic horizon (3–5 years), not a first-year licence-versus-salary comparison. **Build costs, commonly underestimated** - Initial delivery, and the standard optimism factor on estimates. - The long tail: edge cases, admin UI, reporting, audit logs, migrations, internationalisation. - Run cost: on-call rotation, incident response, capacity, dependency upgrades, vulnerability patching. - Documentation, onboarding and the **bus factor** — one person who understands it is an availability risk. - **Opportunity cost**: the product features not built while the team built plumbing. Usually the largest single number and the one most often left out. **Buy costs, commonly underestimated** - Pricing at *future* scale, not today's — per-seat, per-event and per-GB pricing can grow superlinearly with success. - Integration and data migration, plus ongoing sync/consistency work. - The **90% fit problem**: the last 10% of requirements may be impossible, and workarounds around a rigid product often cost more than the product saved. - Vendor risk: acquisition, price changes at renewal, end-of-life, outages you cannot fix, support quality, regional availability. - Compliance: data residency, sub-processor review, certification requirements, security questionnaires. - **Exit cost**: can you get your data out, in what format, how long would a switch take? ### A third and fourth option The question is rarely binary: - **Adopt open source and self-host** — no licence, full control, but you own operations and security; effectively "buy the code, build the operations". - **Buy and extend** — use the product for the common 80% and build only the differentiating extension on top, behind your own interface. - **Compose** — assemble several managed services with thin glue. ### Reducing regret - **Anti-corruption layer**: wrap the vendor behind an interface expressed in *your* domain language, so the vendor's model does not leak across your codebase. This makes replacement a bounded project rather than an archaeology exercise. Do not over-abstract — a wrapper that reproduces the vendor's full API surface buys nothing. - **Data ownership**: keep the system of record and a continuous export where feasible; the biggest lock-in is usually data gravity, not APIs. - **Reversible experiments**: run a timeboxed proof of concept against your real data and real load profile, with pre-agreed success criteria, before signing multi-year terms. - **Contract levers**: price caps at renewal, exit assistance, data-export clauses, escrow for critical vendors. - **Decision record**: write down the decision, the assumptions (scale, price, requirements) and a review trigger. Build-vs-buy decisions expire when assumptions change — a decision correct at 10k users can be badly wrong at 10M. ### Signals it should be a build - The capability is a genuine differentiator, or the *way* you do it is. - No product fits without contorting the domain. - Data sensitivity or latency makes an external service infeasible. - Vendor pricing at your scale exceeds a small team's fully loaded cost, and the capability is stable and well understood. ### Signals it should be a buy - The capability is regulated, commoditised, and boring (payments, identity, tax calculation, email, SMS, log storage). - Time-to-market matters more than fit. - You cannot staff its operation to the required reliability.
- You bought a vendor product and now the last 10% of requirements does not fit. What are your options?Change the requirement if it is not differentiating; extend the product through its supported extension points; build the differentiating slice yourself behind your own interface while the vendor serves the commodity 80%; or trigger a re-evaluation if the misfit is core — using the exit cost you estimated at purchase time.
- How do you decide when to revisit an old build-vs-buy decision?Record the assumptions at decision time — scale, price, requirement fit, strategic value — and attach review triggers such as crossing a usage or cost threshold, contract renewal, vendor acquisition or end-of-life, or the capability moving from context to core.
Companies buy electricity rather than run a generator, even though generators are well understood. You build a generator only if unusual power is your business advantage — or if the grid genuinely cannot serve you.
saying these in an interview costs you the question
- Comparing a first-year licence fee against one engineer's salary and calling it TCO
- Ignoring opportunity cost — what the team would otherwise ship
- Refusing to buy anything because of lock-in, instead of managing it with an interface, data export and exit terms
- Building commodity capabilities like identity, email delivery or payments for no differentiating reason
- Assuming today's pricing holds at ten times the scale
- Treating the choice as binary and skipping open-source self-host or buy-and-extend
- Never revisiting the decision when scale or strategy changes