Build vs buy: a founder's guide to the decision that compounds
Most founders build the part they could have bought and buy the part that should have been their moat. How to draw the line, price the real cost, and decide.
Key takeaways
- Build only what customers would notice and miss; buy everything they would never see.
- Maintenance, not the original build, is roughly 60% of what software costs over its life — price any build at about 1.5× the quoted effort before deciding.
- AI has cut the cost of writing code, not the cost of owning it — price maintenance exactly as you would have before.
- Lock-in is a price, not a curse: it is acceptable when your data is exportable and switching is measured in weeks.
Ask a founder why they built their own admin dashboard and you'll hear a version of the same answer: the off-the-shelf option didn't quite fit, and it looked like a couple of weeks of work. It usually was a couple of weeks of work. That's not the expensive part.
The expensive part is that you now own it. Forever. Every framework upgrade, every security patch, every new hire who has to learn it, every time it breaks at 11pm on a Friday. Across the industry, maintenance — not the original build — accounts for roughly 60% of what a piece of software costs over its life, with credible estimates ranging from 40% to 80%. You didn't buy two weeks of work. You bought a small, permanent tax on your engineering team.
Meanwhile the thing that actually makes your company hard to copy — your matching logic, your pricing engine, your underwriting model, the workflow your customers love — got outsourced to a vendor, wrapped in a no-code tool, or shelved because the team was busy rebuilding Stripe Billing badly. That's the mistake. Not "build" and not "buy", but building the commodity and buying the differentiator.
average budget overrun on large IT projects, which also deliver 56% less value than predicted, across 5,400+ projects studied
share of a software product's total lifetime cost that goes on maintenance rather than the original build (estimates range 40–80%)
median annual SaaS spend per employee in 2026 — and 36% of purchased licences are never used
increase in duplicated code blocks since 2023, across 623 million real-world code changes analysed through the AI-coding boom
Build what customers would miss. Buy the rest.
The only useful test is whether a customer would notice, and care, if you swapped your version for a generic one. Nobody has ever chosen a vendor because their password reset email was elegant. They do choose you because of the thing in the middle that only you understand. Yet the middle is usually where founders run out of engineering time, precisely because it went on the plumbing.
The build is the deposit, not the price
Founders budget for the sprint that ships the feature and never budget for the decade that follows it. Maintenance is roughly 60% of lifetime cost, and most of it isn't bug fixing — it's keeping pace with changing requirements, dependencies and regulations. Large IT projects still overrun budgets by around 45% on average, and the overrun compounds the longer the project runs.
Before approving any build, ask: who owns this in two years, when the person who wrote it has left? If there's no answer, you're not ready to build it.
AI made code cheaper to write, not cheaper to keep
AI has genuinely collapsed the cost of producing code, which makes "we'll just build it" feel more reasonable than ever. But nothing about AI has reduced the cost of owning code. The evidence points the other way: duplicated code blocks are up 81% since 2023 and error-masking patterns up 47% across 623 million analysed changes, while industry research on AI-assisted delivery consistently finds throughput rising alongside instability. Treat AI as a discount on the build only. Price the maintenance exactly as you would have in 2022.
Lock-in is a price, not a curse
Lock-in is the standard argument against buying, and it's usually overweighted. The real question isn't "can I leave?" but "what does leaving cost, and what would it have cost me to never have joined?" Lock-in is acceptable when the vendor is boring, the data is exportable and the switching cost is measured in weeks. It's unacceptable when the vendor owns your customer relationship, your pricing, or data you can't get back out.
The playbook
- 1Draw the moat line this week.
On one page, list every system in your product in two columns: "customers would notice" and "customers would never notice". Be honest — most founders discover the first column has three items and the second has twenty.
- 2Price the ten-year bill, not the two-week build.
For anything you're about to build, estimate the build, then add maintenance at roughly 1.5× the build cost over the life of the system. If the decision flips at that number, it was never a build.
- 3Apply the three questions.
Is it core to your moat? Does it touch data you can't afford to hand over? Could you hire someone who already knows how to run it? Build when the answers are yes / yes / no. Buy on almost any other combination.
- 4Run an exit test before you sign.
Export your data from the tool, today, on the trial. If the export is complete and machine-readable, the lock-in is survivable. If it's a PDF or a support ticket, price that in or walk away.