The five questions
Q1. Has the workflow been stable for 6+ months without major changes?
Yes → Build risk lower. Engineering hours pay back faster.
No → Defer. Volatile workflows burn rebuild budget.
Q2. Does the team actively work around the SaaS limitations every week?
Yes → High. The workaround tax compounds and is the real cost.
No → The SaaS fits the workflow. Buy.
Q3. Is the recurring cost above $300/month per team using it?
Yes → Build break-even typically inside 12-18 months.
No → Build won't pay back fast enough. Leave it.
Q4. Could a senior engineer rebuild the actually-used 80% of the tool in <60 hours?
Yes → Yes. Scope is real. Move to cost math.
No → Scope is hidden. Either you're using more of the tool than you think, or there's real moat under the UI.
Q5. Would losing the SaaS today put a compliance, payroll, or accounting deadline at risk?
Yes → Critical compliance role. Keep buying. Replacing is the wrong fight.
No → No compliance gate. Free to rebuild.
Scoring
- 4-5 "build" answers: Strong replace candidate. Take it to the six-variable matrix below for the full call.
- 3 "build" answers: Possible candidate. Pull pricing data and re-run the math after one more quarter of stability.
- 0-2 "build" answers: Stay on the SaaS. Rebuild fight isn't worth it.
The full matrix
The rubric triages. The matrix decides. Score each variable independently and count the sides: three or more on the build side is a replace candidate, three or more on the buy side means the vendor is earning its money. A single variable rarely settles it, and compliance is the one row that can veto the other five on its own.
| Variable | Points to buy | Points to build |
|---|---|---|
| Workflow specificity | You use 60%+ of the SaaS features as designed. | You use <20% of features and patch the rest with workarounds. |
| Integration depth | The SaaS is the integration hub for 5+ other systems. | The SaaS is a single-input, single-output node in your stack. |
| Vendor moat | Vendor has unique data, compliance posture, or marketplace. | Vendor offers no moat beyond UI and the API you could call directly. |
| Workflow stability | Workflow changes monthly. New requirements arrive often. | Workflow has been stable for 6+ months and is unlikely to change. |
| Cost trajectory | Annual cost <$3,000 and not scaling with team or volume. | Annual cost >$5,000 and growing linearly with seats or usage. |
| Audit & compliance requirement | Tool is your audit trail for accounting, payroll, or legal. | Tool produces no compliance artefact you cannot reproduce. |
Where this goes wrong
The failure mode we see most often is scoring workflow specificity from the feature list rather than from usage. Teams believe they use most of a tool because they recognise most of its menu, and the honest number lands closer to 20% once someone actually checks what fires in a normal week. The second failure is treating cost trajectory as today's invoice, when the variable that matters is the slope: a $200/month tool growing with headcount is a different decision from a $400/month tool that is flat.
The rubric and the matrix also disagree sometimes, and when they do the matrix wins. The five questions are deliberately coarse so they can be answered on a call without pulling data, which means they miss integration depth and vendor moat entirely. If the rubric says build and the matrix says buy, the rubric missed something.
How to cite
NodeSparks (2026). "Build vs Buy: The Rubric and the Matrix." https://www.nodesparks.com/frameworks/build-vs-buy-rubric. CC BY 4.0.
Related
- Zapier vs n8n vs Make vs custom code — dated platform pricing for Q3.
- The 2026 SaaS Replacement Playbook — the essay both frameworks come from.
Published 2026-06-02. Last updated 2026-09-04.
We replace the SaaS stack and the manual ops work eating your team's time. One custom system, owned by you.