How to Evaluate a Software Development Estimate (Before You Sign)

A software estimate is only as good as the assumptions written next to it. A credible one breaks the work into pieces, states what's included and excluded, names who does the work, defines "done", and carries an explicit allowance for risk. If you get one total and a timeline, you have a guess, not an estimate.

You've got a quote from an agency or a dev team. Maybe two or three. The totals are far apart, the documents look nothing alike, and you can't tell which one is realistic, or whether any of them are.

I've been on the other side of this table for a long time. For eight years I was Director of Development & Operations at Business Builders, where we delivered six-figure web application projects, so I've written plenty of estimates and lived with the results. Here's how I read one now when a founder asks me whether to sign it.

What should a credible software estimate include?

The total is the least useful number on the page. What tells you whether an estimate holds up is everything around it. A credible estimate has these seven things:

1. A scope breakdown. The work split into features or deliverables, each with its own estimate. Small enough pieces that you can see where the time goes.
2. Written assumptions. "Assumes you supply all content." "Assumes the payment provider's standard checkout." Every assumption is a place the price can move, so you want them in writing.
3. Exclusions. What is not included. A good vendor is specific here because it protects both of you.
4. Risk and contingency. The parts they're unsure about, and an explicit allowance for them. An estimate with no uncertainty in it isn't confident. It's hiding something.
5. Who does the work. Named roles, seniority, and whether any of it is subcontracted. The senior person in the sales meeting may not be the person writing the code.
6. A definition of done. Tested, deployed to production, documented, handed over. "Done" meaning "works on the developer's laptop" is a different price.
7. How change is handled. What happens when you want something different halfway through, and how it's priced.

If three or more of those are missing, don't compare the total with anything. Ask for them first.

What are the red flags in an agency quote?

Most bad estimates aren't dishonest. They're optimistic, rushed or written to win the deal. Either way, you pay for it later. Here's what to watch for:

A fixed price on a vague scope is the one I'd push back on hardest. It feels safe because the number can't move. But the vendor knows the scope will move, so they either price in a big cushion or defend every line of the original brief. Neither is good for you. Fixed price works when the scope is genuinely fixed. Otherwise, pay for a short discovery phase first and fix the price after. The best discovery phase ends with a clickable prototype you sign off as the agreed scope, so the fixed price is attached to something you've actually seen.

The hidden line items most estimates leave out

These are the lines that turn a reasonable estimate into an over-budget project. If you don't see them, ask where they are:

That last line matters more than people expect. As a general rule, maintaining a system over its life costs more than building it. An estimate that stops at launch shows you the smaller number.

Before any of these, there's one more question: should this be built at all? A client once came to me with budget approved for iPhone and Android apps. I told them not to build it, and we shipped a responsive web app with PWA features instead. The story is in PWA vs Mobile App. The same question applies to anything you could buy instead, which I cover in Build vs Buy Software.

Why do software estimates go wrong?

Not usually because developers are bad at maths. Estimates go wrong for predictable reasons:

• The scope was discovered, not defined. Nobody wrote down what the software must do, so the team found out by building it. Every discovery adds time. A clickable prototype moves those discoveries to the start, where they're cheap. Your team taps through real screens, finds the missing steps and the wrong assumptions, and you sign off on the prototype as the agreed scope before production code is written.
• They estimated the coding, not the delivery. Writing the feature is often the smaller part. Testing it, integrating it, deploying it and fixing what launch reveals is the rest.
• The last stretch is the long one. Getting to a working demo is fast. Getting to something reliable is slow. I wrote about that gap in Why Your AI Project Is Stuck at 80%, and it applies to any software project.
• The spec lives in the old system. When you replace existing software, the real requirements are in how it behaves today, including all the edge cases nobody remembers asking for. On one legacy platform, a previous rebuild had stalled at roughly 18%. We upgraded the existing application in phases instead.
• Incentives point the wrong way. The estimate that wins the work is often the lowest one, not the most accurate one.

An estimate is a forecast, not a promise. Your job isn't to find one that can't be wrong. It's to find one whose risks are visible, so you can see them coming.

What questions should you ask before you sign?

Take these into the meeting. The answers matter, but so does how comfortable the vendor is answering them:

1. Which parts of this estimate are you least sure about, and why? A good team answers immediately.
2. What assumptions would change the price the most?
3. Who exactly will work on this, and how much of their time?
4. What does "done" mean for each piece? Tested? Deployed? Documented?
5. Where are testing, deployment, data migration and post-launch support in this?
6. How do you handle changes, and how are they priced?
7. How will I see progress week to week? A shared board, a demo, a report?
8. What do you need from me, and by when?
9. Who owns the code, the hosting accounts and the domain at the end?
10. What would you cut first if we needed to reduce the cost?
11. Will I click through a working prototype before you write production code, and can I sign it off as the scope?

Question 7 is the one founders skip. At Business Builders I rescued an at-risk SaaS client relationship partly by giving the client an external Kanban board so they could see the work, along with code standards and an 8-stage workflow. Visibility is cheap, and its absence is how small slips become big surprises.

How do you compare two quotes that look nothing alike?

Don't compare the totals. Compare the scope.

Lay the quotes side by side and list every feature and every line item from the hidden list above. Mark which quote includes each one. You'll usually find that the cheaper quote is cheaper because it's quoting less: no migration, no automated tests, no post-launch support, or a vaguer definition of done.

Better still, make the quotes describe the same thing. Ask for a clickable prototype before you sign, and make the signed-off prototype the scope. A written spec leaves room for two vendors to picture two different products. A prototype doesn't: every screen, field and step is there to point at, so both quotes price exactly what you'll get. If you already have one, hand the same prototype to every vendor. You can click through some working prototypes to see what one looks like.

Then compare who's doing the work and how risk is handled. A slightly higher quote with clear assumptions, a named senior team and an explicit contingency is often the cheaper project in the end, because fewer surprises turn into change requests.

Is my developer's estimate realistic? If it has a breakdown, written assumptions, exclusions, a stated contingency, named people, a definition of done and the hidden lines accounted for, it's probably a serious estimate. Whether the numbers themselves are right takes someone who has built similar software to judge.

When should you get a second opinion?

Get one when the contract is big enough that being wrong would hurt, when the quotes disagree widely and you can't see why, or when the work replaces a system your business runs on. Also get one when you're being asked to sign before the scope is clear.

A second opinion isn't about catching the vendor out. Most are doing their best with what they were told. It's about making sure what they were told is complete, and that the risks are on the page instead of in your future.

This is exactly what a Technical Assessment covers. I read the estimate and the scope behind it, compare it with what the work actually involves, and tell you plainly what's missing and what it's likely to cost. For bigger commitments, like taking over an existing product or team, the scope widens into a full technical due diligence checklist.

FAQ

Related Reading

• Technical Due Diligence Checklist: What I Check Before You Buy, Invest or Sign: The full checklist for when the commitment is bigger than one contract.

• Build vs Buy Software: How to Decide, With the Real Costs: The question to answer before you collect quotes for custom work.

• Why Your AI Project Is Stuck at 80% (And How to Actually Ship It): Where the last, most underestimated stretch of a project hides.

If you're holding a quote you can't judge and a contract you're about to sign, get the estimate read first. Get in touch if you want a second opinion before the money moves.