Build vs buy is the most consequential software decision most companies make — and the one they usually make on vibes. We’ve seen mid-sized teams spend eighteen months building what SaaS could have done on day one, and we’ve seen enterprises pay $400k a year for a SaaS that ten engineers could have replaced in a quarter.
Here’s a five-question framework that gets to the right answer faster than any spreadsheet of features. Answer them in order, left to right. The first “no” is your decision.
Question 1 — Does an off-the-shelf solution exist?
Sometimes the answer is genuinely no — you’re building something the market hasn’t solved (yet). More often the answer is “yes, but I haven’t looked hard.” Spend a day doing G2, Capterra, ProductHunt and a few targeted Google searches before greenlighting a build. The 30-minute scan that found a tool already solving your problem is the cheapest 30 minutes you’ll spend this quarter.
Question 2 — Does it cover 80% of your needs?
The 80% rule comes from the fact that no off-the-shelf product fits perfectly. If a SaaS covers 80% of the use case and you can live with the missing 20% (or integrate it via webhooks/API), buy. If it only covers 50% and you’ll be glue-coding around it for months, the “cheap” SaaS just got expensive.
Be honest about the missing 20%. “We’ll just build a small wrapper” is how you end up maintaining a small wrapper for ten years.
Question 3 — Is the total cost lower than building?
Add up the real cost of buying:
- SaaS subscription × expected years
- Integration work (rarely zero)
- Training & change management
- Per-user fees as you scale
- Exit cost (data migration, contract penalties)
Then add up the cost of building:
- Engineering team-cost × estimated months
- Ongoing maintenance (typically ~20% of build cost per year)
- Infrastructure
- Bug-fix tax, security-patch tax
Now compare both numbers over five years, not month one. SaaS often wins year one and loses year three. Custom often loses year one and wins year five. Pick based on the time horizon that actually matches your business.
Question 4 — Is integration realistic?
The dirty secret of SaaS economics is that integration is rarely free. Check:
- Does it expose a real REST or GraphQL API, or just CSV export?
- Are webhooks available for the events you care about?
- Can it talk to your identity provider (SAML, SCIM)?
- Is the data model close enough to yours that mapping isn’t hell?
A SaaS with a closed data model can cost more to integrate than to replace. Walk away.
Question 5 — Will it scale with your roadmap?
Think one year ahead. If your usage triples, does the SaaS pricing triple, or 10x? If you add a workflow the vendor doesn’t support, can you build it on top, or are you stuck waiting for their roadmap? If a competitor offers something you need, can you switch?
Lock-in is the most expensive line item nobody puts in the spreadsheet.
Two cases where the framework reverses
Two situations override the framework and tilt toward custom even when SaaS exists:
- The capability is a competitive differentiator.If owning the workflow IS the moat, build it. You can’t out-compete on something every competitor is buying from the same vendor.
- The data must stay in your perimeter.Regulated industries, certain government work, or sensitive IP — the answer is custom + on-prem (or VPC), period.
How we approach this
We get hired to build software, so it might surprise you that we tell roughly a third of new prospects to buy off-the-shelf instead. The ones who push back and build anyway almost always come back two years later asking us to rebuild it properly. Save the round trip — answer the five questions honestly the first time.
Takeaways
- Run the five-question check before any custom-vs-SaaS decision.
- Total cost over 5 years > total cost month 1.
- Integration cost is rarely zero. Estimate it before deciding.
- Build only when the capability is a moat or the data can’t leave.
