Choose off-the-shelf software when your process is close to how most businesses in your sector work, and consider custom software only when the way you work is part of what customers pay for and no existing tool fits without heavy workarounds. In between, connecting the tools you already have, or keeping a well-run spreadsheet, is often the right answer.
Start with the process, not the software
The question of custom software vs off-the-shelf usually comes up when something hurts: a job system that doesn't match how you quote, three tools that don't talk to each other, or a spreadsheet that's become the business. Before choosing anything, write down the process the software has to support, step by step. If you can't, no software will fix it. Automate a mess and you get a faster mess, and building a mess in code is the expensive version.
Buying is the norm, and for good reason. When DSIT surveyed UK businesses for its AI adoption research, most firms using text-based AI had bought ready-made tools rather than building their own. The same logic applies to software generally: someone else has already paid to build, secure and maintain it.
A simple decision table
| If this is true | Lean towards |
|---|---|
| Your process looks like most firms' in your sector | Off-the-shelf |
| You need it working in weeks, not months | Off-the-shelf |
| The pain is that your tools don't share data | Connect what you have (automation) |
| One person uses it, and the data changes slowly | A well-run spreadsheet |
| Several people edit it live and mistakes cost money | Off-the-shelf, or a small internal tool |
| How you work is part of what customers pay for | Consider custom |
| You've tried two or three tools and all need heavy workarounds | Consider custom |
| You can't describe the process yet | Neither. Map the process first |
Say you run a property maintenance firm with an unusual way of pricing planned works. If a job management tool handles most of what you need, buy it and keep the pricing in a controlled sheet that feeds it. Only if the pricing logic is your edge, and it keeps breaking the tool, does a small custom piece start to make sense.
What drives the cost
Whichever way you go, the price tag on day one isn't the real cost. Watch for:
- Integrations: every system it has to talk to adds build and testing time, and something to maintain.
- Data migration: moving years of records out of spreadsheets and old tools is often the slowest part.
- Users and permissions: who can see and change what gets complicated quickly.
- Change: if your process changes every few months, custom software has to change with it.
- Upkeep: hosting, security updates and fixes for custom builds; per-seat licences that grow with the team for bought tools.
- Ownership: who holds the accounts, the code and the data if you part company with the builder.
When a spreadsheet is fine
A spreadsheet is a perfectly good tool when one person owns it, the structure rarely changes, nobody relies on it being live, and a mistake would be caught before it costs anything. It stops being fine when several people edit it at once, it feeds customer-facing work, or only one person understands the formulas.
The software guides
- 5 spreadsheets that should be software and the 5 that shouldn't: how to tell which sheets to replace and which to leave alone.
- The real cost of running your business on disconnected tools: where the time and errors hide when tools don't share data.
- How to write a brief for a software build: what to put in a brief so quotes are comparable and the build matches the job.
- The 9 numbers every service dashboard needs: what to report on once your data lives in one place. Also in our automation guides.
Or browse all our guides.
Questions people ask
Custom software vs off-the-shelf: which is cheaper?
Off-the-shelf is almost always cheaper to start. Custom can make sense over time only when bought tools need so many workarounds that the hidden cost outweighs the build and its upkeep.
Can I start off-the-shelf and build later?
Yes, and it's often the smart route. Using a bought tool for a while shows you exactly which gaps are worth building for.
What's the in-between option?
Connecting the tools you have with automation, or a small internal tool that sits alongside them. It solves many "our tools don't talk" problems without a full custom build.
Who should own custom software?
You should. Insist the accounts, code and data are in your name, with documentation and a handover, whoever builds it.
Sources
- AI adoption research (GOV.UK (DSIT))