A quote for bespoke software can vary widely — from a small, tightly-scoped piece to a larger product built and refined over months. That is not evasion; it reflects the difference between a focused lead-generation website and a platform used by thousands of people. If you are asking how much does bespoke software cost, the useful question is: what must the first version achieve, and what level of quality will it need to sustain?
A lower quote is not automatically better value, and a higher quote is not automatically evidence of better engineering. The right budget is one that funds the shortest sensible route to a real business outcome, without quietly creating a rebuild project six months later.
How much does bespoke software cost in practice?
Rather than fixed product prices, DELLIUX works in three engagement models — because two projects that look similar can differ enormously in scope. Where a piece of work lands depends on the factors below, not the number of screens.
Fixed-scope projects start from £1,000, with a typical range of around £1,000 to £5,000. This suits well-defined work with clear boundaries: a focused marketing website, a launch or MVP, a landing page, a performance fix, a contained integration or a technical audit. You get a fixed price, a fixed timeline and clear milestones because the outcome is understood up front.
Larger or evolving products — a complex web application, a SaaS platform with billing and multiple roles, or a cross-platform mobile app — are usually better delivered through a monthly retainer from £500. That gives you a block of senior engineering each month that flexes as the product grows, rather than committing a large lump sum to a specification that will inevitably change. It also keeps a senior team close to the code as you iterate towards the right result.
Advisory and audit work starts from £1,000 — architecture reviews, performance audits, technical due diligence and a written report with prioritised actions for an existing product or codebase.
The value of these models is that they match how software actually gets built. A tightly-scoped first version can ship quickly and affordably; a larger product grows in sensible increments without a single, risky upfront estimate. What moves the number within each model is scope, design, integrations and quality — covered next.
What actually drives bespoke software costs?
The number of screens is a poor predictor. Two products can each have ten screens, yet one is a straightforward interface over a simple database while the other includes permission rules, calculations, payment edge cases and third-party systems that fail unpredictably.
Scope and the unknowns behind it
The cost of software is largely the cost of making decisions. A requirement such as “users can manage subscriptions” contains many questions: can they upgrade immediately, what happens to unused credit, who can issue refunds, how are failed payments handled, and what appears in finance reports?
Clear scope lowers cost because engineers spend less time discovering critical rules during development. It does not mean writing a 60-page specification before speaking to users. A short discovery phase that maps the core journey, data, constraints and success measures is usually a better investment than pricing a vague idea as if it were settled.
Design is more than visual polish
Bespoke design costs more than choosing a template, but it should reduce expensive uncertainty. Good product design tests whether users understand the next action, whether information appears at the right moment and whether unusual states have been considered.
For a marketing site, design also affects conversion, accessibility and performance. For an application, it affects training time, support requests and whether users work around the system rather than with it. Skipping design can look like a saving until development becomes a series of contradictory decisions.
Integrations, data and user permissions
Third-party services often appear simple in a sales demo. In production, they require authentication, error handling, rate-limit management, data matching and a plan for when their service changes. Payments, accounting systems, CRMs, maps, identity checks and legacy databases all deserve explicit time in a budget.
Permissions are another frequent underestimate. “Admin, manager and user” sounds modest, but each role may need different visibility, actions and audit trails. If a mistake could expose customer or financial data, this is not an area for shortcuts.
Quality requirements and non-functional work
A product that works in a happy-path demo is not necessarily ready for customers. Testing, monitoring, backups, security reviews, deployment automation and documentation all have a cost. So do accessibility to WCAG 2.2 AA, technical SEO and Core Web Vitals for public-facing websites.
These are sometimes labelled extras because they are less visible than a new feature. That framing is misleading. They are part of the product’s ability to perform, be found, be used and be maintained. The appropriate level depends on the risk and audience, but treating them as an afterthought is rarely cheap.
The team model changes the price and the outcome
You are not only buying development hours. You are buying judgement: the ability to challenge an unnecessary feature, spot a fragile architecture and make sensible choices when requirements change.
A low hourly rate can be good value for a narrow task with precise instructions. It is riskier for an early-stage product where the work includes shaping the solution. Junior-heavy teams may cost less at first, but need more supervision and can take longer to resolve difficult problems. Large agencies bring useful capacity for major programmes, though account management and delivery layers add overhead.
A small senior team can be particularly effective for defined projects and product foundations because the people estimating the work are also close to the code. Direct access reduces translation loss and makes trade-offs visible early. It is not the right model for every programme, especially one requiring a large team to work in parallel, but it can prevent a surprising amount of waste.
Fixed price, time and materials, or a retainer?
A fixed price works well when the outcome and boundaries are understood. It gives a founder or business owner budget certainty, provided the proposal is specific about what is included, what is excluded and how changes are handled. Be cautious of a fixed quote that is dramatically lower than others without a clear explanation. The missing cost often returns as change requests, lower quality or an incomplete release.
Time and materials suits work with genuine uncertainty: product discovery, legacy-system rescue work or an evolving SaaS proposition. It is not a blank cheque when managed properly. Use a capped budget, short delivery cycles and regular demonstrations tied to agreed priorities.
A monthly retainer is useful after launch or where an organisation has a continuous stream of improvements. It can cover maintenance, security updates, performance work, small feature releases and technical advice. Agree how capacity is allocated and what happens if urgent issues arise.
How to budget without paying for the wrong thing
Start with the business result, not the feature list. “Reduce manual order processing from three hours to thirty minutes” is a better starting point than “build an admin dashboard”. It makes it easier to decide which features are essential for version one and which can wait.
Ask a potential partner to separate discovery, build and ongoing support in its estimate. You should be able to see the assumptions, major risks, proposed technology and milestones. A credible estimate will include questions. A supplier who can price a complex system instantly, without understanding users or integrations, is guessing.
Keep a contingency of roughly 10-20% for a bespoke build. This is not permission for uncontrolled scope. It is a practical allowance for discoveries that only emerge once real systems, real data and real users are involved. If the budget has no room for change, reduce the initial scope rather than hoping nothing will move.
Finally, calculate the cost of delay and the cost of a poor build. If a well-scoped internal tool saves two people a day of repetitive work, the return may be clear. If a cheap customer-facing platform is slow, inaccessible or difficult to change, its headline saving can disappear through lost leads, support burden and a premature rebuild.
The best first step is usually a short, honest conversation about the outcome, constraints and budget range. DELLIUX can review a proposed scope or show how a project would be phased before you commit to a larger build.
