Most comparisons of this compare year one, which is where off-the-shelf always wins. Compare five years — the actual life of a business system — and the picture inverts for a large share of businesses.
The short answer: off-the-shelf makes sense at low headcount and genuinely standard processes. Beyond that, you are renting software that never quite fits, for ever, and paying people to work around the gap.
Here is the arithmetic most comparisons leave out.
The comparison most articles give you
| Off-the-shelf | Custom | |
|---|---|---|
| Upfront cost | Low — often £0 to start | £10,000+ |
| Ongoing cost | Per user, per month, forever | Hosting + maintenance |
| Time to running | Days to weeks | Weeks to months |
| Fit to your process | You adapt to it | It adapts to you |
| Tested by | Thousands of businesses | Your project only |
| Support | Vendor, included | Your supplier, or in-house |
| Changes | Request and hope | Whenever you decide |
| Exit | Export and migrate | You own it |
All true, all insufficient — because it compares the wrong time horizon and ignores the option that most often wins.
The five-year model
Software decisions are not annual decisions. Model five years, because that is roughly how long a business system lives.
Worked example: 25 users, operations system
Off-the-shelf at £45/user/month
| Year | Cost | Notes |
|---|---|---|
| 1 | £13,500 + £8,000 setup | Configuration, migration, training |
| 2 | £13,500 | |
| 3 | £14,850 | Assume 10% price rise |
| 4 | £14,850 | |
| 5 | £16,335 | Another rise |
| Total | £81,035 | Plus workaround labour |
Custom build
| Year | Cost | Notes |
|---|---|---|
| 1 | £45,000 build + £1,200 hosting | |
| 2 | £1,200 + £6,000 changes | |
| 3 | £1,200 + £4,000 | |
| 4 | £1,200 + £4,000 | |
| 5 | £1,200 + £4,000 | |
| Total | £69,000 | You own the asset |
On these numbers custom wins over five years — but change three assumptions and it flips completely:
- Fewer users. At 8 users the product costs around £26,000 over five years and custom will not catch up. Genuinely small teams should buy.
- Headcount falls. Per-user pricing scales down; a custom build does not refund you.
- The product fits genuinely well. Rare, and testable — if you are designing workarounds during a trial, it does not fit.
The conclusion: at 25 users the custom build is already £12,000 cheaper over five years — and you own an asset at the end rather than a renewal notice. Scale up and the gap widens with every seat you add.
The cost nobody models — and it decides the answer
Workaround labour. If a product fits badly, someone spends 30 minutes a day moving data between systems. At a £30,000 salary that is roughly £1,900 a year, every year, plus the errors nobody catches until a customer does.
Over five years that is £9,500 of hidden cost which appears on neither side of a standard comparison. Add it to the off-the-shelf column and the gap widens to over £20,000.
Licence inflation. The 10% rises in the model above are conservative. Vendors reprice at renewal, and your negotiating position weakens every year your data sits inside their system.
This is the most common reason businesses rebuild anyway — three years and £40,000 of licence fees later, having paid for the migration twice.
Modelling it for your own numbers
Run this before deciding anything. It takes under an hour and it settles most arguments.
Step 1 — count the users who need a licence. Including the occasional ones. Products charge per seat whether the seat is used daily or monthly.
Step 2 — get the real per-user price, after year one. Ask the vendor what renewal looks like, and what the last three years of price increases have been. If they will not say, assume 8–10% a year.
Step 3 — add implementation. Configuration, migration, training. Typically £5,000–£50,000 depending on scale, and frequently more than the first year of licences.
Step 4 — add the workaround labour. This is the step everyone skips. Ask the people who will use it how much time they expect to spend moving data between the product and everything else. Multiply by their fully loaded hourly cost (salary × 1.3 ÷ 1,900) and by 52.
Step 5 — project five years with the licence increases compounding.
Step 6 — compare against a build: cost, plus hosting (£300–£4,800/year), plus changes (£4,000–£8,000/year for a mid-size system).
Step 7 — note what you own at the end of each.
Where the arithmetic usually lands: under about 12 users, buy. Between 12 and 30, it depends mostly on fit and on how much workaround labour the gap creates. Above 30, a build is frequently cheaper over five years and always cheaper over ten.
The third option almost nobody proposes
Keep the product. Build only the part that does not exist.
Most businesses convinced they need a full custom system actually need:
- The accounting package they already run — untouched
- Three integrations so systems stop disagreeing
- One custom module for the process no product supports
That typically costs a quarter of a full build and carries a fraction of the risk. You keep the tested, supported, updated product for the 80% that is standard, and build only the 20% that is yours.
Agencies rarely propose this because it is a smaller invoice. Product vendors never propose it because it admits a gap.
If you take one thing from this page, take this: ask every supplier whether a hybrid would work before accepting that a full build is necessary.
The migration cost of changing your mind
Worth knowing before you commit either way, because it is asymmetric.
Leaving a product: export what the vendor permits, in the format they offer. Usually customers, products and transaction history — often without attachments, custom fields or the configuration that encoded your business rules. Expect to rebuild the rules from scratch somewhere else, and expect the export to be less complete than the documentation suggests.
Leaving a custom system: you hold the source, the database and the documentation. A new supplier reads the schema and the code. Nothing is withheld because there is no one to withhold it. Provided the IP and handover were right at the start.
The practical asymmetry: a product can make leaving expensive by design, and has a commercial reason to. A custom system cannot, provided you own it.
Which means: the “safe” choice of buying a product carries a lock-in risk that the “risky” choice of building does not. That is the opposite of how the decision is usually framed, and it is worth weighing.
Test it before you sign. Ask any vendor for a full export during the trial. What comes back — and how readily — tells you what leaving will be like.
Buy off-the-shelf when
Your process is standard and you are willing to adapt. The real question is whether the way you do it is genuinely better or merely familiar. Usually it is familiar, and adopting the product’s way is an upgrade.
You need it working in weeks. Products win decisively on speed.
Headcount is low. Per-user pricing is cheap when there are few users.
Nobody internally can own a build. Custom software needs an owner. Without one it decays.
The requirement is heavily regulated and standard. Payroll, statutory accounts, VAT submission. Products that already handle HMRC compliance have absorbed a cost you do not want to repeat.
Build custom when
The process is a competitive advantage. If how you do it is why customers choose you, encoding it in a product everyone else uses removes the advantage.
No product supports it, and you have checked properly. Not “we looked at two” — properly.
You already have a product surrounded by workarounds. Three apps, a Zapier chain and a daily manual step is the product telling you it does not fit.
Licence costs have become indefensible for the fraction you use. Paying enterprise per-seat pricing for 20% of a product’s functionality at scale.
Integration is the whole point. When the value is in systems agreeing with each other, and the product will not integrate deeply enough.
You need to own it. Strategic systems you cannot afford to have repriced or discontinued by a vendor.
The questions that decide it
Answer these honestly and the decision usually makes itself.
1. Have you genuinely evaluated the products? Three or more, configured as a trial, with your real data. Most “no product fits” conclusions come from a web search and an assumption.
2. Is your process better or just familiar? Ask someone who joined in the last year. They can still see it.
3. What does it cost over five years, including workaround labour? Not year one.
4. Who will own it? Name them. If you cannot, buy.
5. Would a hybrid work? Keep the product, build the gap, integrate properly.
6. What happens if the vendor doubles their price? With a product, you pay or migrate. With a custom build, nothing happens.
7. What happens if your supplier disappears? With a custom build, you need the source code and documentation. This is worth its own question of every supplier.
Signals you have passed the threshold
Specific, observable, and usually present for a year or two before anyone acts.
You are paying for seats that barely use it. Half the licences exist because the system requires a login for something trivial.
There is a spreadsheet alongside it. The product does not handle something, so a parallel record exists. There is always a spreadsheet, and it is always the part that actually matters.
You have added a third-party connector to join two things the product should join. Now you pay for the product, the connector and the workaround.
Someone has “the system job”. A person whose role is substantially moving data between the product and everything else.
You have stopped asking for changes. Not because you have none — because you know the answer. That is a ceiling you have accepted without deciding to.
Your process is described in terms of the software’s limitations. “We do it that way because the system won’t let us do it properly.”
Renewal is a negotiation you dread. You know you cannot leave, and so do they.
Two or three of these is a prompt to run the five-year arithmetic. Four or more and the arithmetic has usually already decided.
Where both go wrong
Off-the-shelf fails when the evaluation was rushed, the product was bought on a demo rather than a trial with real data, configuration was treated as a project rather than a discipline, or nobody budgeted for the workarounds.
Custom fails when the process was automated instead of improved, integration was underestimated, data migration was treated as a task, nobody owned it, or the business changed faster than the software.
Note that almost none of those failures are about the technology. Both routes fail for the same reasons: insufficient thinking before committing.
What you are actually buying in each case
Beyond features, the two purchases differ in kind, and the difference shows up years later.
Buying a product, you are buying
A relationship with a vendor’s roadmap. Features arrive when they decide. The one you need may never come. The one you depend on may be deprecated.
Their pricing power. It increases every year your data sits inside their system, because leaving gets more expensive as you accumulate history and training.
Their security and compliance posture — frequently better than you could build, and genuinely a point in favour.
Their other customers’ priorities. You are one voice among thousands, and the product moves toward the average.
A fixed ceiling. You will find it, and typically at the moment you are growing fastest.
Building custom, you are buying
An asset. It appears on your balance sheet, transfers with the business, and has value in a sale.
Control of the roadmap. Changes happen because you decided, not because enough other customers asked.
Fixed costs instead of scaling ones. The system costs the same at 40 users as at 25.
The maintenance obligation. This is the real trade. Someone must keep it current — dependencies, security patches, platform changes. Budget £3,000–£8,000 a year for a mid-size system, or a retainer.
Dependence on documentation quality. Your ability to change supplier rests on how well the handover was done. Which is why that is worth interrogating hard.
Frequently asked questions
Is custom software better than off-the-shelf?
No, not inherently. Off-the-shelf is better for standard processes, low headcount and speed. Custom is better when the process is a competitive advantage, no product fits, or integration is the point. Most businesses are better served by a product, or by a hybrid.
How much cheaper is off-the-shelf software?
Much cheaper in year one — often £0 to start against £10,000+ for a build. Over five years the gap narrows and can reverse at higher headcount. Model five years including workaround labour, not twelve months.
Can I start with off-the-shelf and move to custom later?
Yes, and it is often the sensible route. Use a product while you learn what you actually need, then build once the requirement is proven. Check the product’s data export before you commit, so leaving is possible.
What is a hybrid approach?
Keeping the product for the standard 80% and building only the custom 20%, integrated properly. Typically a quarter of the cost of a full build with far less risk. Ask every supplier whether this would work before accepting that a full build is necessary.
How do I know if a product genuinely does not fit?
Trial at least three with your real data and real users for two weeks. If after that you are still designing workarounds for the same core process, the gap is real.
Does custom software need more maintenance?
It needs different maintenance. A product is maintained by the vendor and you absorb their decisions. Custom is maintained by you or your supplier, and you control the decisions. Budget £3,000–£8,000 a year for a mid-size custom system, or a retainer from £800/month.
Written by Jas Singh. Last updated 8 October 2026.
