The build-versus-buy decision is usually made on feeling: frustration with a product that almost fits, or nervousness about the cost of building. Both are poor guides, and they fail in opposite directions — frustrated operators overbuild, nervous ones spend years working around software that doesn’t fit.
Here’s a way to decide it on evidence.
Start by pricing the gap
Don’t begin with “what would custom cost.” Begin with what the misfit costs you now, per month, in money.
Work through:
- Staff time on workarounds. Hours per week re-keying between systems, maintaining spreadsheets alongside the platform, or producing reports manually. Multiply by loaded salary cost.
- Revenue you can’t capture. Work not billed because it wasn’t recorded. Extras lost for lack of documentation. Contracts not won because you couldn’t provide reporting a client required.
- Licence and configuration spend on tools you’re working around, including any consultant who maintains that configuration.
- Error cost. Rework, credits, disputes traceable to information being wrong or missing.
- Growth constraint. What you’d have to hire to double volume on the current process.
Most operators who do this honestly are surprised. A four-person team losing six hours a week each to workarounds, plus a modest amount of unbilled work, produces an annual figure large enough to change the conversation.
If the gap costs little, stop here. Buy the closest product, accept the imperfection, and spend your attention elsewhere. Not every irritation deserves a software project.
What off-the-shelf genuinely gives you
It’s worth being clear about what you’d forgo, because “we’ll build it exactly how we want” tends to obscure real advantages:
- Immediate availability. Working next week, not next year.
- Someone else’s maintenance. Security patches, dependency upgrades, browser and OS changes, and — in regulated trades — updates for regulatory change. This is continuous work you would otherwise own permanently.
- Accumulated edge cases. A mature product has absorbed thousands of customers’ awkward situations. Your v1 will not have.
- Support, training, documentation that exists without you writing it.
- Exit. If it doesn’t work, you stop paying. Cancelling custom software means owning an asset nobody maintains.
What custom genuinely gives you
- Your actual process, rather than a process shaped to fit a product.
- The asset model you need — which, for evidence-driven trades, is frequently the thing no platform gets right.
- Integration on your terms, not restricted to a vendor’s connector list.
- Cost that doesn’t scale with headcount. Per-seat pricing punishes growth; a built system doesn’t.
- A defensible position, if your methodology is what clients are buying.
- Control over data and continuity — no roadmap changes, no acquisition, no sunset notice.
The honest cost of building
Vendors quote the build. The costs that follow are what people miss:
Maintenance is permanent. Dependencies age, platforms change, browsers break things, security issues need patching. Budget a meaningful annual percentage of the original build cost, indefinitely, whether or not you add features.
You own support. When it breaks on a Friday afternoon, there’s no vendor to call unless you’ve contracted one.
Change has a cost per unit. With SaaS, features appear. With custom, every change is a project — sometimes small, never free.
Key-person risk. If one developer holds all the context, you have a business continuity problem. Mitigate with documentation, tests, and more than one person familiar with the code.
Opportunity cost. Time and management attention spent on the build isn’t spent on customers.
A rough model: build cost, plus 15–25% of it annually for maintenance, plus a change budget, plus hosting. Compare that against licence cost plus the monthly gap you priced earlier, over five years. The comparison is usually clearer than either side expects — and often points at the third option.
The third option, which is usually right
Configure a platform and build only the missing piece.
Keep the mature product for what it does well — scheduling, invoicing, accounting integration, filing — and build the specific thing it can’t do, integrated via API. An asset register with your compliance model. A client portal. A classification catalogue. A reporting layer.
You get vendor-maintained commodity function and a bespoke competitive edge, at a fraction of full-build cost and risk. The prerequisite is that the platform has a usable API — which is worth checking before you commit to it, and which many buyers never think to ask about.
A decision test
Custom becomes defensible when three or more of these hold:
- The gap costs more than a few thousand a month, measurably.
- The core data model is wrong for your trade, not just the forms.
- Your process is a genuine competitive advantage, not merely habit.
- Per-seat licensing is penalising your growth.
- You’ve evaluated at least three products properly and none fit.
- You can fund maintenance for five years, not just the build.
- Someone internally will own the system and its priorities.
Fewer than three, and you’re likely buying a preference at considerable expense. Point 3 deserves scrutiny: plenty of processes are unusual because nobody ever revisited them, not because they’re better. Encoding those in software makes them permanent.
Frequently asked questions
How much does custom software cost to run? Plan for 15–25% of the build cost per year for maintenance, plus hosting and any support arrangement. Budgeting zero is the most common mistake and produces software that quietly rots.
Can we start with off-the-shelf and build later? Yes, and it’s often the sensible sequence — provided you check the exit path first. Can you export everything, in a usable format, without a fee? Confirm that before you load years of data in.
What if the vendor changes their pricing? It happens, and per-seat models are where it hurts most. Factor a realistic increase into any five-year comparison rather than assuming today’s price.
Is custom software an asset? Financially it may be capitalised, depending on your jurisdiction and accounting treatment — ask your accountant. Operationally, treat it as a liability that produces value: it needs ongoing investment to keep working.
Internal links: #9 field service buyer’s guide, #17 legacy modernisation, #7 MVP cost, /services, /products. External references: your accountant on capitalisation treatment; each candidate vendor’s published API documentation as evidence of the hybrid path. CTA: “We’ll tell you if configuring a platform is the better answer — it often is.” → /contact