Build software only when four conditions hold: the capability differentiates you, nothing on the market fits, a team can run it for years and control needs rule out third parties. Otherwise buy, or buy and extend, after comparing three-year costs in person-months.
Most build vs buy mistakes surface in year three, when the engineer who built the system has left and the maintenance never stopped.
Building your own software is closer to adopting a dog than buying a sofa. The day it arrives is the cheapest day you will have with it, and the commitment lasts for years. This guide gives you a four-condition test, a third option most teams overlook, a three-year cost model and a decision record that keeps the matter settled.
Why build vs buy decisions go wrong
Most errors come from comparing the wrong numbers. Teams set an engineering estimate for version one against a single year of licence fees. Version one is, in practice, the smallest part of the cost of owned software.
Hosting, upgrades, security patches, on-call cover and new feature requests continue for as long as the system lives. Engineers also tend to prefer building, and their estimates are honest but optimistic. Sunk cost then keeps weak internal tools alive long after a good product has reached the market.
The four-condition build test
Build only when four conditions hold together. If any one fails, buying, or buying and extending, usually wins.
| Condition | Question to answer | Points to build | Points to buy |
|---|---|---|---|
| Differentiation | Would customers notice and value it? | It encodes how you win business | It is standard back-office work |
| Fit gap | Does any product fit without heavy compromise? | Tested options fail key scenarios | Two or more options pass your scenarios |
| Stamina | Can you run and secure it for years? | A named team beyond version one | Nobody wants to be on call for it |
| Control | Do data or regulatory needs rule out third parties? | Needs no provider meets in writing | Providers meet them with evidence |
Two examples show the range. An internal expense approval tool rarely passes, because customers never see it and mature products exist. A pricing engine that encodes how the business wins deals often does pass, because the logic itself is the advantage.
The third option: buy and extend
The strongest answer is often to buy the standard core and build a thin layer on top. That layer holds your configuration, integrations or differentiating logic, and you avoid maintaining the plumbing. The risk moves to the platform, so we recommend checking it as carefully as your own code.
- API stability: ask how long old versions remain supported after a new release.
- Deprecation notice: secure the notice period for retiring features in the contract.
- Limits: confirm rate and data volume limits at your expected peak, not today's load.
- Evidence: check that the provider's SOC 2 report (an independent auditor's attestation on its controls) or ISO/IEC 27001 certificate covers the APIs you will rely on.
Compare three years of cost in person-months
Compare like with like over three years, in one unit. Person-months work well, because engineering time is the scarce resource. Convert subscription fees into person-months at your loaded engineering cost.
Count every line. Building carries development, hosting, security work, on-call cover, upgrades and new features. Buying carries subscription growth, integration, administration and renewal increases. Both carry ownership, migration and the cost of leaving.
Consider a hypothetical internal approvals workflow. Version one takes six person-months to build, then 3.5 a year to run, plus a one person-month upgrade in year three. Buying costs two person-months a year in subscription, rising 10% at each renewal. Integration adds 1.5 in year one, and administration adds 0.5 a year.
| Year | Build (person-months) | Buy (person-months) |
|---|---|---|
| Year 1 | 6 build + 1.75 run = 7.75 | 2 + 1.5 + 0.5 = 4.0 |
| Year 2 | 3.5 | 2.2 + 0.5 = 2.7 |
| Year 3 | 3.5 + 1 upgrade = 4.5 | 2.42 + 0.5 = 2.92 |
| Three-year total | 15.75 | 9.62 |
Buying is cheaper here by about six person-months, and the true gap is wider. The build figure comes from engineers who would otherwise improve your product. If the subscription were four person-months a year, the options would be roughly level. The decision would then turn on differentiation and stamina rather than cost.
Weigh the obligations and record the decision
Building makes you a software producer. NIST SP 800-218, the Secure Software Development Framework, sets out the secure development practices your team would be taking on. If you build an AI system, you may become its provider under the EU AI Act, so the prudent course is to involve counsel early.
Buying moves risk rather than removing it. Verizon's 2025 Data Breach Investigations Report found third parties involved in 30% of breaches, double the previous year. A bought system therefore needs evidence, clear data terms and a tested exit.
Write a one-page record of the options, test results, cost assumptions and chosen path. Store it where the next leader will find it, and name the triggers that would reopen it:
- Price: a renewal increase above an agreed level.
- Provider: an acquisition or a retired product line.
- Market: a product now covers your key scenarios.
- People: the owning team loses those who understand the system.
The bottom line
Conclusion
Adopting a dog is a fine decision when you have the time and the years to give it. Building software is the same. It is right when the capability is genuinely yours, nothing on the market fits and a team will still own it in year three.
The four-condition test, the buy-and-extend option and a three-year model in person-months turn an opinion contest into a decision you can defend. This week, choose one internal tool your team maintains and estimate its yearly running cost in person-months.
Frequently asked questions
When does it make sense to build software in-house?
When the capability differentiates the business, tested products fail key scenarios, a named team can run and secure it for years, and data or regulatory needs rule out third parties. All four should hold.
What costs are usually missed in build vs buy comparisons?
On the build side, maintenance, security work, on-call cover, upgrades and the opportunity cost of engineers. On the buy side, integration, administration, renewal increases and the cost of leaving.
What does buy and extend mean?
Buying a standard product for the core and building a thin layer of configuration, integrations or logic on top. It keeps differentiation in-house without maintaining commodity plumbing.
How long should a build vs buy cost model cover?
Three years is a sensible minimum, because version one is the smallest part of the cost of owned software. A sensitivity check shows which assumption would change the answer.
How do I stop the build vs buy debate restarting?
Keep a one-page decision record with the options, test results, cost assumptions and explicit review triggers, such as a large renewal increase or a change in the owning team.
References
- Verizon, 2025 Data Breach Investigations Report (press release)
- Secureframe, SOC 2 Trust Services Criteria explained
- ISO, ISO/IEC 27001 Information security management
- NIST, SP 800-218 Secure Software Development Framework (SSDF) Version 1.1 (February 2022)
- EUR-Lex, Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), Annex III (2024)
Disclaimer: General information only, not legal, security, compliance or financial advice. Check the cited sources and seek professional advice. Names belong to their owners; no endorsement implied.