“Should we build it or buy it?” is one of the questions clients ask me most, and it’s rarely as simple as the person asking hopes. Buy the wrong SaaS and you spend years fighting its limits; build the wrong thing and you own a maintenance burden that outlives the people who wrote it. Here’s the framework I use to make the call defensible.
Start with one question: is this a differentiator?
The single most useful lens: does this capability differentiate your business, or is it table stakes?
- Differentiator — something customers choose you for, or a process that’s genuinely your edge → lean build (or heavily customize). You don’t want your competitive advantage to be a checkbox a vendor could give everyone tomorrow.
- Commodity — email sending, CRM, auth, payments, HR → lean buy. Building undifferentiated infrastructure is spending your best engineers on a solved problem.
Most things are commodities. Be honest about how few of your capabilities are truly differentiating.
The questions that refine the decision
- Total cost of ownership, not sticker price. Buying has license + integration + lock-in costs. Building has build + maintenance forever + the opportunity cost of the team. Compare over 3–5 years, not at purchase.
- Time-to-market. Buy usually wins on speed. If being live this quarter matters more than perfect fit, that’s a strong signal.
- Fit. How much of your real requirement does the product cover out of the box? 80% with clean extension points is great. 80% with the missing 20% being your core workflow is a trap.
- Team and longevity. Can you maintain what you build, for years, as people leave? A brilliant custom system nobody can maintain is a liability, not an asset.
- Strategic control & lock-in. How painful is it to leave the vendor later? For core capabilities, exit cost is a real risk to weigh.
The middle path most people forget
It’s rarely pure build vs pure buy. The mature answer is often buy the platform, build the differentiation on top:
- Buy the commerce engine, build the storefront experience that’s your edge.
- Buy the marketing platform, build the custom integrations and data logic that make it yours.
- Buy the cloud primitives, build the orchestration specific to your business.
This is exactly the Salesforce-plus-custom pattern I work in every day: standard platforms for the commodity, custom architecture for the parts that differentiate. You get speed and a moat.
The traps on each side
Over-buying: assembling so many SaaS tools that your real system becomes the fragile integration layer between them — which you now maintain anyway, with none of the control.
Over-building: the “we’re special” delusion that leads teams to rebuild commodity infrastructure, then spend years maintaining a worse version of what they could have bought.
Both come from skipping the differentiator question.
How I’d summarize it to a CIO
Buy the commodity, build the differentiator, and be ruthlessly honest about which is which. Decide on total cost over five years, weight time-to-market and fit, and never build something you can’t maintain once the original team is gone.
The build-vs-buy decision isn’t really technical — it’s strategic. It’s about where you spend your scarce engineering capacity and where you’re willing to accept someone else’s roadmap. Get that framing right and the specific answer usually becomes obvious.