The ranges
Most pages on this subject refuse to give a number. That is understandable, because the honest answer does depend on what you are building, but it leaves you with nothing to budget against. So here are the numbers we work to, and what the rest of the UK market tends to charge for comparable work.
- Our smallest engagement: from £4,000
- A first build of a real business system, with us: £8,000–£15,000
- The same brief at a small agency: commonly £25,000–£40,000
- A senior freelance developer: typically £450–£600 a day
"A real business system" means something a team uses every day to run part of the business: tracking jobs or orders, a few different kinds of user, an integration or two, reporting. It does not mean a marketing site, and it does not mean a whole platform. Larger platforms get built in phases, and each phase should be useful on its own, so you are never paying for six months of work before anyone can use any of it.
The agency figure is not a criticism. An agency carries account managers, project managers, designers and several developers, and its price reflects that. Sometimes you need all of those people. Often you do not, and it is worth knowing which you are paying for.
What drives the number
Two briefs that both say "a system to manage our jobs" can be priced very differently, and fairly. The difference is almost never the headline feature. It is the things around it.
- Scope. The number of distinct screens and workflows. Each one needs designing, building, testing and maintaining, and they add up faster than people expect.
- Kinds of user. A system used only by office staff is one product. Add engineers in the field, clients logging in to a portal and subcontractors who should see only their own jobs, and it is closer to three — each with its own view of the same data.
- Roles and permissions. Who can see what, who can approve what, and what happens when someone leaves. Simple rules are cheap. Rules with exceptions ("managers can see everything except payroll, unless they are in the finance team") are where time goes.
- Integrations. Connecting to your accounting package, payment provider or CRM. The happy path is quick. The failure cases — duplicates, retries, the other system being down for an afternoon — are most of the work, and they are not optional.
- Data migration. Moving years of records out of spreadsheets or an old system. Clean data is a script. Real data is usually a project of its own, because the old system allowed things the new one should not.
- Offline or mobile use. Anything that has to work without a signal, on a phone, in a plant room, is harder than a web page on an office desk.
If you want to bring a quote down, those are the levers. Cutting a user type or postponing an integration to a second phase saves far more than trimming screens.
Fixed price or day rate
A day rate is the cost of the developer's time. You pay for the days worked, whatever they produce. It suits open-ended work: support, investigation, working through a backlog whose size nobody knows yet. The risk of the estimate being wrong sits with you.
A fixed price is the cost of an agreed outcome. The supplier writes down what will be built, prices it, and carries the risk if it takes longer. It suits a build with a clear edge, which most first versions of a business system can be given if the scope is written properly.
We work to fixed prices, off a scope agreed in writing before anything is built. The written scope matters as much as the price: it is the thing both sides refer back to when something changes mid-build, and something usually does. A change then becomes a conversation about a line in a document, with its own price, rather than an argument about what was meant.
Comparing the two is harder than it looks. A day-rate quote of "about twenty days" is an estimate, not a price, and estimates in software tend to go one way. When comparing a fixed quote with a day-rate one, ask the day-rate supplier what happens at day twenty-one.
Deposits and milestones
Expect to pay a deposit before work starts. That is normal and it protects both sides: the supplier is not building on trust alone, and you have a clear moment at which the engagement properly begins.
After that, payments should be tied to milestones — points where something you can see and use has been delivered — rather than to dates on a calendar. We take a deposit and tie the remaining payments to milestones on every engagement. A supplier who asks for the full amount up front is asking you to carry all of the risk. One who invoices monthly regardless of progress has no particular reason to reach the end.
What it costs to run
The build is the largest single cost, but it is not the only one. Budget for these as well, and ask any supplier to put figures against them in writing:
- Hosting. Servers, the database, file storage and backups. For a typical business system this is a modest monthly bill, and it should be in your name and on your card, not bundled into someone else's invoice at a margin.
- Third-party services. Email sending, SMS, mapping, document processing, anything metered. Usually small, occasionally not — check the pricing pages of anything the system depends on.
- Maintenance. Security updates, dependency upgrades, the occasional fix. Software that nobody touches for three years does not stay still; the world around it moves and something eventually breaks.
- Change. The business will want things the first version did not do. That is a sign it is being used, and it is worth expecting rather than resenting.
None of those should come as a surprise halfway through the first year.
Getting a number you can trust
The quality of a quote depends on the quality of the brief behind it. A vague brief gets a vague price, or a precise-looking price with a large contingency hidden inside it. Writing a software brief covers what to send so that the number you get back means something.
And before any of this, it is worth checking that building is the right answer at all. For a lot of problems it is not, and a subscription to the right product is cheaper than any figure on this page. Bespoke vs off the shelf is an honest attempt at that question. If it does come out in favour of building, bespoke software is what we do.