You've got an idea. You're ready to build. And then someone quotes you £75,000 for something you thought would cost £15,000.

If that's ever happened to you or you're dreading it happening, you're not alone. Software cost estimation is one of the most misunderstood parts of building a tech product, and founders get burned by it all the time.

I've spent years working with startup founders as a fractional CTO or consultant, and the pattern is painfully consistent. A founder walks into a conversation with a dev agency or freelancer, doesn't quite know how to evaluate what they're hearing, and ends up either overpaying for something bloated or underpaying for something that falls apart six months later.

This article is the checklist I wish someone had given every founder I've worked with before they signed their first development contract.

Why Software Estimates Go Wrong

Estimating software is genuinely hard. Software development is abstract, requirements shift, and two developers can look at the same brief and quote wildly different numbers, both legitimately.

The Standish Group found that roughly 66% of technology projects end in partial or total failure. For a startup founder burning through savings or a seed round, a cost overrun of even 30% can be the difference between launching and shutting down.

The Checklist: 12 Questions to Ask Before You Commit

1. Do You Actually Know What You're Building?

This sounds obvious, but it's where most budget blowouts start. Write down what the software needs to do, not what it should look like. Focus on user actions: "A customer logs in, uploads a document, and receives an analysis within 30 seconds." That's a requirement. "It should feel modern and sleek" is not.

Action: Write a one-page brief that covers who uses it, what they do with it, and what success looks like.

2. Are You Getting an MVP Quote or a Full Product Quote?

One of the most expensive mistakes founders make is asking for a full product build when what they actually need is a Minimum Viable Product. A basic MVP typically needs much less time compared to a full complex product build. If someone quotes you for the full vision on day one, that's a red flag.

Action: Ask your developer to quote for Phase 1 separately. If they can't break it down even after clear requirements, that's the point you need to question things.

3. What's Included in the Quote—And What Isn't?

A quote might cover development, but what about UI/UX design, testing, server setup, third-party API integrations, post-launch bug fixes, documentation, and data migration? 

Action: Ask for a line-item breakdown. If possible, go phase-wise and ask to quote for the respective phase.

4. Who's Actually Doing the Work?

There's a big difference between a senior developer quoting 100 hours and a junior quoting 60. The junior's estimate might balloon to 150 hours because they'll hit problems the senior would have anticipated. Plus, not to mention AI tools are widely used by developers to generate code for the app, which could produce results that seem to work but are not always scalable.

Action: Ask who specifically will work on your project, their experience level, and whether the person quoting is the person building.

5. What's the Pricing Model?

Developers generally go with one of the pricing models below at a time. 

Fixed price: Total cost agreed upfront. Safe-feeling but rigid, additional changes trigger extra charges. 

Time and materials: Pay for actual hours/day of work. This could be more flexible and better for early-stage products. 

Dedicated team: Monthly retainer. Works well past the MVP stage.

Action: Ask partners which model they recommend for your stage and why.

6. Have You Talked to More Than One Provider?

Three quotes are the minimum. Don't just compare the bottom line; compare what's included, methodology, team composition, and communication.

Action: Get at least three quotes and create a comparison sheet. Check their communication, are they open enough to share the information that should be shared? Sometimes your gut feeling can play a major role here to help you make a wise decision. 

7. Is There a Discovery Phase?

A 2024 study of software engineers found projects with documented specs were 50% more likely to succeed, and those with clear requirements were 97% more likely to succeed. Discovery phases might come at a cost, but are insurance against tens of thousands of dollars wasted.

Action: Ask if the provider offers a discovery phase. If they want to skip to building, think carefully.

8. What Happens When Requirements Change?

They will change. The question is how they're handled. Is there a change request process? How are additional costs communicated?

Action: Ask for their change management process in writing before you start.

9. What Are the Ongoing Costs After Launch?

Software is never truly 'done'. Almost every software has ongoing development or maintenance. Annual maintenance costs run roughly 15–20% of the original build cost. If your MVP costs £40,000, budget £6,000–£8,000 per year.

Action: Ask for a post-launch cost estimate alongside the build quote.

10. Do You Have a Technical Advisor Who Isn't Selling You Something?

When you're non-technical, every conversation with a developer is an information asymmetry problem. Having someone in your corner who understands tech but isn't financially tied to the build changes everything. Think of it like having a surveyor when buying a house or a second opinion.

Action: Consider engaging a fractional CTO or technical advisor before committing to a build partner.

11. Are You Building Something That Already Exists?

Does a tool already exist that solves 80% of this problem? A good advisor will tell you when not to build. A bad one will let you spend £50,000 on something Airtable could have handled.

Action: Spend a good amount of time researching existing tools before committing to a custom build.

12. What Does Your Gut Tell You About the People?

Software projects are relationships. The best development partners educate you along the way. If someone's just nodding and taking your money, that's not a partnership, it's a transaction.

Action: Trust the conversations, not just the proposals.

Final Thought

Estimating software cost isn't about finding the cheapest option. It's about understanding what you're buying, from whom, and whether the numbers reflect reality rather than optimism. The founders who navigate this well learn to ask the right questions, surround themselves with the right people, and treat software like the investment it is.

If you're a startup founder about to commission your first build, sometimes a short conversation with someone who's been in the trenches can save you months of headaches. That's exactly what we do at LumenHarbor, offering CTO-level guidance to founders who want clarity, not confusion, when it comes to their tech decisions.

If that sounds useful, book a free 15-minute discovery call and let's talk through your situation.