Build vs buy: when DIY beats SaaS at scale
Build-vs-buy isn't a values debate, it's a breakeven date. SaaS wins early because it converts a big upfront build into a small monthly fee. DIY wins once your usage-based SaaS bill exceeds the fully-loaded cost of owning the code — typically around month 18 for infrastructure-style tools. This piece gives you the formula, a worked example, and the three traps that make teams build too early.
On this page
"Should we build it or buy it?" gets argued like a philosophy. It's actually arithmetic. There's a date — a breakeven month — where the cumulative cost of buying crosses the cumulative cost of building. Before that date, buying is cheaper. After it, building is. Everything else is storytelling.
The mistake teams make isn't picking the wrong side. It's never computing the date, then either building too early (and eating opportunity cost) or buying too long (and overpaying a usage-based bill that scaled past the point of sense).
Quick answer
Buy when you're small or uncertain: SaaS turns a large upfront build into a small, cancellable monthly fee, and that optionality is worth a lot early. Build once your usage-based SaaS bill durably exceeds the fully-loaded cost of owning the code — not just the engineer-hours to write it, but maintenance, on-call, and opportunity cost. For infrastructure-style tools that breakeven typically lands around month 18. Compute your own date before you argue about it.
The formula
Let:
- B = upfront build cost (engineering hours × fully-loaded rate)
- M = monthly cost to maintain what you built (on-call, patches, ~15–25% of build cost annualised)
- S = current monthly SaaS bill
- g = monthly growth rate of that SaaS bill (usage-based plans grow with you)
You build when the cumulative cost of owning drops below the cumulative cost of buying. The naive single-month version is simply: build when S > M and you can amortise B over the time you'll keep the system. The honest version accounts for the SaaS bill growing while your maintenance cost stays roughly flat.
A worked example
You're paying $4,000/month for a managed service. The bill is growing ~6% a month as you scale. A senior engineer at a fully-loaded $14,000/month says they can build a replacement in 3 months (so B ≈ $42,000) and maintain it for about 20% of that per year (M ≈ $700/month).
Scroll to see more
| Month | Cumulative buy (6% growth) | Cumulative build (B + M) |
|---|---|---|
| 0 | $0 | $42,000 |
| 6 | $27,900 | $46,200 |
| 12 | $61,400 | $50,400 |
| 18 | $108,500 | $54,600 |
| 24 | $172,000 | $58,800 |
The lines cross between month 12 and 18. Before that, buying is strictly cheaper and lower-risk. After month 18, the SaaS bill's compounding growth makes owning the code dramatically cheaper — by month 24 you've saved over $110,000 versus continuing to buy.
Notice what drives the crossover: it's not the build cost, it's g, the growth of the SaaS bill. A flat $4,000/month bill that never grows might never cross. A usage-based bill compounding at 6% crosses fast.
The three traps
Trap 1 — Undercounting the fully-loaded build cost
The build estimate is always the optimistic one. Real B includes design, testing, the integration glue, documentation, and the two-month tail of "it's done except for the edge cases." Multiply the engineer's first estimate by at least 1.5×. And M is not zero — software you own is software you maintain forever.
Trap 2 — Ignoring opportunity cost
The engineer building your replacement billing system is not building your product. If those three months could have shipped a feature that moves revenue, the true cost of building includes the revenue you didn't earn. For core-product work, opportunity cost usually says buy so your team stays on the thing customers pay for.
Trap 3 — Building a commodity
If the thing is a solved commodity — auth, email delivery, payments — building it almost never beats buying, because vendors amortise their build across thousands of customers and you can't. Build the thing that's core and differentiating; buy the thing that's necessary but generic. The build-vs-buy date only favours building when you'd also keep the system long enough to bank the savings.
A simple decision rule
- Is it core to your differentiation? If no → buy (and stop here).
- Is your SaaS bill growing faster than ~4%/month? If no → probably buy.
- Compute the breakeven month with the formula above, using a 1.5× fully-loaded build estimate.
- Will you still run this system well past the breakeven month? If yes → build. If you're not sure → buy and keep the option open.
The same discipline applies to your own pricing: if you sell a usage-based plan, you are the SaaS bill on someone else's build-vs-buy spreadsheet. Make sure your pricing ladder still wins their arithmetic at scale, or you'll train your best customers to leave.
Math check: with a SaaS bill of $4,000/month growing 6% monthly, cumulative spend by month 18 is about $108,500; a $42,000 build plus $700/month maintenance totals roughly $54,600 over the same window — a ~$53,900 swing in favour of building, but only if you keep the system past month 18.
Sources
- a16z, "Build vs. Buy" framework essays (2023–2024).
- Gartner IT cost-optimization guidance on total cost of ownership (2024).
- BudgetForge analysis of 25 infrastructure migration case studies (2024–2026).
Written by
Camille ForsterCamille Forster writes about pricing and unit economics for founders. Ex-RevOps, recovering spreadsheet maximalist.
Frequently asked questions
What's the single biggest driver of the build-vs-buy breakeven?
The growth rate of your SaaS bill. A flat bill may never cross; a usage-based bill compounding at 5–6% a month crosses the build line quickly because your maintenance cost stays roughly flat while the bill keeps climbing.
How should I estimate the build cost?
Take the engineer's first estimate and multiply by at least 1.5× to cover testing, integration, docs and edge cases, then add ongoing maintenance at roughly 15–25% of build cost per year. The optimistic estimate is almost always wrong on the low side.
When should I almost never build?
When the thing is a solved commodity — auth, payments, email delivery — or when it isn't core to your differentiation. Vendors amortise those builds across thousands of customers; you can't.
Does opportunity cost change the answer?
Often. Engineers building a replacement aren't building your product. For core-product teams, the revenue you forgo while building usually tips the decision toward buying.
Related reading
True cost of running an LLM workflow in 2026
The sticker price per token is the smallest line in your LLM bill. Once you add retries, embeddings, vector reads, orchestration, and the platform margin, a "simple" agent workflow lands around $0.42 per run — roughly 4× the raw model cost. This breakdown shows where the money actually goes and which three levers cut a workflow bill the fastest without touching quality.
Effective hourly rate: the only freelance metric that matters
Your headline rate is a vanity number. Your effective hourly rate — total income divided by every hour the business consumed, billable or not — is what you actually earn. For most freelancers it lands 35–55% below the rate on their invoice once you count admin, sales, and unbilled rework. This piece shows how to compute it, why it's always lower than you think, and the three moves that raise it without raising your rate.