“How much does bespoke software cost?” is a sensible question to ask before you commit to a build. The honest answer is a range: a focused first release and a multi-system platform are different investments, even when they solve similar business problems.
The figures below are early planning guides, not a DuniaOps quote or a promise that a particular scope will fit a band. They help you decide whether to keep exploring, compare a software product, or narrow the first release before asking suppliers for an estimate.
Indicative UK project ranges
| Type of work | Early planning range | Typical shape |
|---|---|---|
| Focused internal tool or first production release | £15,000–£50,000 | One main workflow, a small number of user roles and limited integrations |
| Connected business application | £50,000–£150,000 | Several workflows, meaningful system integrations, operational reporting or a managed rollout |
| Complex platform or legacy-system replacement | £150,000–£500,000+ | Multiple systems or teams, substantial migration, higher assurance needs or phased replacement |
These are broad budget bands, not fixed market tariffs. One published set of UK planning ranges uses similar bands for focused tools, connected applications and complex platforms. A separate provider’s 2026 sample of its own project estimates reported first production releases between £11,000 and £34,000. That is useful context, but neither source predicts what your project will cost. Compare the published planning bands and read the provider’s estimate sample and assumptions.
All figures here are in GBP and should be treated as excluding VAT, hosting, third-party licences and other external charges unless a proposal says otherwise. Check what is included before comparing two numbers.
What moves a project towards the top of a range?
The number of screens is only one part of the estimate. Cost usually changes with the work needed to make the system useful, safe to operate and possible to change later:
- Workflows and rules: exceptions, approvals, permissions, allocation logic and reporting need more design and testing than a simple form.
- Integrations and data: connecting older systems, cleaning or migrating data, and handling unreliable third-party interfaces adds uncertainty.
- Security and assurance: sensitive data, access controls, audit trails, resilience and regulatory requirements affect architecture and verification.
- Production readiness: automated tests, monitoring, deployment, recovery procedures, documentation and handover are part of a dependable release.
- Scope certainty: unresolved decisions create rework. A short discovery phase can reduce uncertainty before a larger build is priced.
The UK Government’s cost-estimating guidance is written for infrastructure projects, not software, but its core estimating principle is relevant: an estimate evolves with scope and schedule, and a range should reflect risk and uncertainty. Read the guidance.
How to make a smaller first release useful
Reducing cost should mean reducing unnecessary scope, not removing the work that makes software safe to use. Start with one important user journey and agree what it must accomplish. Keep secondary workflows, complex integrations and edge cases for later unless the product cannot deliver value without them.
Then ask each supplier to show what sits inside the estimate: discovery, design, engineering, testing, deployment, project ownership and handover. Clarify assumptions, exclusions, dependencies and how changes will affect the budget. UK contract data can give context for individual software developer rates, but a contractor day rate is not the price of a delivered product: it does not automatically include product discovery, testing, delivery coordination or production handover. IT Jobs Watch’s UK rate data is based on advertised contract vacancies, not agency project quotes.
Also compare the total cost of ownership. A SaaS subscription may be the better choice when its workflow fits. For a custom build, budget for the hosting, licences, maintenance, support and future changes that continue after launch—not only the initial development.
What to prepare before asking for a quote
You do not need a complete specification. Bring a clear description of the problem, who experiences it, how the current process works, which systems or data are involved, and what a useful first release would change. A supplier should ask questions about ownership, testing, deployment and support before giving a confident number.
At DuniaOps, we use a discovery conversation to clarify those assumptions and identify a sensible first step. If you are evaluating a build, see our custom software development service and tell us what your team needs the software to do.
