Contents
There is no single useful price for bespoke software without a defined scope. This guide does not present supplier price bands as a UK market average or quote a price for your project. Instead, it gives you a way to build a budget, expose the assumptions behind it and compare proposals on the same basis. Start with the smallest valuable outcome, then account for the work needed to launch, operate and eventually hand over the system.
Define the outcome before the feature list
Write down who needs to do what differently, what gets in their way today and how you will recognise an improvement. A purchasing portal, for example, might need to reduce repeated order entry while preserving approval rules. That is a more useful starting point than asking for a portal with a dashboard.
Separate the first usable release from later ideas. Include the operational work needed for that release: loading existing data, training administrators, supporting users and handling exceptions. A narrow feature list can still describe a substantial project when the surrounding process is complicated.
The GOV.UK Service Manual advises understanding the problem, users and constraints before committing to a build. Its discovery guidance provides a useful starting point for questioning an assumed solution; it does not establish a commercial price or a delivery promise for your project.
Identify the work that changes the estimate
Ask the delivery team to explain the main drivers separately. These may include user journeys, permissions, integration with existing systems, data migration, reporting, testing and release preparation. Two products with similar screens can require very different work behind those screens.
For an integration, establish whether documentation, a test environment and a named technical contact exist. For a migration, inspect representative data and define who resolves duplicates or missing records. For permissions, describe the actual actions each role may take rather than relying on a generic administrator/user distinction.
Record assumptions beside each estimate. If a supplier assumes clean data and an available API while another includes data repair and a bespoke connector, their totals are not directly comparable. Resolve the difference in scope before negotiating the number.
Separate delivery, operation and uncertainty
Build a budget with distinct lines for discovery and design, implementation, migration and launch, and ongoing operation. For ongoing costs, consider hosting, third-party licences, monitoring, maintenance and the support arrangement you actually need. Ask what is included in the quoted period and what is billed separately.
Keep an explicit allowance for unresolved work. Do not choose a contingency percentage simply because it is familiar: identify the assumptions that could change the budget and ask what evidence would narrow the range. A short technical investigation may be more useful than increasing every line indiscriminately.
Include your organisation's contribution. Someone must answer product questions, arrange access, review releases and make decisions about scope. Those responsibilities affect both effort and elapsed time even when they do not appear on the supplier's invoice.
Compare proposals on the same basis
Request a shared statement of scope, exclusions, acceptance criteria and dependencies. Ask how the team handles changes, what triggers a revised estimate and what happens when an assumption proves wrong. Understand whether a price is fixed for a defined scope, an estimate of time and materials, or a capped phase with a separate next decision.
Compare handover and support as well as delivery. Establish who controls repositories and hosting accounts, what documentation you receive and how defects are distinguished from new requirements. Have the relevant commercial terms reviewed by the people responsible for procurement and contracts.
A proposal should make the next commitment understandable. If the problem is not yet well defined, commission a bounded investigation with named outputs and a decision at the end. If the scope is sufficiently understood, ask for a delivery plan that explains how progress and acceptance will be demonstrated.
Build a comparable estimate worksheet
Create one row for each complete user journey, integration, migration, launch activity and recurring service. Give every row the same fields: outcome; included work; excluded work; supplier effort or price basis; your team's responsibilities; dependency; acceptance evidence; and the unresolved question that could change the estimate. Ask every supplier to complete the same worksheet.
For an illustrative order-approval journey, the outcome might be that an authorised manager can approve an order within their own location. Included work could cover access rules, approval history, notifications and rejected orders. A useful acceptance check would show that a manager cannot approve another location's order. The unresolved question might be whether approval limits come from an existing system. This is a synthetic planning example, not a description of a particular customer's implementation.
Summarise one-off delivery and launch costs separately from recurring costs over a stated planning period. Use the same period and assumptions for every proposal, record whether amounts include VAT, and distinguish committed prices from provisional estimates. Calculate the comparable total as delivery plus migration and launch plus operation over that period. Keep risk allowances visible beside that total, with a reason for each allowance rather than an unexplained percentage.
Before committing, give each important unknown an owner and a way to resolve it. If an integration determines feasibility, a technical spike using synthetic data may be the next purchase. If a workflow is well understood and isolated, a bounded first release may be appropriate. The worksheet should lead to a decision about the next phase; it is not evidence that all future work can be priced today.
Prepare a brief that makes the next estimate better
Bring a description of the current process, the users involved, the systems it touches and the outcome you want. Add known deadlines and explain why they matter. Share representative synthetic examples rather than exposing live customer data during initial discussions.
State your budget readiness honestly, including whether funding is approved or you are building a business case. Ask the team which decisions can be made now, which need investigation and which can wait until a later release. The result should be a more defensible investment decision, with the remaining uncertainty visible.