Most businesses commissioning custom software for the first time think they’re paying for code. In reality, the code is one of the smallest parts of the transaction. What you’re actually buying is software that continues working, remains understandable, and can still be adapted five or ten years from now when your business has changed around it.
That difference explains why software quotes can vary so dramatically, and why the cheapest proposal so often becomes the most expensive decision later.
Comparing the headline price is straightforward. Understanding what’s included in that number is where things usually go wrong.
One brief, completely different quotes
Take the same one-page project brief and send it to four different suppliers. It’s common to get prices back that look something like £7,000, £22,000, £38,000, and £60,000. None of those figures are necessarily dishonest. They’re usually pricing entirely different levels of work.
The £7,000 quote is often a solo freelancer overseas, moving quickly from one project to the next. The software itself may be decent enough. What often comes missing is documentation, automated testing, long-term support, or any certainty the developer will still respond once the final invoice is paid.
At around £22,000, you’re more likely dealing with a UK freelancer or a small local team. Communication tends to be easier, contracts are simpler, and there’s a fair chance they’ll still be available next year. What you may not get is structured project management, deeper design work, or robust testing processes.
The £38,000 quote usually comes from a smaller UK agency that has already invested time in proper discovery, detailed scoping, design input, testing, and post-launch support.
The £60,000 quote is often either a larger consultancy with higher operating costs or a team that identified technical complexity others failed to spot and priced accordingly. In some cases, it’s the only quote in the stack that’s genuinely accounting for the full workload.
The mistake is assuming all four suppliers are offering the same thing. They aren’t. They’re offering different levels of protection, process, support, and long-term reliability. Judging them purely on price is how businesses end up paying for the same project twice.
Risk never disappears, it just changes hands
Every custom software project carries risk. The only thing that changes between suppliers is who absorbs it.
A very cheap fixed-price quote with little or no discovery process usually leaves most of the uncertainty sitting with the client. Once the project begins and requirements turn out to be less straightforward than expected, integrations behave differently, or third-party APIs fail to work as documented, somebody has to absorb the extra time and cost.
With an experienced supplier that scoped the project properly, that problem is usually theirs to solve. With a supplier that underquoted, the problem often comes back to you through scope disputes, additional charges, delays, or software that never fully delivers what was originally expected.
Time-and-materials contracts shift risk in a similar way. They can look sensible and flexible at first glance, but they place the budget uncertainty almost entirely on the buyer. If the hours increase, the invoice increases. Unless you’re close enough to the process to challenge every logged hour, it becomes difficult to know whether the spend still matches the value being delivered.
That is why discovery work matters so much before development begins.
What proper discovery actually involves
Discovery is rarely the exciting part of a software project, but it’s the stage that determines whether everything afterwards runs smoothly or turns into damage control.
A proper discovery process gives the supplier enough understanding of your business, systems, workflows, constraints, and edge cases to produce a realistic scope and a realistic price.
That process usually includes conversations with the people who’ll actually use the software rather than only the person signing off the budget. It means reviewing the systems the software needs to integrate with, especially the awkward legacy ones everyone avoids talking about. It also means auditing any existing data the new system will inherit, because inherited data is almost always messier than expected.
Good discovery should also produce a written scope explaining exactly what will be built, alongside a separate list covering what will not be included. That second document prevents a surprising number of disputes later.
When suppliers skip discovery entirely and quote from a one-page brief, they’re pricing based on assumptions. The estimate may still end up correct, but at the time the quote is produced, they don’t actually know.
Proper discovery doesn’t need to become a month-long consultancy exercise. For most SME projects, it’s usually a handful of meetings, shared documentation, and a signed scope before development starts. The cost of doing that work properly is usually minor compared to the cost of discovering missing requirements halfway through the build.
The real comparison is the five-year cost
A £12,000 project that later needs £8,000 of rework, another £15,000 for a new developer to untangle the codebase, and months of operational disruption while the system limps along is no longer a £12,000 project. It’s a £40,000 problem with additional stress attached.
A £40,000 build that arrives properly documented, tested, and maintainable may still cost roughly the same amount five years later. In some cases, less, because the software remains stable enough that only minor updates are needed over time.
The more honest comparison is total ownership cost over the actual lifespan of the system, not the number sitting at the bottom of the original proposal.
Businesses burned by cheap software projects almost always say they wish they’d invested more at the beginning. Businesses that paid for quality upfront rarely complain they spent too much.
For a clearer picture of realistic pricing across different project sizes, this guide to UK app development pricing ranges breaks down common costs by complexity. If you’re comparing local suppliers against offshore options, it’s also worth looking at a bespoke software development company in London that offers fixed-price delivery across the UK.
What actually matters inside a quote
The line item that says “development: £X” is usually the least useful part of the proposal. The more important questions sit underneath it.
How much discovery has already happened? Has the supplier reviewed your systems, workflows, and operational edge cases thoroughly enough to commit confidently to the quoted number?
What does testing involve? Are there automated tests protecting the software every time changes are introduced, or is testing limited to manually clicking through a few screens before launch?
Will documentation be included? That means both technical documentation for future developers and operational documentation so your staff can train new employees without relying entirely on the original supplier.
Who owns the code once the project is complete? Under UK law, intellectual property ownership only transfers if the contract explicitly says so. A surprising number of low-cost agreements leave this vague.
What support exists after launch? Even a modest support agreement can save significant money the first time something fails during business hours.
How are changes handled once development begins? Every software project evolves. The important part is whether small changes are treated collaboratively or used as opportunities for constant additional billing.
How many people are involved in the build? A solo developer can be perfectly suitable for smaller projects. For larger systems, relying on one individual creates a genuine continuity risk.
Extremely cheap quotes usually hide something
If most suppliers return figures within a fairly consistent range and one proposal comes in dramatically lower, it’s worth examining what has been removed from the process, because something almost certainly has.
There is rarely a secret productivity advantage involved. More commonly, the supplier has misunderstood the scope, intends to recover costs later through additional charges, or excluded parts of the project that are essential for a reliable build.
Those missing pieces are usually the least visible during development and the most important later on. Documentation. Automated testing. Proper integration handling. Error management. Thoughtful system design. The underlying infrastructure work that keeps software stable when conditions stop being ideal.
Software can absolutely be built without those things. The problem is that somebody eventually has to fix the gaps, and fixing them later is usually far more expensive than building them properly from the start.
The one rule that matters
Choose the quote where it’s clear what you’re paying for, where proper discovery has happened before pricing, and where the supplier is likely to still exist when the software eventually needs updating or expanding.
If that supplier also happens to be the cheaper option, that’s perfectly fine.
If those fundamentals are missing, the savings usually reappear later as delays, rebuilds, support problems, or expensive redevelopment work.