What does custom software actually cost a small business?
Almost nobody publishes prices for this, which is why everyone assumes it is unaffordable. Here are real figures.
Ask ten development companies what a custom system costs and nine will say "it depends". That is true, and it is also useless. So here are real figures, with the reasoning underneath them.
The short version
| What you want | Typical UK cost | How long |
|---|---|---|
| One focused tool — a form, its records, a dashboard | £3,000 – £8,000 | 2–5 weeks |
| A proper operational system — several screens, users, permissions | £12,000 – £35,000 | 2–4 months |
| That, plus a mobile app for field staff | £25,000 – £60,000 | 3–6 months |
| Integration with accounting, payroll or stock you already run | Add £4,000 – £15,000 | Add 2–6 weeks |
| Ongoing development on a retainer | £1,200 – £4,000 a month | Continuous |
Those are ranges for work done properly by a UK team, not offshore rates and not agency rates with three account managers on the call.
Why the same job gets quoted at £8,000 and £40,000
Four things, mostly.
Who is actually doing the work. A London agency has a sales team, account managers, a project manager and an office. All of that is in your quote before a line of code exists. A small team bills you for building.
Whether anyone understood the job. A quote produced from a one-page brief is a guess with a margin bolted on. The margin exists because the guess is probably wrong. An hour spent understanding how you actually work usually takes more off the price than it adds.
How much of it is genuinely new. Login, permissions, records, search, exports, an audit trail — every system needs these and they are largely solved. If someone is quoting you as though all of it is bespoke, they are either inexperienced or hoping you do not know.
What happens after launch. Some quotes are low because support is not in them. You find out when something breaks.
The three things that move your price most
1. How many different kinds of user
One kind of user is straightforward. Three kinds — office staff, field staff, and customers who log in — is not three times the work, it is more. Every screen needs to know who is looking at it, and every piece of data needs a rule about who may see it.
If you can launch with one kind of user and add the others later, do. It is the single biggest saving available.
2. Whether it has to talk to something else
A system that stands alone is predictable. A system that has to synchronise with Sage, Xero, a payroll provider or a supplier's stock feed is not, because you have inherited someone else's API, their rate limits and their outages.
Integration is not hard, exactly. It is unpredictable, and unpredictable is what costs money.
3. Whether it has to work without signal
If your staff are in basements, lift shafts, fields or plant rooms, the app has to keep working with no connection and reconcile when it comes back. That is genuinely more work — you are building for two states instead of one, and the awkward part is what happens when two people edit the same thing offline.
It is worth it when the alternative is lost paperwork. It is wasted money if everyone is sat in an office on wifi.
When you should not build anything
We talk people out of custom work regularly. It is cheaper for us to say so early than to build something they resent paying for.
Do not build if off-the-shelf nearly fits. If a £40 a month product does 80% of what you need, the honest question is whether the other 20% is worth £20,000. Sometimes it is — that 20% is often the bit that makes you money. Often it is not.
Do not build to fix a process problem. Software makes a good process faster and a bad process faster to go wrong. If nobody agrees how the job is meant to run, no system will settle it.
Do not build for a business you are about to change. If you are mid-acquisition or rethinking the model, wait. Software built for last year's shape is expensive to bend.
How we price it
We quote a fixed number for defined work, and after that most clients move onto a monthly retainer.
The retainer is unlimited development within a fair use policy. In practice that means you ask for things as they come up rather than raising a change request for every tweak, and we build them in priority order. The fair use part exists so the arrangement stays sane at both ends — it is a working relationship, not an all-you-can-eat buffet.
Why we prefer it: the fixed-price model quietly makes us enemies. Every change becomes a negotiation, so you stop asking, and the system slowly drifts away from the business. On a retainer the incentive is the opposite. We would rather you asked.
Worth reading next: how an unlimited development retainer actually works.
What to ask anyone quoting you
- Who writes the code, and are they in the UK?
- What happens after launch, and what does that cost?
- What is not included in this number?
- Who owns the code and the data if we part company?
- Can I speak to a client you built something similar for?
That last one matters most. Any competent firm can name two or three.