Most build-vs-buy advice is written by people who sell one of the two options. This is a scoring rubric instead: ten questions, weighted, that produce a recommendation — and three of them are weighted against building, because most of your software stack should stay bought.
Answer them about one specific tool, not about your business in general. The right answer is almost never "replace everything."
How the scoring works: seven questions add points when the answer is yes; three subtract them. A total of 10 or more is a clear case for building, 5–9 means build carefully and start small, 1–4 means go and measure, and zero or below means keep paying.
The ten questions
Does the bill grow when you hire, without the value growing too?
Per-seat pricing indexed to headcount rather than usage is the single strongest argument for building.
+3 if yes
Is the workflow that matters most to you the one the tool handles worst?
Generic products are strongest at generic work. If your differentiator is the awkward part, that gap will never close.
+3 if yes
Does a spreadsheet, manual export or specific person exist purely to patch a gap?
That workaround is a running labour cost, and it is usually a precise specification of what should have been built.
+3 if yes
Is a feature you need gated behind a plan costing 2x or more per seat?
Tier jumps multiply across every seat for the sake of one capability. This is where subscriptions get expensive fastest.
+2 if yes
Would you struggle to get your own data out in a usable shape today?
Lock-in is a real cost even if it never appears on an invoice. It also gets worse every month you wait.
+2 if yes
Has the vendor raised prices or removed a feature you relied on in the last two years?
Past behaviour predicts future behaviour. Building converts an unpredictable cost into a fixed one.
+2 if yes
Is the process stable — roughly the same in two years as it is today?
Custom software fits a process precisely. If the process is still changing weekly, buy flexibility instead and revisit later.
+2 if yes
Is the tool regulated, compliance-heavy, or a network you need others to be on?
Payroll, tax, payments and anything requiring other companies to participate should almost always be bought.
-4 if yes
Is the total annual cost under about $2,500?
Below this, even a smooth build rarely pays back within a sensible horizon. Cheap tools that work are not a problem to solve.
-3 if yes
Would you struggle to name the five screens the replacement needs?
If the requirement is not yet clear enough to sketch, the project is not ready — regardless of the economics.
-3 if yes
Score: 0
Answer all ten to see a recommendation
0 of 10 answered.
Why three questions push the other way
Regulated, compliance-heavy, or a network (−4)
Payroll and tax filing change with legislation and punish mistakes legally rather than commercially. Payment processing carries compliance obligations that take longer to satisfy than the rest of your application takes to build. And anything that requires other companies to be on the same system — EDI, marketplaces, industry portals — is a network you join, not one you build. This is the heaviest weight in the rubric because it overrides good economics.
Under about $2,500 a year (−3)
A $200/month tool costs $12,000 over five years. A replacement costs something similar and carries risk the subscription doesn't. Below this threshold, building has to be justified by something other than cost — usually a capability you genuinely can't buy.
Can't name five screens (−3)
This one catches more failed projects than the other nine combined. If you can't sketch the main screens on a napkin, the requirement isn't understood well enough yet — and a project that starts without that clarity ends over budget with something nobody uses. The fix isn't to abandon the idea; it's to spend a month writing down what actually happens today.
Reading your score honestly
A high score isn't permission to skip the arithmetic. It says the shape of the problem favours building; whether it pays back depends on your real numbers, which is what the break-even calculator is for. And a low score is genuinely useful information — it usually means the cheaper win is trimming unused seats, fixing one integration, or building a small reporting tool alongside the system you keep.
If you scored in the middle, the deciding variable is almost always labour. Track the hours your team spends on workarounds for one month before deciding. That number moves more projects across the line than the subscription cost does — and it's the number the audit template is built to capture.