Business Software
How Much Does Bespoke Software Cost in the UK?
A credible bespoke-software budget is a range built from scope, uncertainty, team shape and operating obligations. A fixed headline figure before those are understood is usually sales positioning, not an estimate.
Why there is no honest universal price
Two applications with ten screens can have radically different costs. One may maintain simple reference data; another handles payments, personal information, delegated approvals, external integrations and a zero-downtime migration.
Price follows required behaviour, uncertainty and consequence-not screen count. Suppliers can quote a small brochure site quickly because the solution is familiar. A business system needs evidence about workflows, data, exceptions, security, scale and transition.
A useful early answer is therefore a range with named assumptions, exclusions and the evidence that will narrow it.
Cost begins with the business boundary
Define who uses the system, which journeys it owns, what remains outside and which existing tools it replaces. “Customer portal” could mean viewing documents or a multi-tenant transactional platform with payments and secure messaging.
Exceptions often drive more effort than the main journey: corrections, delegation, failed payments, disputed records and retrospective changes. Include them before estimating.
Separate launch scope from future ideas. Design important extension points, but do not fund speculative features as though they are confirmed requirements.
Discovery is part of delivery economics
Discovery maps outcomes, workflow, data, integrations, risks and options. It may include prototypes or technical spikes where usability or feasibility is uncertain.
Its purpose is not to document every screen. It reduces expensive uncertainty before a full team is committed. Discovery can also show that a product, integration or process change is cheaper than bespoke development.
A supplier offering a precise fixed quote with no discovery has either priced substantial contingency, assumed a simple interpretation or expects changes to become commercial disputes.
Team composition matters more than a day rate
A lower rate does not reduce cost if delivery needs more rework, management or elapsed time. Compare the team needed for the risk: product or business analysis, UX, engineering, quality, architecture, delivery and operations.
Not every role needs to be full-time. A focused senior team can outperform a larger team where communication dominates. Conversely, one developer cannot sustainably provide independent review, discovery, security, testing and support for a consequential system.
Ask who actually performs the work and how senior attention is allocated after sale. A blended rate can conceal an inexperienced delivery shape.
The principal cost drivers
| Driver | Why it changes effort | Evidence that narrows the estimate |
|---|---|---|
| Workflow and rules | States, exceptions and permissions multiply paths | Mapped journeys and decision examples |
| Integrations | External contracts, sandboxes and failure handling are uncertain | API access, samples, limits and ownership |
| Data migration | History is duplicated, incomplete or semantically inconsistent | Profiling, volumes and reconciliation rules |
| Security and assurance | Sensitive or regulated work needs stronger controls and evidence | Data classification, threat model and compliance duties |
| Scale and availability | Concurrency, resilience and recovery affect architecture and testing | Measured volumes, peaks, RTO and RPO |
| User experience | Public, accessible or complex interfaces need research and testing | User groups, tasks and prototype evidence |
| Transition | Parallel running, training and cutover add temporary work | Adoption plan, legacy boundary and retirement criteria |
Integrations are not just connectors
A successful API call is the easy part. Production integration needs authentication, rate limits, idempotency, timeout, retry, mapping, reconciliation, monitoring and a support owner.
Supplier documentation may omit actual data quality or sandbox differences. Test the riskiest integration early. If access depends on a contract not yet signed, show that dependency in the range.
Budget change after launch. External providers version and retire interfaces; somebody must own that response.
Data migration is a business decision
Migration effort follows ambiguity more than row count. Two customer records may represent duplicates, related organisations or intentional billing identities. Only business ownership can decide.
Profile source data before committing to a fixed migration price. Define what moves, what is archived, how records map, which copy is authoritative during cutover and how correctness is reconciled.
Do not assume every historical field belongs in the new model. Preserving unexplained structure can recreate the legacy system's constraints.
Security cost should be designed, not added
Authentication, authorisation, tenant isolation, audit, encryption, secrets, backup and incident response affect architecture. Adding a penetration test at the end cannot correct a weak trust boundary cheaply.
Assurance depth should match consequence. A public system handling sensitive data needs more evidence than an internal low-risk tool. Ask which security activities and remediation are included.
Fixed price, time and materials, or phased funding?
| Model | Works well when | Main risk |
|---|---|---|
| Fixed price | Scope and acceptance are genuinely understood | Contingency, rigidity or disputes over interpretation |
| Time and materials | Learning and reprioritisation are expected | Weak budget control if outcomes and governance are unclear |
| Capped increment | A bounded outcome can be delivered and reviewed | Interfaces between increments may be underplanned |
| Discovery then delivery range | Important uncertainty must be reduced before commitment | Stakeholders may mistake discovery for a promise of the original idea |
A sensible commercial model assigns risk to the party able to control it. A developer cannot economically fix-price an undocumented third-party dependency without contingency or exclusions.
Budget beyond the first release
Include hosting, monitoring, backups, support, security patches, platform upgrades, certificates, domains, third-party services and continuing product decisions. Usage-based services make some costs variable.
Plan a warranty or stabilisation period, then define service levels and enhancement capacity separately. Support keeps the service healthy; product development changes what it does.
Software that never receives lifecycle funding becomes legacy regardless of the initial build quality.
Internal time is part of the cost
Subject-matter experts must explain rules, resolve data ambiguity, review prototypes, test workflows and support adoption. If they are unavailable, decisions wait or developers guess.
Include backfill and decision time in the plan. A low supplier invoice can coexist with a costly internal programme.
How to compare proposals
- Normalise scope, assumptions, exclusions and operating period.
- Check whether discovery, design, testing, security, migration and deployment are included.
- Compare named team shape and availability, not only rate.
- Ask how uncertainty and change are governed commercially.
- Check repository, hosting, documentation, data and exit ownership.
- Inspect support, warranty and lifecycle assumptions.
- Challenge a price materially lower than peers: find the missing scope or different assumption.
Build a budget in stages
- State the business outcome, deadline and cost of the current problem.
- Fund enough discovery to expose workflows, data and highest risks.
- Estimate a narrow first production outcome with explicit quality controls.
- Use ranges for later scope and identify variables that move them.
- Reserve transition, contingency and internal participation.
- Model several years of operation and change.
- Reforecast after every increment using delivery evidence.
Contingency should correspond to named risk
A contingency percentage is useful only when the team can explain what it protects. Separate expected scope from allowances for uncertain migration, third-party access, performance, policy decisions or adoption. This makes it possible to retire contingency when evidence arrives instead of leaving an unexamined reserve.
Known work should be estimated as work, not hidden inside contingency. Unknown but testable assumptions belong in discovery or an early spike. Track drawdown openly; if ordinary omitted requirements repeatedly consume it, the estimate was incomplete rather than unlucky.
UK accounting and procurement need separate advice
VAT treatment, capitalisation and available tax relief depend on the organisation, contract and rules applying at the time. Involve a qualified accountant or finance adviser rather than treating generic supplier guidance as accounting advice.
Procurement timing, milestones and internal approval affect cash flow and schedule, but do not reduce engineering effort. Keep accounting treatment separate from total cost so a financing or tax effect is not presented as cheaper delivery.
Confirm whether proposal values include VAT and which third-party charges use foreign currencies. Exchange-rate movement, annual price changes and usage overages belong in sensitivity analysis rather than being silently fixed at today's value.
Related C3 Software guides
Frequently asked questions
Can a supplier quote bespoke software before discovery?
It can provide a broad range based on explicit assumptions. Precision should increase only as workflow, data, integrations and risk become understood.
Why do bespoke-software quotes vary so much?
Suppliers may assume different scope, team seniority, assurance, migration, ownership and support. Compare the underlying offer, not the bottom line alone.
Is fixed price safer?
Only when the work is sufficiently understood. Otherwise risk returns as contingency, exclusions, reduced quality or change disputes.
What is most often omitted?
Data correction, integration failure handling, internal staff time, adoption, production assurance and ongoing lifecycle ownership are frequent omissions.
Turn an idea into a defensible budget range
C3 Software Limited has built and supported UK business software since 2001. If you need to understand likely scope, risk and investment before committing, talk to C3 Software about a focused discovery and estimate.