Key Takeaways
- Buy for problems every business has; build for the workflow that makes you money differently
- The most expensive option is buying a tool that almost fits, then working around it forever
- The workaround tax — exports, re-keying, 'we track that part in a spreadsheet' — is the tell
- Most winning setups are hybrid: keep your tools, build the connective layer between them
- Custom pays off when one workflow burns 5+ hours a week and no tool matches it
The 80/20 of business software
Every business is 80% standard: invoices go out, appointments get booked, leads get followed up. SaaS exists because that 80% is the same everywhere — and for it, buying beats building every single time. Nobody should custom-build a calendar.
The other 20% is the part that makes you you: how a deal moves from application to funding at an auto finance shop, how recall works at a dental practice, how a GC turns a site visit into a signed change order. That's where generic tools stop fitting — and where the manual hours pile up.
The build-vs-buy question is really: which side of the 80/20 is this problem on?
The workaround tax
The clearest signal you've forced a 20% problem into an 80% tool:
- Someone exports to a spreadsheet to do the "real" work, then re-imports
- Two tools hold the same data and someone reconciles them weekly
- "We use it, but we track the important part separately"
- A step that matters to you has no field, so it lives in the notes column
- You pay for three overlapping tools because each covers a fragment
Each workaround looks small. Together they're the reason a business with six subscriptions still runs on manual labor. When Auto Capital USA came to us they had the tools — the 20–25 hours a week went into the gaps between them. The fix wasn't tool number seven; it was a hub built around how their deals actually flow. Ops time dropped to 3–5 hours.
The decision table
| Situation | Verdict |
|---|---|
| A mature tool matches 90%+ of the workflow | Buy. Adopt its process; don't customize |
| Tool fits, but data must flow to other systems | Buy + build the integration |
| Workflow is your competitive edge | Build. Don't sand your edge down to fit a template |
| Tool would need daily workarounds | Build. The workaround tax never stops accruing |
| The process itself is a mess | Neither yet. Fix the process, then decide |
The math
Custom clears when the workaround tax exceeds the build:
Workaround tax = weekly hours lost × loaded rate × 52
$ example: 6 hrs/wk × $45/hr × 52 ≈ $14,000/yr — every year
Custom build = one-time cost, scoped to ONE workflow
Payback = build cost ÷ annual tax
At 5+ hours a week, payback typically lands well inside a year — and unlike a subscription, the recovered time doesn't renew annually as a cost. Our client results run $36,000–$72,000 a year in reclaimed time; every one of those started as a single scoped workflow, not a platform rewrite.
Where "build" goes wrong (and how not to)
Custom software earned its scary reputation from big-bang projects: eighteen months, everything at once, delivered late, used never. The fix is scope discipline:
- One workflow at a time. Not "an ERP" — the quoting flow. Then the next thing.
- Keep your existing tools where they work; build the connective layer, not a replacement.
- Ship in days-to-weeks, then stabilize against real use.
- Documented handoff — you own it, no lock-in to the builder.
That's the difference between custom software as a risk and custom automation as an ROI line.
Next steps
Find your biggest workaround: the export-fix-reimport ritual, the reconciliation spreadsheet, the notes-column workflow. Price it with the formula above.
If it clears $10k a year, it deserves a real decision instead of another renewal. A free ops assessment gives you the build-vs-buy call for that one workflow, with the scope and payback attached — including the times the honest answer is "just buy X."