Build vs Buy Software Decision Framework for CTOs
A build vs buy software decision framework that scores reversibility, not just cost. Decide per capability, price the integration tax, and keep an exit.
Stop Arguing About the System. Argue About the Capability.
The meeting always looks the same. Someone opens a weighted scoring matrix with twelve criteria, everyone argues about whether "flexibility" is worth 15% or 20%, and the winner is whichever column the person with the budget wanted to win before the spreadsheet existed. Most of the time, the build vs buy software decision framework in that spreadsheet isn't wrong so much as pointed at the wrong object — it's grading a system when the real decision lives one level down, at the capability.
You do not buy or build "a CRM." You buy contact storage, pipeline reporting, email sync, and a permission model, and then you build the one piece that encodes how your company actually sells. Treat that bundle as a single yes/no and you'll get a defensible-looking answer to a question nobody asked.
Why Most Build vs Buy Software Decision Frameworks Produce Bad Answers
Three structural flaws show up in almost every version of the exercise.
The unit of analysis is too big. Scored as a whole, a system is always a tie: the vendor wins on speed and support, the custom option wins on fit and control, and the weights decide the outcome. Scored capability by capability, the same system usually resolves cleanly — most components are commodity, one or two are not.
The decision is modelled as permanent. Teams argue as if they're choosing forever. They aren't. They're choosing what to do for the next 18 to 36 months and how much it will cost to change their mind. That second number almost never appears in the matrix.
Only entry cost gets priced. Build estimates are scrutinized line by line. The buy column gets a subscription figure and a shrug, as if integration, data migration, admin overhead, and eventual exit were free. They are the majority of the real total cost of ownership, and they are the part that surprises people in year two.
The Three Questions That Actually Decide It
Before any scoring, answer these honestly. They resolve more decisions than the matrix does.
1. Is this capability how you win, or how you operate? If a customer would notice its absence and a competitor couldn't copy it from your marketing site, it's differentiating — build it. Payroll, SSO, invoicing, ticketing and document storage are how you operate. Nobody has ever won a deal because their expense approval flow was bespoke.
Be strict here. Every team believes their version of a commodity process is special. The test isn't "is our process different?" — it's "does the difference produce revenue, margin, or a moat?" Usually the process is different because of an accident in 2019 that a vendor's opinionated default would quietly fix.
2. Does the vendor's roadmap converge with yours? When you buy, you're not buying software. You're buying a dependency on someone else's product priorities. If your next three years of requirements sit on their roadmap, buying is leverage — you get work you didn't pay for. If your requirements are a rounding error in their market, every quarter pushes you further apart, and you end up building on top of the thing you bought anyway, in the worst possible place: their extension model.
3. What does it cost to leave? Exit cost is the criterion that gets skipped, and it's the one that determines how badly a wrong answer hurts. Can you get your data out in a usable shape? Is the integration surface behind an interface you control, or is the vendor's SDK sprinkled through your codebase? Score this before you score anything else.
The Rubric
Run this per capability, not per system. Score each row 1–5 toward whichever column fits, and note that the rows are not equal — differentiation and exit cost outrank the rest.
| Criterion | Points to buy | Points to build |
|---|---|---|
| Differentiation | Customers never see it | It's the reason they choose you |
| Roadmap convergence | Vendor is shipping your next 3 needs | Your needs are off their roadmap |
| Exit cost | Standard data export, thin integration | Deep coupling either way — build the interface first |
| Regulatory surface | Vendor already holds the certifications | Your data residency or audit rules are unusual |
| Integration count | 1–2 well-documented touchpoints | Many systems, custom mappings, bidirectional sync |
| Change frequency | Requirements stable for years | Rules change every quarter |
| Operational appetite | No team to own on-call for it | You already run adjacent services |
| Time pressure | Needed this quarter | Needed this year, and it compounds |
| Volume economics | Small, stable user or event count | Per-seat or per-event pricing scales against you |
Two rows deserve extra attention.
Integration count is the most underestimated line in any build vs buy analysis. Every additional system a bought tool must talk to converts "configuration" into engineering work you own but can't refactor. Bought tools are cheap when they sit at the edge and expensive when they sit in the middle of your data flow.
Operational appetite is where honest teams stop themselves. Building isn't the expensive part; owning is. Custom software means patching, upgrading dependencies, rotating credentials, answering the pager, and keeping someone alive who understands it. If nobody's name goes next to it on day one, you're not choosing build — you're choosing abandonment with extra steps.
The Option Nobody Puts in the Matrix
Framed as a binary, this question has a bad answer built in. The version that survives contact with production is usually neither: buy the platform, build the edge.
Buy the commodity substrate — auth, storage, billing, the generic 80% — and build a thin, well-bounded custom layer that holds your actual logic and talks to the platform through an interface you define. Not the vendor's plugin framework. Your own API boundary, with the vendor behind an adapter.
This costs slightly more than either pure option up front and buys you the thing both pure options lack: the ability to change your mind about one component without re-litigating the whole system. When a vendor doubles their price or sunsets the product, you replace an adapter instead of a platform. We've written before about how agent systems fail when rules live in a prompt instead of the tool layer — the principle is the same one. A boundary you can enforce beats an arrangement you're merely counting on.
Running It in an Afternoon
At Kuaray we do this with clients in a single working session, and it's deliberately unglamorous:
- List the capabilities, not the systems. Break the scope into 8–15 verbs the business needs performed. If a line item is a product name, it's too big.
- Sort them into differentiating and supporting. Force a split. If more than a third land in "differentiating," the team is flattering itself — re-run it with the revenue test.
- Shortlist real vendors for the supporting ones. Not categories. Named products, with their actual API docs open, because the integration surface is the thing you're really evaluating.
- Write the exit plan before signing anything. How the data comes out, in what format, and what code would have to change. If nobody can describe it, exit cost is high — score it that way.
- Score the rubric per capability. Fast. Instinct is fine; disagreement is the signal worth discussing.
- Draw the boundary. Decide exactly where bought ends and built begins, and define that seam as an explicit contract.
- Set a review date. Twelve or eighteen months out, with the specific condition that would flip the decision written down. "We revisit if seat count passes X" beats a vague intention.
The Tie-Breaker
When the score is close — and it often is — pick the option that is cheaper to undo.
That rule is unsatisfying and almost always right. Close scores mean the evidence doesn't favor either path, which means your real risk isn't picking wrong, it's staying wrong for three years because unwinding is too expensive. A reversible mediocre decision outperforms an irreversible good one, because you get to keep deciding as you learn what the requirements actually were.
The corollary: spend your architectural effort on the seams, not the components. Whether you build or buy any given piece matters less than whether the piece is behind an interface you can swap. That's true of the custom software you commission and equally true of the SaaS you sign for, and it's the discipline that makes the next build vs buy software decision framework you run take an afternoon instead of a quarter.
If you're standing this up for the first time and want to see the seam-first approach applied end to end, our MVP approach is built on exactly this: buy everything boring, build the part that's yours, and keep both replaceable.
Talk to Kuaray about your build vs buy decision — we'll run the capability split, score the rubric with your team, and tell you honestly which parts you should not be paying us to build.