Nobody can quote a bespoke software project from a one-line description, and any supplier who does is either guessing or padding. That is not evasion — it is the same reason a builder cannot price a house extension from a photograph of your garden. What a good supplier can do is explain the cost structure precisely enough that you can build a defensible budget and interrogate the quotes you receive. That is what this article is for.
The variables that actually move the number
Cost in software is almost entirely a function of engineering time, and engineering time is driven by a small number of things. Most of them are not the ones clients expect.
Scope, measured in distinct behaviours rather than screens
Clients tend to count screens. Engineers count states. A “user profile page” is one screen and perhaps a dozen states once you account for validation failures, permissions, incomplete data, concurrent edits and the mobile layout. A useful rule when scoping: for every feature, ask what happens when it fails, when two people do it at once, and when the data is missing. If nobody has an answer, the feature is not scoped, it is named.
Integrations, which are where estimates go to die
Integrating with a well-documented modern API — Stripe, Xero, a mainstream CRM — is predictable work. Integrating with a legacy system whose only interface is a nightly CSV drop, or a vendor API with no sandbox environment, is research, not implementation. The cost difference between those two cases can be an order of magnitude for the same nominal feature. Before signing anything, list every external system the software must talk to and, for each one, establish whether there is documentation, a test environment, and someone who will answer questions. Any integration failing two of those three is a risk item, not a line item.
Regulatory and compliance requirements
UK GDPR obligations apply to almost any system holding personal data, and they are cheap to design in and expensive to retrofit. Data subject access requests, deletion, retention policies, audit logging and lawful basis all have engineering consequences. If you operate in a regulated sector — financial services, healthcare, anything touching children’s data — add requirements for access control granularity, evidence trails and often a formal security assessment. Where a client needs Cyber Essentials Plus or an ISO 27001-aligned environment, that shapes hosting, deployment process and documentation from day one.
Design, and how much of it is genuinely new
An internal tool built on an existing component library needs layout decisions, not a design programme. A customer-facing product where the interface is part of the value proposition needs research, prototyping and iteration. Both are legitimate; they are not the same budget. Be honest about which one you are buying.
Quality assurance, proportionate to blast radius
The right amount of testing depends on what happens when the software is wrong. A dashboard that displays a stale figure is an annoyance. A payroll calculation, a medication reminder or a device firmware update that goes wrong is a different category of problem. Automated test coverage, staged rollouts and the ability to roll back are cost items, and they are worth arguing about explicitly rather than leaving as an assumed part of “development”.
Why published ranges vary so wildly
You will find UK figures spanning from a few thousand pounds to well over a million for things described in almost identical language. The spread is real, and it comes from three places.
- Different definitions of “done”. One quote covers a working prototype; another covers a production system with monitoring, backups, documentation and handover. Both are called an app.
- Different team compositions. Day rates in the UK vary substantially by region, seniority and whether you are buying a delivery team or individual contractors. A cheaper day rate that needs three times the days is not cheaper.
- Different risk positions. A supplier committing to a fixed price on a vague brief has priced the ambiguity into the number. That is rational behaviour, not profiteering.
As orders of magnitude rather than quotes: a single well-defined integration or an internal tool replacing a spreadsheet sits at the low end. A first commercial release of a multi-user SaaS product with authentication, billing, an admin surface and a couple of integrations sits a tier above that. A platform touching regulated data, hardware, or a large existing estate sits a tier above again. The jumps between tiers are driven by the number of independent systems that must be correct simultaneously, which is also why cost does not scale linearly with feature count.
Contracting models and what each one really costs you
Every model allocates risk somewhere. There is no arrangement in which nobody carries it.
Fixed price
Attractive because the number is knowable in advance. The trade-offs: it requires a specification detailed enough to price, which is itself a paid piece of work; it prices in a risk buffer you pay whether or not the risk materialises; and it makes change adversarial, because every deviation becomes a variation order. Fixed price works well for genuinely bounded work — a defined integration, a migration, a redesign of an existing product. It works badly when the requirements are still being discovered, which is most first-version products.
Time and materials
You pay for effort expended. This is honest and flexible, and it puts the budget risk on you. It is only safe with real visibility: a prioritised backlog you control, working software demonstrated at short intervals, and the contractual ability to stop. If a supplier resists any of those three, the flexibility is theirs and the risk is yours.
Dedicated team or capped time and materials
A fixed monthly cost for a known team. Predictable cash flow, continuity of knowledge, and it suits ongoing product development rather than a one-off build. The trade-off is that you are buying capacity rather than outcomes, so it only works if someone on your side is genuinely deciding what that capacity does each sprint. A capped model — time and materials with an agreed ceiling per phase — is often the practical middle ground for a first engagement.
The costs almost every budget omits
- Ongoing maintenance. Dependencies get security patches, mobile platforms deprecate APIs on their own schedule, browsers change, third-party APIs version. This is not optional work; software left alone for two years is not stable, it is unsupported. Budget for it annually as a proportion of the build, and ask any supplier what proportion they see in practice.
- Infrastructure. Hosting, managed databases, object storage, egress, backups, monitoring, error tracking, email and SMS delivery. Individually small, collectively a recurring line worth modelling at your expected usage rather than today’s.
- AI running costs. If the system uses hosted models, inference is a variable cost that scales with usage rather than a fixed licence. Model it per active user before you commit to a pricing model of your own.
- Support. Someone answers the questions and triages the bug reports. Decide whether that is you or the supplier, and at what response times, before launch rather than after the first incident.
- Your own people’s time. Requirements, review, testing, data preparation, training and rollout. Projects stall on client-side availability more often than on engineering.
Questions to put to any supplier before you compare prices
- What is explicitly out of scope in this number?
- Which assumptions, if wrong, would change it most — and how would we find out early?
- Who owns the code, the repositories and the cloud accounts on day one?
- What does the first year of running and maintaining this cost, separately from building it?
- If we stopped after three months, what would we have that works?
The last question is the most revealing. A supplier who can describe a genuinely useful three-month outcome is thinking in terms of deliverable value; one who can only describe a finished twelve-month system is asking you to carry the whole risk of the plan being right.