- Start with off-the-shelf. It is cheaper, faster and someone else maintains it.
- The cost that decides this is usually the workaround tax: hours spent every week bridging what your software cannot do.
- Custom starts to pay when the process is a genuine differentiator, or when the workarounds cost more each year than building would.
- Compare three years of total cost, including your own time, not the first invoice.
We build custom software for a living, so read this one knowing that. It still says most businesses should buy rather than build, because most should.
We build custom software, so it is worth saying plainly: most businesses should not. Off-the-shelf software is cheaper, available immediately, maintained by someone else, and improved without you paying for it. For the overwhelming majority of what a small business does, that is the right answer.
But there is a point where a business outgrows it, and the signals are consistent enough to describe. This guide is about recognising that point, and about not reaching it prematurely.
The three options, honestly
| Off-the-shelf | Configured platform | Custom build | |
|---|---|---|---|
| Time to running | Days | Weeks to months | Months |
| Up-front cost | Low | Medium | High |
| Ongoing cost | Per user, forever, and it rises | Licence plus maintenance | Hosting plus changes you choose |
| Fit | You adapt to it | Good within its limits | Exact |
| Who maintains it | The vendor | Shared | You, or whoever built it |
| Main risk | Outgrowing it, price rises | Hitting the platform's ceiling | Cost, and building the wrong thing |
The middle option is the one people forget. A great deal can be achieved by configuring an existing platform properly, and it captures much of the fit of a custom build at a fraction of the cost.
The cost nobody puts in the spreadsheet
When people compare options they compare licence fees. The cost that actually decides it is the time spent every week working around what the software cannot do.
It shows up as exporting to a spreadsheet to do the bit the system does not handle. Re-keying the same information into two places. A weekly report someone assembles by hand. A process everyone knows is wrong but nobody has time to fix.
Five hours a week of workaround, at a fully loaded cost of £25 an hour, is £6,500 a year. Over three years that is £19,500, spent quietly, with nothing to show for it. That is the figure to compare against a build, not the subscription.
The workaround tax is invisible precisely because it is distributed. Nobody spends a day on it. Everybody spends twenty minutes.
When custom genuinely pays
Four situations. If none apply, off-the-shelf is almost certainly still right.
- The process is your differentiator. If how you do something is why customers choose you, forcing it into a generic tool erodes the thing you compete on. Standard processes should use standard software. Distinctive ones may not be able to.
- The workarounds cost more than the build would. Once the annual cost of bridging the gap approaches the cost of closing it, the arithmetic has already changed.
- Per-seat pricing has stopped making sense. Per-user pricing is excellent at five users and punishing at fifty. At some headcount the subscription exceeds what owning it would cost.
- Nothing on the market does it. Genuinely rare, and worth checking hard before concluding. But some businesses do have a real problem nobody has packaged.
Because the existing tool is unfamiliar. Because one feature is missing. Because a competitor built something. Because it feels more professional to own it. None of these survive contact with a three-year cost comparison, and all of them are common.
Work through your own case
Every answer from the questions above, if you would rather read them all at once.
Adopt it, and adapt to it
If you answered: Yes, thoroughly › Close enough to live with
Where your process differs from the software's assumptions without a good commercial reason, change your process. Most small business processes are habit rather than strategy, and the vendor has usually seen more businesses than you have.
Revisit in a year. If you are still working around the same three gaps then, that is real evidence rather than first-week friction.
Configure and integrate before you build
If you answered: Yes, thoroughly › Most of the way, with gaps › Probably
This is the option people skip, and it is frequently the right one. Proper configuration, automation rules and a well-chosen integration close most gaps for a fraction of a custom build.
A small piece of bespoke software that connects two existing systems is also far cheaper than replacing either of them, and it leaves the vendors maintaining the hard parts.
Not yet, but keep measuring
If you answered: Yes, thoroughly › Most of the way, with gaps › No, the gap is fundamental › Under £5,000
At this level the workarounds are cheaper than almost any build, and the pain is not yet strong enough to have taught you exactly what you need.
Keep a simple log of where time goes for three months. If the number climbs, you will have evidence and a much sharper specification. Businesses that build after measuring get far better results than those that build after getting annoyed.
Worth a serious conversation
If you answered: Yes, thoroughly › Most of the way, with gaps › No, the gap is fundamental › £5,000 to £20,000
At this level a focused build can pay for itself within two to three years, particularly if the cost is growing as you do.
Do not replace everything. Find the single most expensive workaround and address only that. Narrow projects succeed far more often than wholesale replacements, and they let you judge the return before committing further.
The arithmetic supports building
If you answered: Yes, thoroughly › Most of the way, with gaps › No, the gap is fundamental › Over £20,000
Over three years you are spending more than £60,000 on working around software that does not fit. That comfortably funds a considered build, and unlike the workarounds it leaves you with an asset.
Still start narrow. Scope the highest-cost part of the problem, ship it, measure the hours it gives back, then decide about the rest. The most common way custom projects fail is being too ambitious at the start rather than too small.
Change the process rather than the software
If you answered: Yes, thoroughly › Nothing came close › Not really, it is just how we do it
If the process is not a differentiator and nothing on the market supports it, the most likely explanation is that the process is unusual rather than that the market has a gap.
Adopting a standard way of working is almost always cheaper than building software to preserve a non-standard one, and it comes with the advantage that new staff already know how it works.
Do that first
If you answered: Not really
Search for tools built specifically for your industry, not just general-purpose ones. Ask others in your trade what they use and what they hate about it. Trial the two or three closest fits with real data rather than a demo dataset.
This costs a week and regularly saves tens of thousands of pounds. It also sharpens your requirements enormously, which makes every later option cheaper.
Compare three years, not the first invoice
Subscription pricing looks cheap in month one and compounds quietly. Custom looks expensive on day one and then largely stops. Comparing them at a single point in time is what produces bad decisions in both directions.
Include all of the following on both sides:
- Licences or build cost, across three full years
- Implementation, data migration and training
- Hosting, support and maintenance
- The workaround tax, which belongs on the off-the-shelf side
- Expected price rises, since per-seat costs tend to grow with headcount and with vendor pricing changes
- The cost of getting out, if you ever need to move
A custom system needs hosting, security updates, occasional fixes and someone who understands it. Budget 15% to 20% of the build cost a year for keeping it healthy. A build that is never maintained becomes a liability faster than most people expect.
If you do build, build narrow
Keeping a custom project out of trouble
0 of 7Try hard to buy. Configure before you build. If you build, build the smallest thing that removes the most expensive workaround, and judge it on hours recovered rather than on how complete it feels.