Symentic Technologies

BlogEngineering

Nobody Can Price Your Software From a Blog Post

The ranges in every custom software cost guide are real and useless. Here is how the number actually gets built — and the contract clause that matters more than the price.

Bar split 30/70: the build is 20-60% of a custom software project’s lifetime cost, everything after launch is 40-80%.

Search "how much does custom software cost UK" and you get a page of guides offering a range. £15,000 to £250,000. £30,000 to £150,000. Simple, medium, complex, in a table with three rows.

Every one of those guides is published by a company that sells software development. Including this one.

The difference is what we do with that. We are not going to give you a range, because we cannot price a project we have not scoped, and neither can anybody else with a blog post. What we can do is tell you how a custom software cost gets built, which parts of it a supplier can move without you noticing, and what to look for in the quotes you are about to receive.

If you only read one section, make it the one about who owns the code.


Why every custom software cost range is useless

The ranges are not dishonest. They are just answering a different question than the one you asked.

"How much does custom software cost" is "how much does a building cost". Genuinely, somewhere between a garden office and a hospital. Publishing that range is accurate and tells you nothing, because the cost is not a property of the idea. It is a property of the decisions nobody has made yet.

Two suppliers can look at the same one-page brief, quote £40,000 and £120,000, and both be quoting in good faith. They have not disagreed about the price. They have disagreed about what you meant.

That is the actual problem with buying software, and no amount of comparison-shopping fixes it. What fixes it is knowing which assumptions produce the gap.


There is only one equation

Every custom software cost reduces to one equation. Everything else is detail:

Cost = (people × days) + the price of being wrong + what happens after launch.

Buyers negotiate hard on the first term, ignore the second, and forget the third. The second and third are where the money actually is.

The day rate is the least interesting number

For reference: the median contractor day rate for a software developer in the UK is £525, across 254 advertised rates in the six months to 7 September 2026 — up 5% on the same period last year.

That is what one contractor charges you directly. An agency day rate is not the same unit and should not be compared to it. It carries a developer plus some share of a designer, a tester, someone who talks to you, holiday and sickness cover, the warranty period after launch, and the fact that nobody is billable 100% of the time. A supplier quoting a low day rate has, by definition, either taken people out of that list or is going to need more days.

Day rate is the easiest thing to win a comparison on and the worst single predictor of the custom software cost you end up paying. This is also why offshore rate tables mislead: they compare invoices, not outcomes, and the invoice is not the cost. The cost includes the rework, the overlap hours you lose to time zones, and the number of times a requirement has to be explained.

Days are where custom software costs actually differ

Two firms quoting your feature list can be three times apart on days and both be right, because "done" is not one thing.

What "done" means

Roughly what it involves

Who it's right for

It works when I demo it

Happy path only, one user, no real data, no error handling worth the name

Proving an idea to a room. Genuinely valid. Do not launch it.

It works for a real business

Real data, permissions, error states, backups, one or two live integrations, tested on the devices your customers actually use

Most SMEs, most of the time

It works when we're asleep

Monitoring, uptime commitments, audit trails, compliance, load, a second person who understands it

Anything taking money at 2am, or holding data you'd have to report on if you lost it

The gap between row one and row three is not features. It is the same features, built to withstand different amounts of reality. If a quote does not say which row it is in, that is the first question, and the answer will move the price more than any feature you cut.


The four things that actually move a custom software cost

Notice what is not on this list: how many screens there are.

1. Whether the scope holds still. This is the big one, and there is data on it. Analysis of Standish Group project outcomes for 2020–2024 puts roughly 31% of projects as successful, 50% as "challenged", and 19% as outright failures — numbers that have barely moved despite two decades of agile adoption. Separately, McKinsey's study with Oxford of more than 5,400 IT projects found that every additional year a project runs adds about 15% to the cost overrun. Time is not neutral. A project that drifts does not cost the same amount later; it costs more.

2. Integrations you do not control. Your EPOS. Your payment provider. Your accountant's system. A twenty-year-old database somebody's cousin built. Each one is a third party whose documentation may be wrong, whose sandbox may not match production, and whose support queue you cannot escalate. One unknown integration can cost more than five known screens.

3. Data migration. Everyone forgets this, and it is almost never a small job. Existing data is messy in ways nobody knows about until it is being moved. Duplicate customers, dates in three formats, a "notes" field being used as five different fields.

4. The requirements nobody writes down. How fast, for how many people, available how often, recoverable from what. These do not appear on a feature list and they set the architecture — which means they are extremely cheap to decide at the start and extremely expensive to decide later.


The number the quote does not contain

Here is the part that turns a good purchase into a bad one, and the half of a custom software cost that never appears on the quote.

The build price is not the cost of the software. It is the deposit.

The classic figure — and it has held up uncomfortably well — is that maintenance consumes 40% to 80% of total software cost, making it the most expensive phase of the lifecycle. And the part people misread: enhancements account for roughly 60% of maintenance cost. Most of what you spend after launch is not fixing what broke. It is you wanting the thing to do more, because it works and you can now see what it should have done.

That is not a failure. That is the system succeeding. But it means a custom software cost with a build number and nothing after it is not a budget, it is a down payment. Assume an ongoing line from day one, ask any supplier what it covers and what it costs, and treat a quote with no answer as incomplete rather than cheap.


Fixed price and time-and-materials are pricing different things

Neither one is the honest option. They allocate risk differently, and the right choice depends on how settled your scope genuinely is.

Fixed price

Time and materials

What you're buying

Certainty about the invoice

Certainty about the hours

Who carries the risk of being wrong

The supplier — so they price for it

You

The hidden cost

A contingency you cannot see, built into every line

No ceiling, and no natural pressure to stop

What it does to changing your mind

Punishes it — every change is a variation, negotiated separately, usually at worse rates

Absorbs it easily, which is also how projects quietly double

Right when

Scope is genuinely settled and small; a defined phase; a replacement for something that already exists

Discovery, anything with unknown integrations, anything where you expect to learn

The trap with fixed price is not the contingency. It is that fixed price makes your supplier's interests point away from yours the moment anything changes — and the Standish numbers say something will. You end up arguing about whether a thing was in scope instead of whether it is the right thing to build.

The trap with time and materials is simpler: nobody is incentivised to finish.

The workable middle, and what we generally recommend: a small, genuinely fixed-price discovery phase that produces a scope and an estimate, then a build priced against that scope with a stated change process. You pay a few thousand pounds to find out whether the project is £40,000 or £120,000 — which is cheaper than finding out in month five.


The clause that matters more than the price

Ask a supplier who owns the code when the project is finished. If the answer is a shrug and "you do, obviously", read the contract.

Under UK law, the author of a work is the first owner of copyright in it (Copyright, Designs and Patents Act 1988, s.11(1)). There is an exception where the work is made by an employee in the course of employment, in which case the employer owns it (s.11(2)). A software development agency is not your employee. Neither is a freelance contractor.

And copyright does not transfer by paying an invoice: "an assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor" (s.90(3)).

Put those together and the position is uncomfortable. Unless your contract contains a written, signed assignment of the intellectual property, the supplier owns the software you paid to have built. You very likely have a licence to use it. That is not the same thing, and you find out it is not the same thing on the day you want to move to another supplier, sell the business, or raise money and have someone do due diligence on it.

Three things to check, in order:

  • Is there an actual assignment clause, in writing, and does it cover source code, designs and documentation — not just "the deliverables"?

  • Is it conditional? "IP transfers on receipt of final payment" is normal and fine. "IP transfers on completion of the support term" is not the same thing.

  • What is not theirs to give? Open-source components and licensed third-party code cannot be assigned to you, and should not be — but you need the list, because a copyleft licence in the wrong place can affect what you are allowed to do with your own product.

This is the same question we tell restaurants to ask their ordering platform about the customer list, and hotels to ask their booking engine about guest data. Who owns the thing you paid for, and can you leave with it? The answer is almost never in the sales deck.


What a quote worth trusting looks like

Not longer. Clearer. It states:

  • The assumptions. Every estimate rests on them. A quote that hides its assumptions has not removed the risk, only your view of it.

  • The exclusions. What is explicitly not included is more informative than what is.

  • Which "done" it is. Demo, real business, or asleep at 2am.

  • Who is actually on it, for how many days, and whether those people exist yet or are being recruited against your project.

  • What happens when something changes — the process, the rate, and who decides.

  • What it costs after launch, and what that covers.

  • The IP position, in a clause, not a sentence in an email.

  • How you leave. Access to source, repositories, infrastructure and data, at any point, without asking nicely.

A supplier who resents these questions is telling you something useful, at no charge.


The short version

The range in every custom software cost guide is real and useless. Your number depends on decisions you have not made — mostly about what "done" means, and how much your scope will move.

Day rate is the weakest signal in the whole process. Days are where quotes actually differ, and they differ because of assumptions, not features. The build price is a deposit; most of the lifetime cost arrives afterwards, and most of that is enhancement rather than repair. Fixed price and time-and-materials are not honest and dishonest, they are different risk allocations, and the wrong one turns your supplier into your opponent halfway through.

And before any of that: check that the contract actually assigns you the copyright, in writing, because the default under UK law is that it does not.


Getting custom software cost quotes and unsure how to compare them? We build custom software for UK businesses — and we run our own products, Stayvieo and FoodCiti, which means we have been on the paying side of every mistake described above. Happy to look over what you have been sent, whether or not we are one of the people who sent it. See what we've built, or tell us what you're trying to do.

Related reading: A channel manager will never win you a direct booking · How much commission do Deliveroo and Just Eat actually charge?

Keep reading