Off-the-shelf or build your own? An honest way to decide
We turn down work over this regularly. Here is the reasoning we use, so you can apply it before you call anyone.
There is an obvious conflict of interest in a development company writing this. So here is the test we actually use, including the parts that lose us work.
Start by assuming you should buy
Off-the-shelf software is cheaper, available on Monday, maintained by someone else, and has already had its awkward bugs found by other people. That is a genuinely strong position and custom work has to beat it.
Most businesses that think they need something bespoke need one of three things: a product they have not found yet, a process decision nobody has made, or two existing tools connected.
The four questions
1. Does anything off the shelf get you to 80%?
Look properly. Not the first result, not the one with the best marketing — search how your industry actually describes the problem. Trade bodies and forums are better than Google for this.
If something reaches 80%, the real question becomes whether the remaining 20% is worth £15,000 or more.
Sometimes it plainly is. If the 20% is the thing that makes you different from competitors, it is not a rounding error, it is the business.
Often it is not. If the 20% is preference rather than operation, buy the product and adapt.
2. Is the awkward bit the thing you are actually good at?
Every business has one part that does not fit a standard product, and that part is usually the reason customers choose you.
A haulage firm that quotes on a rule nobody else uses. A property manager with a bespoke maintenance arrangement. A contractor whose compliance paperwork is why they win the tenders.
When the awkward bit is your advantage, generic software makes you more average. That is when building earns its price.
3. Do you have the process, or only the wish?
This is where most custom projects fail, and it has nothing to do with software.
If you asked three people in your business how a job gets from enquiry to invoice, would you get three answers? If so, no system will resolve it. It will pick one answer, make it much faster, and the other two people will build a spreadsheet.
Agree the process first. That is free, and it is most of the work.
4. Will you still want this in three years?
Custom software is a commitment. It needs maintaining, a server, occasional attention when a browser or an OS changes underneath it.
If the problem is temporary — a contract that ends, a grant-funded project, a one-off migration — build the cheapest thing that survives it, or do it in a spreadsheet and accept the mess.
The middle ground people forget
It is not a binary. Two options sit between:
Connect what you already have. An enormous number of "we need a system" conversations are really "these two systems do not talk". Integration is usually a fraction of the price of replacing either.
Build the one missing piece. Keep your accounting package, keep your CRM, build only the operational part nobody sells. Smaller, cheaper, and less to maintain.
We suggest one of these more often than we suggest a full build.
When we say no
We turn work down when the problem is organisational rather than technical, when an existing product plainly fits, when the budget cannot produce something worth having — a half-funded system is worse than no system — and when a client wants software to force a change that people have not agreed to. That one never works, and it is a bad way to spend twenty thousand pounds.
If you do decide to build
Start smaller than you think. The most useful first version is the one that replaces a single painful thing — one spreadsheet, one clipboard, one process everyone complains about. Ship that, use it for a month, then decide what is next.
Businesses that specify everything up front usually build a large system around assumptions that turn out to be wrong. Businesses that ship something small and grow it end up with a system shaped by how they actually work.
Worth reading next: what custom software actually costs.