The honest answer is that it depends, which is useless on its own. So here is the useful version: what the ranges look like, what actually moves them, and how to work out whether the number is worth paying in your case.
We have deliberately not put a single figure at the top of this article. Anyone who quotes one without asking what you need is guessing, and you should treat the number accordingly.
What drives the cost
Almost all of it comes down to five things.
How many distinct processes it covers
One process, done properly, is a small project. The cost rises with the number of genuinely different things the software has to do, not with the number of screens. A system that manages one workflow for three teams is far cheaper than one managing three workflows for one team.
How many systems it has to talk to
Integration is usually the most underestimated line. An API with good documentation is straightforward. A legacy system with a nightly file export, or a product whose API does not expose the field you need, can cost more than the rest of the build. This is worth establishing early, because it is the item most likely to change the shape of a quote.
How complicated the rules are
“Approval required over £5,000” is cheap. “Approval required over £5,000, or over £2,000 for new suppliers, or always for one particular client, unless the regional manager has pre-authorised the category this quarter” is not. The second one is often the real rule, and it is worth writing down before asking anyone to price the work.
Who has to use it, and from where
Internal software for twenty known users is a different proposition from a portal your clients log into. Anything customer-facing raises the bar on accessibility, performance, resilience, and authentication. All reasonable requirements, and all of them cost.
What the data is
Personal data brings UK GDPR obligations. Payment data brings PCI scope. Health or financial data brings more again. None of this makes a project unaffordable, but it is real work and it should be priced openly rather than discovered halfway through.
Rough shapes of project
Ranges, not quotes, and deliberately wide, because the variables above move them a great deal. UK market rates, for work done properly rather than at the cheapest possible day rate.
A single process, replacing a spreadsheet. One workflow, a handful of user roles, simple or no integration, internal users. Typically a few weeks of work. This is the most common sensible starting point and the easiest to justify, because the cost of the current approach is usually measurable.
A connected internal system. Several related processes, real permissions, one or two integrations with existing systems, reporting that someone relies on. Typically a couple of months.
A client-facing application. Everything above, plus external users, accessibility standards, and a higher bar for availability and support. Substantially more, and the ongoing cost is higher too.
A platform. Multiple applications sharing identity and data, built to be extended over years. This is a programme rather than a project, and anyone starting here without having done one of the smaller ones first is taking an unnecessary risk.
If a supplier quotes the bottom of these ranges for the top of the scope, that is not a bargain. It is a misunderstanding that will surface later, usually as change requests.
The cost people forget
Hosting and running it. Modest for most business applications: cloud infrastructure for an internal system is often tens of pounds a month rather than hundreds. It is not zero, though, and it continues.
Support and maintenance. Dependencies need updating, security patches need applying, and browsers change. Budget for this explicitly. Software with no maintenance budget does not stay still; it degrades.
Changes after launch. This is a feature, not an overrun. The business will change and the software should follow. The question to ask a supplier is not whether changes cost money, but how quickly they can be made.
Your own people’s time. Someone internal has to answer questions, test things, and make decisions. This is the cost most often left out of a business case, and the one most likely to cause a delay.
Comparing it against what you pay now
A build is capital; a licence is rent. Comparing them needs a period of years, and three years is usually the fairest.
Work out what the current approach costs annually:
- Licence or subscription fees, at the number of seats you actually pay for
- Time spent on manual steps the software would remove, costed at a rough hourly figure
- The cost of errors you can attribute to the current way of working
- Anything you are paying a person to do purely because the system will not
Then compare three years of that against the build plus three years of running and maintaining it.
Two things usually surprise people. The first is how large the manual-time figure is once it is written down. The second is that the licence line is rarely the deciding factor. It is the time, and the delay, that dominate. We go through this trade-off in more detail in custom software versus off-the-shelf.
How to get a number you can trust
Bring the process, not the feature list. A supplier who understands what the work is can tell you where the cost sits. One given a list of screens will price the screens.
Ask what would make it cheaper. A good answer usually exists: dropping a nice-to-have, phasing an integration, starting with one team. A supplier unwilling to find one is selling scope rather than solving a problem.
Ask what would make it more expensive. The honest risks should be named up front. Integration with a system nobody has seen yet is the usual one.
Get the ongoing cost in writing. Hosting, support, and what a typical change costs after launch.
Ask how soon something could be live. A supplier who can put working software in front of people in the first month is managing the risk properly, which we go into in how long custom software takes.
Start smaller than you think. A first piece of work that proves the approach is worth more than a complete specification that has not met reality. It also gives you a real basis for pricing the rest.
When the answer is not to build
If the process is genuinely standard, a package will be cheaper and that is the end of it. Payroll, accounting, general-purpose email. These are solved, and solved better than a bespoke build would manage.
The case for building is strongest where the process is distinctive, where it is costing measurable time, and where no product fits it without a workaround that somebody maintains by hand. That combination is common, but it is not universal, and a supplier worth using will tell you when you do not have it.
If you are not yet sure which situation you are in, the signs of having outgrown spreadsheets is a more concrete place to start than a budget conversation.