This is a guide written by a team that builds custom software, arguing that most businesses shouldn't commission any. That isn't false modesty — it's the only way the advice is worth anything. Building when you should have bought is the most expensive mistake in this category, and it's common.
Start from buy, not build
Off-the-shelf software carries an enormous advantage: the cost of building it was shared across thousands of businesses, and so was the cost of finding its bugs. For any problem that is genuinely common — accounting, payroll, email, scheduling, most CRM — a mature product will beat a custom build on cost, reliability and time to value, and it isn't close.
The default should always be to buy. Building is what you do when buying has been genuinely tried and has genuinely failed.
When off-the-shelf genuinely stops working
There are a handful of situations where the default flips. In our experience it's these:
- Your process is the differentiator. If the way you do the thing is the business, forcing it into someone else's workflow erodes the advantage you're paying to protect.
- You're paying for a suite to use one part of it. Common at scale, where per-seat costs multiply across people using a fraction of the features.
- The workaround has become the system. Spreadsheets alongside the software, re-keying between tools, an ops person whose job is moving data. That labour is a real recurring cost.
- Integration is the actual problem. Your tools each work, but nothing talks, and the vendor has no interest in fixing that.
- The roadmap will never reach you. You've asked for the thing you need; it isn't coming.
One of these on its own usually isn't enough. Two or three together generally is.
The four costs people underestimate
A build needs sustained decisions from whoever knows the process. That person is usually busy running it. This is the most commonly missed cost of all.
New software means retraining and a temporary dip in productivity, whatever it's replacing. Budget for it rather than being surprised.
Software isn't a project that ends. Businesses change and the system has to follow. Ask what continuing support costs before you start, not after.
Getting existing records in, clean and reconciled, is routinely underestimated. Messy source data is normal, not exceptional.
Ownership, data and lock-in
The genuine advantage of a build is that the result is yours. No per-seat bill that grows with headcount, no vendor deciding your roadmap, and your data in a structure you chose rather than one you inherited.
But ownership only means something if it's written down. Make sure the agreement is explicit about who owns the source code, where it's hosted, who holds the credentials, and what happens if you and your developer part ways. A build you can't take elsewhere is just lock-in with extra steps.
Build, configure, or integrate
A surprising number of "we need custom software" conversations end at integrate. Connecting a POS, an accounting package and a CRM so data flows once is frequently the whole problem, and it's a far smaller job than a rebuild. That's also the shape of most automation work — making systems you already own talk to each other.
Scoping a first version
The failure mode of custom projects is scope: a year of building before anyone uses anything, by which time the requirements have moved. The antidote is to ship something genuinely useful early, then extend.
Pick the single workflow that hurts most. Build that, properly, and put it in front of the people who do the job. What you learn from three weeks of real use will reshape the rest of the plan more usefully than any amount of upfront specification.
What good delivery looks like
- You see working software regularly, not status reports.
- Scope is agreed in writing and changes are priced when they're requested.
- Someone who understands your business is in the conversation, not only developers.
- You get the credentials, the code and the documentation as you go — not at the end, if you ask.
- Support after launch is defined before launch.
Questions to ask a developer
- Should we be building this at all? A developer who never says "buy this instead" is selling, not advising.
- Who owns the code and the data, in writing?
- What does the first usable version look like, and when?
- What happens if we stop working together?
- What does ongoing support cost, and what does it include?
- Who will actually be building it — and can I talk to them?
FAQ
Upfront, almost always. Over several years it depends on what you'd otherwise pay in per-seat licensing and in the manual labour created by a poor fit. The comparison only becomes meaningful when you price both sides over the same period.
If the answer is "a year", push back. A well-scoped first version targeting one workflow should reach real users far sooner, with everything else built on top of what that use teaches you.
That's a question about how it's built and who can maintain it. Conventional technology choices and documented code mean any competent developer can pick it up. Exotic choices are what make software hard to outgrow safely.
Usually, and it's often the better answer than replacing anything. If your systems each work but don't share data, integration solves the real problem at a fraction of the cost of a rebuild.
Tell us the workflow that's hurting. We'll tell you whether it's a build, a configuration, or an integration — and if an off-the-shelf product does it better, we'll name the product.
Book a discovery call