Build vs buy is a cash, time, and focus decision — not an engineering preference.
Teams underestimate maintenance and overestimate build speed. A disciplined TCO comparison usually favours buying anything that is not your product's core.
It belongs in our small business finance growth guide, alongside when buying software is better and why building more features hurts your business. Use the burn rate calculator when you want to model your own numbers.
Cost Comparison
A rigorous build vs buy cost comparison requires modelling both options over a realistic time horizon — typically three to five years — rather than comparing upfront costs alone. Upfront costs almost always favour buying; long-term costs depend on scale, customisation requirements, and how the business evolves.
Cost to buy: Licence or subscription fee (monthly or annual), implementation and configuration cost, integration development cost, training cost, and ongoing subscription escalation. For a mid-market SaaS product, this might be: £800/month subscription + £5,000 implementation + £2,000 integration development = £14,600 in year one, then approximately £10,000 per year thereafter.
Cost to build: Engineering specification and design, development time (at fully loaded engineer cost), QA and testing, infrastructure and hosting, ongoing maintenance, and feature development as requirements evolve. A modest internal tool requiring four months of one senior engineer's time at a fully loaded cost of £95/hour: 160 hours/month × 4 months × £95 = £60,800 in development alone, plus ongoing maintenance of roughly £10,000-£15,000 per year.
In this example, buying saves approximately £47,000 in year one. Even if the subscription cost doubles at renewal and the build option incurs no additional cost, buying is cheaper for several years. The Build vs Buy Software Calculator models this comparison over your chosen time horizon, showing the crossover point — if one exists — where building becomes cheaper than buying.
Time vs Money
Cost comparison captures the financial dimension of the decision. The time dimension is often more important.
A commercial solution can typically be deployed in days to weeks. A custom-built solution takes months at minimum and often longer once the full scope is understood. During that gap, the problem the software was meant to solve either goes unsolved or is handled by more expensive workarounds — manual processes, temporary hires, or spreadsheets that become deeply embedded and harder to replace than expected.
The opportunity cost of delayed deployment is real. A business that waits six months for a custom CRM to be built, when a commercial CRM could have been operational in two weeks, has spent six months without the sales tracking, pipeline management, and forecasting that the system was meant to provide. The cost of that gap rarely appears in the build vs buy analysis, but it is often larger than the direct cost difference.
Time to value is especially critical in early-stage businesses where speed of iteration matters more than perfection of solution. A bought solution that is 85% fit for purpose and operational this week is usually more valuable than a perfectly specified custom solution that will be ready in six months — because the business will learn things in those six months that change what the perfect solution looks like.
Risk Factors
Building carries risks that buying does not:
Scope creep: Custom builds consistently take longer and cost more than estimated. A four-month build becomes seven months. A £60,000 project becomes £95,000. These overruns are so common in software development that they should be treated as the expected outcome rather than the exception in any build cost calculation.
Key person dependency: Custom-built software, particularly internal tools, frequently becomes dependent on the engineer or engineers who built it. When they leave, the codebase becomes increasingly difficult to maintain, extend, and eventually understand. Commercial software does not have this problem.
Maintenance burden: Custom software requires ongoing maintenance that competes with feature development for engineering time. In a small team, maintenance obligations on existing custom tools can consume a disproportionate share of engineering capacity, limiting the team's ability to build new things.
Version lag: Commercial software vendors release improvements, security patches, and new integrations continuously. Custom software gets the improvements the team chooses to build. In fast-moving categories — security, AI integration, API connectivity — the custom solution often falls behind commercial alternatives within two to three years of its initial build.
Worked example: internal reporting dashboard
Buy: BI tool £400/month, 2-week setup, analyst self-serve. Build: 2 engineers × 10 weeks × £4,500/week = £90,000, plus £18,000/year maintenance. Five-year buy ≈ £34,000; build ≈ £180,000 before opportunity cost.
Delay: leadership waits 10 weeks for custom charts; decisions on pricing and churn stay manual. Estimated £8,000 MRR fix delayed — far above licence cost.
They buy, redirect engineers to activation project; payback under two months on delayed MRR alone.
Leadership agrees to re-evaluate build only if the vendor misses SLA or integration requirements twice in a row.
Check results in the startup runway calculator and see are product features worth the cost for related guidance.
What to do next
- Tag the request as core or supporting.
- Estimate build at 2× initial timeline with maintenance.
- Compare five-year TCO with burn and runway tools.
- Run 30-day vendor pilot with success metrics.
- Revisit build only if pilot fails defined criteria.
This article is for general planning and education — not professional financial, tax, or legal advice. Figures are illustrative; check current terms and your own numbers before acting.
Frequently asked questions
What is total cost of ownership?
Build + maintain + integrate + train + opportunity cost — not just sprint points.
When does build become cheaper?
Sometimes year four+ at scale, if vendor fees explode and you have stable requirements — rare for internal tools.
How do we prevent scope creep on builds?
Fixed MVP spec, time-box, and executive sponsor with kill switch.
Is no-code a third option?
Often yes for ops workflows — between buy SaaS and full custom code.
Who should own the decision?
Product + finance on runway impact, not engineering alone.