Why do software development quotes vary so much?

This is a conversation we're having with founders all the time now. They show us an app they've built in Lovable, Replit or one of the other AI tools and, at first glance, it looks pretty much finished. There's a login, a dashboard, the main feature works and it looks surprisingly good. They've spent £20 rather than £20,000, which is genuinely remarkable.

Then they decide they want to turn it into a proper product and ask a couple of developers for quotes. One comes back at £5,000 and another comes back at £50,000. They've both seen the same prototype, they've both been given the same description of what it needs to do, and both say they can build it. So what on earth is the extra £45,000 for?

That's where the confusion starts. It's tempting to conclude that one developer is cheap and the other is expensive, but very often they're simply not quoting for the same thing.

Why does the £5,000 quote look so plausible?

Because software is unusual in that you can see a lot of the product while seeing almost none of the engineering behind it. If your prototype has the right screens and you can click through the main journey, it feels like most of the work has already been done, and sometimes quite a lot has.

Ben Burch, co-founder of Allegr and the technical consultant who joins Rob Lynch and me on The One About AI, described this really well when he came on The Humans Behind the Tech. Allegr is also a client of ours, for full disclosure.

"Technology has always been a market in my eyes that's been very imperfect. You could get some website built for £500, £5,000 or £500,000 and often, to all intents and purposes, the consumer's experience of those things will be similar. So the market's quite fragmented and broken."

That was true long before AI. What vibe coding has done is make the gap between what something looks like and what's underneath it much bigger. The tools are incredibly good at getting something onto a screen quickly, which is why they're so exciting, but a working screen doesn't tell you much about how the data is structured, how permissions work, what happens when something fails, whether the system can cope with thousands of users or what another developer is going to find when they open the code six months from now.

Jason Margolin, a fractional CTO and formerly at Meta, put it nicely on The Humans Behind the Tech:

"People ask Lovable to “create a monday.com clone”, you'd be surprised by how many think that they can get away with building their own task management system in Lovable. There's a reason why they're a million dollar company and they've invested so much time and money into making the product. People think they can clone it in five minutes, which visually it might look the same, but it just won't work as well."

None of that means the person quoting £5,000 is lying to you, or even that their quote is wrong. They may simply be pricing a much narrower job.

So what is the £50,000 quote actually paying for?

A better question is probably: what has each person assumed is already solved?

The prototype may have dealt with the visible parts of the product brilliantly, while a larger quote is allowing for more of the things sitting behind them.

‍

‍

That's only an illustration, and paying more certainly doesn't guarantee that somebody is doing all of those things. But they are the kinds of questions I'd be asking, because they begin to explain why two quotes that appear to cover the same product can end up so far apart.

The other difference is often the team itself. A freelancer can be an excellent choice, particularly for a smaller product, but the trade-off is that you're naturally more dependent on one person.

Nick Sales, a fractional CTO and a regular at Tech Startups in the Pub, described the decision like this when he came on The Humans Behind the Tech: What a Fractional CTO Actually Does

"People wanting to hire a single developer to do everything instead of taking my advice, which is very frequently much more like maybe a development agency is the best way of doing this, because the costs will be explicit, they can ramp up, they can ramp down, they'll get the skills you don't know you need because you don't know we need them yet. As opposed to Dave down the road who works in his garage, and he might get another job at some point, and then suddenly where will you be?"

That's obviously an argument in favour of agencies, and I run one, so take it in that context. But the broader point is important: part of what you're buying may be resilience rather than code, and resilience is very difficult to see in a demo.

Why am I being asked to pay for planning when I've already built the thing?

This is probably the most frustrating part. You've already got an app you can click around, then somebody comes along and says they want to spend time discussing user roles, data structures, edge cases and architecture before they start building. It can feel like going backwards.

After six years and 60-odd software builds, though, I've become fairly boring about this: a bit of thinking at the beginning always costs less than discovering halfway through the build that something fundamental doesn't work.

One useful test is simply to look at the questions you're being asked before you receive the quote. How many users are you expecting? What data are you storing? Are there different types of users? Who can see what? What happens when something goes wrong? Which third-party systems does it rely on? What needs to happen after launch?

If somebody is asking those questions and somebody else isn't, that probably explains at least some of the price difference. Nick put the alternative rather more colourfully:

"If you are jumping in and just paying people time and materials to develop something that's delivered to them on the back of envelopes and through conversations and with no formal design process, that's a great way of getting rid of all your excess money. I've seen that happen on more than one occasion, unfortunately."

You don't need months of workshops and enormous specification documents, but somebody does need to think through the difficult bits before you're halfway through building them. That's why we treat discovery as part of the build rather than an optional extra.

Can't a developer just finish the prototype I've already made?

‍

Yes, sometimes they absolutely can. I don't think founders should automatically be told that everything they've made with AI needs to be thrown away and rebuilt. 

The real question is whether you've built a useful technical foundation or a very good description of the product you want. Sometimes it's both. Sometimes the screens are excellent but the code underneath needs work, sometimes parts of the application can stay and others need rebuilding, and sometimes starting again is genuinely cheaper than trying to unpick what is already there.

My co-founder, Rob Lynch, described one of the problems on episode one of The One About AI:

"Often you'll end up with something that is bloated and you'll have gone in different directions and different tangents trying to build different features. And there'll be a ton of obsolete code sitting there, which every single time you try to add a feature and make it more complicated, the AI has got to work with its own ugly beast to try to add on to it. And if you go too far down that route, getting humans to try and unpick what's been done is incredibly tough."

I rather like "its own ugly beast" because we've seen exactly that. You add something, change your mind, ask the AI to alter it, add another feature, remove half of the first one and keep going. From your point of view the product is improving, but underneath you may also be accumulating a lot of things you no longer need.

Ben described the slightly painful economics of it as: "notionally I spent £20 getting this far, but it's going to cost me, say £10,000 to get me to the next stage."

That's the bit AI hasn't removed. It has made getting the first version enormously cheaper, but getting from a convincing prototype to something you can confidently put customers onto is still a different job. We've written more about that in Your vibe-coded app is 80% done.

So which software development quote should I choose?

Not automatically the expensive one, because that would be just as daft as automatically choosing the cheapest.

If you're building an internal tool for five people, there's no sensitive data involved and the consequence of it going down for an afternoon is somebody making another cup of tea, the £5,000 option might be entirely sensible. If you're taking payments, storing customer information, integrating with critical systems or planning to build a business around the product, there are more things that need to be thought through.

Equally, a £50,000 quote can still be a bad quote. A large number with a glossy proposal attached isn't evidence that somebody knows what they're doing.

What I'd want to understand is what each quote actually includes. What happens after launch? Who fixes problems? How has security been approached? What testing is included? What happens if usage grows faster than expected? What parts of the existing prototype are being kept, and what is being replaced?

Ask both bidders the same questions and the difference between the quotes tends to become a lot less mysterious.

And don't throw your prototype away. Even if not a single line of its code eventually survives, you've still done something extremely useful because you've turned an idea in your head into something a development team can see, use and discuss with you. Before these tools existed, getting to that point could itself take weeks.

The mistake isn't building the prototype. It's assuming that because the prototype looks 80 per cent finished, the engineering is 80 per cent finished too.

If you've built something over a weekend and now have two wildly different quotes sitting in your inbox, we're happy to have a look under the hood and tell you what we think, including if the cheaper one is perfectly fine.

‍