How Much Does Bespoke Software Cost?

Why This Question Is Hard to Answer Honestly

'How much does bespoke software cost?' is the most common question in the industry and the one that receives the least useful answers. Most developers either refuse to give any indication - 'it depends, get in touch for a quote' - or give a number so low it cannot possibly be accurate, designed to get you into a conversation rather than to set realistic expectations.

Neither of those responses serves you well. If you are trying to decide whether bespoke software is within your budget, you need a realistic sense of cost before investing time in scoping conversations. If you are evaluating quotes you have already received, you need enough context to know whether the numbers are credible.

This guide attempts to answer the question honestly. It will not give you a fixed price - nobody can do that without understanding your specific requirements - but it will give you a framework for understanding what drives cost, what different budgets realistically achieve, and how to identify when a quote is too low to be believable.

A note on the numbers in this guide: they reflect UK market rates for experienced senior engineers delivering production-quality software. They are not the cheapest prices available. They are realistic prices for work that will actually do what you need it to do.

The Fundamental Economics of Bespoke Software

Before getting into specific cost drivers, it helps to understand the basic economics. Bespoke software costs what it costs because you are paying for a skilled person's time. Unlike a physical product, there is no material cost, no manufacturing process, and no economies of scale in the traditional sense. The cost of building software is almost entirely the cost of the engineering time required to build it.

Senior software engineers in the UK charge day rates in the range of £500 to £1,000 per day, depending on their specialisation, experience, and the nature of the work. Agencies and consultancies typically charge more than this because they have overhead costs - offices, account management, project management, and business development - that are factored into their rates.

This means that the cost of a bespoke software project is essentially: the number of days of engineering time required, multiplied by the day rate of the people doing the work. Everything else - fixed-price projects, milestone-based billing, monthly retainers - is just a different way of packaging the same underlying economics.

Understanding this helps you evaluate quotes more intelligently. If you receive a quote for a complex SaaS platform at £8,000, and you know that senior engineering time costs £500-£1,000 per day, you can immediately calculate that the quote assumes 8 to 16 days of work. A complex SaaS platform cannot be built in 8 to 16 days. The quote is either from a very junior developer, is based on a much more limited scope than you described, or is not honest about what will actually be delivered.

The Main Cost Drivers

Within the basic economics of engineering time, specific factors determine how much time a given project requires. Understanding these factors lets you estimate where your project sits in the cost range before anyone has looked at your requirements in detail.

1. Feature Scope and Complexity

The most obvious cost driver is the number of features and the complexity of the logic behind them. More features means more time. More complex features means more time per feature. This seems obvious, but it is consistently underestimated in two ways.

First, features that seem simple often are not. A user login system seems simple - everyone has seen one. But implementing it correctly involves user registration, email verification, password reset, session management, multi-factor authentication, social login, account recovery, and security against common attacks. Done properly, a user authentication system takes several days. Done quickly and poorly, it creates security vulnerabilities that will need to be fixed later at greater cost.

Second, the interaction between features adds complexity that is not visible when looking at features individually. A reporting feature might seem like a simple addition to an existing system. But if the data model was not designed with reporting in mind, adding comprehensive reporting might require restructuring significant parts of the database - which is much more expensive than if reporting had been considered from the start.

As a rough guide, feature complexity falls into three broad categories:

Most real projects contain a mix of all three categories. A SaaS platform, for example, might have dozens of simple features, several medium complexity features, and a handful of high complexity ones. The high complexity features - multi-tenancy, billing, user management - typically account for a disproportionate share of the total cost.

2. Number and Complexity of Integrations

Integrations with third-party systems are one of the most consistently underestimated cost drivers in bespoke software projects. Every external system your application needs to connect to adds development time - and the amount of time varies significantly depending on the quality of the integration.

Well-documented modern APIs from established providers - Stripe for payments, SendGrid for email, Twilio for SMS - are relatively straightforward to integrate. They have comprehensive documentation, active developer communities, good SDKs, and test environments. A clean integration with a well-maintained API might take one to three days.

Poorly documented APIs, legacy systems, or integrations that require complex data transformation take considerably longer. A legacy ERP system that requires a custom adapter, or an API that is not well documented and has unexpected behaviour, might take two to three weeks to integrate reliably.

There is also the question of what 'integrated' means. A basic integration that sends data in one direction and handles the happy path is much faster to build than a robust integration that handles errors gracefully, retries failed requests, logs everything for debugging, deals with rate limits, and keeps data consistent between systems when things go wrong. The difference between a fragile integration and a reliable one can be several days of additional work.

Projects that require many integrations - a system that needs to connect to a CRM, an accounting platform, a payment gateway, an email platform, and a legacy internal database - can easily have integration work that equals or exceeds the core application development in time and cost.

3. User Types and Permission Complexity

Every distinct user type in your system adds complexity. An application with a single user type is significantly simpler to build than one with multiple user types who have different views of the same data and different sets of actions available to them.

A SaaS platform that serves individual users is simpler than one that serves teams, where different team members have different roles and different members of the same team can see each other's data but not other teams' data. Adding an admin dashboard for you to manage all customers adds another user type. Adding a partner or reseller tier adds another.

Permission systems are particularly expensive to implement correctly because the logic is complex, the edge cases are numerous, and the consequences of getting it wrong - a user seeing data they should not see, or being able to take actions they should not be able to take - are serious. Rushing permission implementation to save cost is one of the most common sources of security problems in bespoke software.

4. Data Volume and Performance Requirements

Applications that need to handle large volumes of data, or that have demanding performance requirements, cost more to build correctly than applications that do not. This is because they require more careful database design, more sophisticated query optimisation, caching strategies, and infrastructure that can handle the load.

An application that needs to store and retrieve thousands of records is architecturally different from one that needs to handle millions. A dashboard that needs to aggregate data in real time across a large dataset requires different design decisions than one that can afford to pre-calculate results overnight. These differences are not visible in a feature list, but they affect development time significantly.

The cost implication is not just in the initial build. Systems that are not designed for the data volumes they will eventually reach become progressively more expensive to operate and to fix as they grow. Designing for realistic scale from the start costs more upfront but significantly less over the life of the system.

5. Mobile vs Web

Mobile applications cost more than web applications for the same functionality, for two main reasons. First, mobile development requires platform-specific knowledge and tooling - even with cross-platform frameworks like React Native, there is meaningful platform-specific work required for iOS and Android. Second, the app store submission and review process adds time and introduces uncertainty into the delivery timeline.

A web application and a companion mobile app cost more than a web application alone - typically 50-80% more, depending on how much functionality the mobile app duplicates and how much is native to mobile. A mobile-first product with no web component is often comparable in cost to a web application of similar scope, because the platform-specific work replaces rather than adds to the web development work.

6. Timeline and Urgency

Compressed timelines cost more. This is a consistent truth across all types of skilled work and software development is no exception.

There are several reasons for this. Compressed timelines require more intensive, focused work that leaves less room for the iterative thinking and refinement that produces better software. They limit the ability to identify and fix problems before they become entrenched. They often require working in ways that create technical debt - shortcuts that will need to be addressed later at greater cost.

A project that could be delivered in four months at a measured pace, producing high-quality, well-tested software, might be deliverable in eight weeks under intensive conditions - but it will cost more, it will carry more risk, and the output quality is likely to be lower. The total cost of ownership over the life of the system is almost always higher for rushed projects.

If your timeline is driven by a real external constraint - a regulatory deadline, a product launch tied to an event, an investor commitment - it is worth being explicit about this from the start so a developer can tell you honestly whether the constraint is achievable and what it will cost. If your timeline is aspirational rather than mandatory, the most cost-effective approach is almost always to take the time the project actually needs.

7. Post-Launch Requirements

The cost of building software does not end at launch. Most software requires ongoing maintenance, security updates, dependency management, and feature development after it goes live. The scale of this ongoing investment varies significantly and should be factored into the total cost of ownership from the start.

At a minimum, software requires security patching and dependency updates as vulnerabilities are discovered and third-party libraries release new versions. For web applications and mobile apps, platform changes - new browser versions, iOS and Android updates - require periodic compatibility work. This ongoing maintenance cost is typically 15-25% of the original development cost per year.

Beyond maintenance, most applications need to evolve as your business grows and your users' needs become clearer. Feature development after launch is usually charged at the same day rate as the initial build, and the cost depends on the scope of the changes. Architecture decisions made during the initial build significantly affect how expensive post-launch development is - a well-architected system is much cheaper to extend than one that was not designed with future growth in mind.

What Different Budgets Realistically Achieve

With the cost drivers understood, it is possible to give a realistic picture of what different budget levels can deliver. These ranges assume UK market rates for experienced senior engineers delivering production-quality work.

How to Evaluate Whether a Quote Is Reasonable

Once you have received quotes from developers, the question becomes whether the numbers are credible. Here is a framework for evaluating them.

Does the time implied by the quote make sense?

The simplest check is to work backwards from the quote to the implied development time. If you know or can estimate the day rate of the developer, divide the quote by that rate to get the number of days implied. Then ask yourself: is that enough time to build what was described?

A quote of £15,000 from a developer charging £500 per day implies 30 days of work. Is 30 days enough to build the features described? For a simple internal tool, possibly. For a SaaS platform with billing and user management, almost certainly not.

If you do not know the developer's day rate, you can assume a range of £300-£400 per day for junior developers, £500-£700 for mid-level, and £700-£1,000 for senior. Agencies typically charge 20-40% above these rates to cover their overhead.

Is the quote broken down by feature or phase?

A credible quote should be broken down in enough detail that you can see where the time is being spent. A single line item - 'development of your platform: £25,000' - tells you nothing about what is included. A detailed breakdown by feature, phase, or functional area tells you what the developer thinks they are building and lets you identify where their assumptions differ from yours.

Quotes without breakdown are either from developers who have not thought carefully about what is involved, or from developers who prefer the ambiguity that comes from a vague scope. Neither is a good sign.

Does the quote include what you actually need?

Scope creep - the gradual expansion of a project beyond its original definition - is one of the most common sources of cost overruns in software development. It often starts with a quote that does not explicitly exclude things the client assumed were included.

When evaluating a quote, check explicitly whether it includes: user authentication and account management, an admin interface for you to manage the system, testing and quality assurance, deployment and hosting setup, documentation, and post-launch support. These are commonly omitted from quotes to keep the headline number low, then added back as the project progresses.

Is the timeline realistic?

Software takes longer than expected. This is not a cynical observation - it is a consistent empirical finding across thousands of software projects. The reasons are well understood: requirements are never as clear as they seem at the start, problems discovered during development require design changes, testing reveals issues that need to be fixed, and integration with third-party systems is harder than anticipated.

A developer who quotes a very short timeline for a complex project is either very optimistic or not being honest about what is involved. A realistic timeline includes time for requirements clarification, iterative development, testing, bug fixing, and deployment. For a moderately complex project, this is typically measured in months rather than weeks.

What does the developer's track record suggest?

The most reliable indicator of whether a quote is credible is the developer's track record with similar projects. A developer who has built five SaaS platforms and can point to them is much more likely to quote accurately for a sixth than one who has never built one before.

Ask for examples of similar work. Ask what challenges came up and how they were handled. Ask whether the projects were delivered on time and on budget, and if not, what happened. A developer with genuine experience of the type of project you are commissioning will be able to have a detailed, specific conversation about it. One without that experience will speak in generalities.

Common Reasons Projects Cost More Than Expected

Even with realistic initial quotes, projects sometimes cost more than expected. Understanding the most common reasons helps you structure engagements that minimise this risk.

Requirements that were unclear or incomplete

The most common source of cost overruns is requirements that were not fully defined at the start of the project. When a developer encounters a requirement that was not in the original scope, they have to decide whether to include it in the existing budget or raise a change request. Legitimate change requests happen in every project - the question is whether they are genuinely new requirements or whether they represent scope that was always implied but not made explicit.

The best protection against requirement-driven cost overruns is thorough upfront scoping. A technical specification produced before development begins, agreed by both parties, and used as the basis for the fixed-price estimate, is the most effective way to minimise scope-driven cost increases.

Integration complexity that was underestimated

Integrations with third-party systems are almost always more complex in practice than they appear in planning. APIs have undocumented behaviour, rate limits that are only discovered at scale, and authentication mechanisms that are more complex than the documentation suggests. Legacy systems have quirks that only appear when you try to connect to them.

The best protection against integration cost overruns is a developer who investigates the specific APIs and systems involved before providing a quote, rather than assuming they will behave as documented.

Performance problems discovered late

Performance problems that are not discovered until the application is under real load - or until it contains real data volumes - can be expensive to fix because they sometimes require architectural changes rather than targeted optimisations. A system that performs acceptably with a thousand records may perform unacceptably with a hundred thousand.

The best protection is architecture designed with realistic data volumes in mind from the start, and performance testing with realistic data before launch rather than after.

Scope expansion during development

As software takes shape, it is natural to see opportunities to improve it or to realise that a feature that seemed unnecessary is actually important. Scope expansion is not inherently bad - it often reflects good product thinking. But it should be handled explicitly, with a clear understanding of the cost and timeline implications of each addition, rather than absorbed silently into the project.

A good developer will tell you the cost and timeline impact of every scope change before implementing it. A developer who absorbs scope changes silently is either not tracking them or planning to raise them at the end as additional charges.

The Total Cost of Ownership

The cost of building software is only part of the total cost of owning it. A complete picture includes the ongoing costs of hosting, maintenance, security updates, and feature development that continue for the life of the system.

Practical Steps Before Getting Quotes

Before approaching developers for quotes, there are several steps that will significantly improve the quality and comparability of the quotes you receive.

Define your requirements as clearly as possible

The more clearly your requirements are defined, the more accurate the quotes you receive will be. This does not mean you need a complete technical specification before talking to developers - that is what the scoping process is for. But you should be able to describe: what problem the software is solving, who will use it and how, what the key workflows are, what systems it needs to connect to, and what you consider essential versus nice-to-have.

Know your budget range before you start

Going into a quoting process without a budget range makes it harder to have productive conversations. You are likely to receive quotes across a very wide range, some of which will be entirely unrealistic in one direction or another. Sharing a budget range with developers allows them to tell you honestly whether it is sufficient for what you need, rather than either undershooting to win the work or overshooting because they do not know what you can afford.

Ask for detailed breakdowns

Request that all quotes are broken down by feature, phase, or functional area. This allows you to compare quotes meaningfully - a lower total price might include less scope, and a higher one might include things you do not need. Breakdowns also allow you to scope down to fit a budget if the full scope exceeds it.

Evaluate the developer, not just the price

The cheapest quote is rarely the best value. Software development is a service where the quality of the output is highly variable and where the consequences of poor quality accumulate over time. A system built by an inexperienced developer at half the price of an experienced one will typically cost more in total over its lifetime - through maintenance, bug fixing, performance problems, and eventual rebuild - than the more expensive option would have.

Frequently Asked Questions

Related Resources