"Just buy the SaaS" is correct 80% of the time. The other 20% is where companies quietly lose money — paying per-seat fees that scale faster than revenue, contorting workflows around someone else's data model, and never quite getting the integration to work.
Here's the decision tree we use with clients.
When to buy SaaS
Buy if at least three of these are true:
- The workflow is generic across companies in your industry.
- A category leader exists with clear feature gravity (the next 5 years of roadmap is what you'd build anyway).
- You're under 100 employees — the per-seat math still favours rent.
- The data lives mostly inside that one tool.
- You don't need it to integrate deeply with anything custom.
When to build (or buy + extend heavily)
Build if any two of these are true:
- The workflow is genuinely how you compete — it's not a back-office process, it's the product or the operational moat.
- You're paying more per year for SaaS in this category than one engineer-year of cost.
- The integration tax is so heavy you've already built a shadow system on top of the SaaS.
- The vendor is moving away from your use case (acquired, sunsetting, raising prices aggressively).
- Your data ends up split across the SaaS and your own systems, and the reconciliation work is constant.
The hybrid that usually wins
The most common right answer isn't pure build or pure buy — it's: buy the commodity layer, build the differentiated layer on top of it, and own the data in your own warehouse. Buy the CRM. Build the pricing engine that reads from it. Don't try to make the CRM be the pricing engine.
The mistake we see most often isn't picking wrong on the first decision. It's never revisiting it. Re-run this tree once a year on any system spending more than $50k/yr — the right answer changes as the business changes.