How to Read a Development Estimate: Five Questions That Show Whether It Is Real

Two agencies look at the same brief and come back with estimates that are nowhere near each other. Neither is lying. They are answering different questions, and the document rarely says which.

Here are five questions that make the difference visible. They work on any estimate, including ours.

1. What weekly hours per person does this assume?

This is the single most useful question, and almost nobody asks it.

If a plan quietly assumes 40 productive hours per person per week, the calendar it produces is fiction. Standups, code review, design handover, clarifications, a broken pipeline, a sick day. All of it is real work that is not feature work.

When we plan, we count about 18 focused hours per person per week. That number is not a guess. Our largest recent platform ran 3,086 hours over 31 weeks with a team of five to six. Multiply the planning assumption out: 31 weeks x 5.5 people x 18 hours = 3,069 hours. The plan and the delivered project are 0.55 percent apart.

Ask the number. If the answer is 40, or if there is no answer, the timeline in front of you has not been planned. It has been divided.

2. Does this include QA and project management, or only development?

Across our work the split is roughly 70 percent design and development, 15 percent QA, 15 percent project management.

An estimate that shows only the development share looks about 30 percent cheaper than one that shows the whole build. It is not cheaper. The testing and the coordination still happen, they are simply not in the document you are comparing. That difference alone explains a large share of the gap between two quotes for the same brief.

When you compare, normalise first: ask both vendors to state QA and management separately, then compare like with like.

3. What does it assume about our existing systems?

A greenfield app answers only to itself. An app that has to work with your CRM, your billing, your warehouse system or a legacy database answers to systems that were not designed for it: someone else's data model, someone else's rate limits, someone else's downtime.

In our model that work is a module of its own, 70 to 180 hours depending on how many systems are involved and how well documented they are. Ask which of those systems the estimate assumed, because an estimate that does not name them has not priced them.

So ask specifically: which systems did you assume we have, which of them did you assume are documented, and what happens to the estimate if one of them is not. An estimate that does not mention your existing stack has not accounted for it.

4. Is this a range, and what moves it?

A single number before anyone has seen your requirements is a guess in a suit. The honest form is a range plus the two or three factors that move it.

In our experience the factor that moves ours the most is unclear requirements. Ambiguity does not stay in the document, it turns into a rebuilt screen in month three. That is why we start with discovery: it converts open questions into decisions while changing them is still free, and no later decision does as much for the range.

If you get a single number, ask what would have to be true for it to hold. The answer tells you whether anyone thought about it.

5. What is excluded?

Development estimates typically cover design, development, QA and release. They typically do not cover:

• ongoing support and maintenance after launch
• infrastructure and hosting
• third-party licences and paid APIs

None of these are hidden costs. They are a different budget line that starts when the build stops. The problem is not that they exist, it is discovering them in the month you planned to launch.

Three things that should make you slow down

A timeline with no discovery. If the plan goes straight from brief to development, someone has decided your requirements are already clear. They are not, and the cost of finding out arrives later at a worse moment.

A team that grows to hit your date. Adding people does not shrink the work, it runs it in parallel: more interfaces, more coordination, more rework. It buys some calendar back and costs hours to get it. That trade can be worth making, but it should be stated, not hidden inside a date.

Round numbers everywhere. An estimate where every line is 40, 80 or 120 hours was not built from the work. It was built from a feeling and then tidied up.

Do this before your next call

Run the numbers yourself first. Our cost calculator asks what you are building and which modules it needs, then returns the scope in hours, a realistic timeline and the team it takes. Walking into a vendor conversation with your own range changes it from a pitch into a comparison.

If you want the reasoning behind the hours, we wrote it out in how long it takes to build a mobile app, using the same project referenced above. If you want to know what an estimate is quietly assuming away, what actually goes wrong in app projects covers the five items that are usually missing.

And if you would rather just describe the project, tell us what you are building and we will come back with a scoped estimate and the assumptions written down.

Questions people ask

Is the cheapest estimate ever the right one?

Sometimes, but check what it excludes before deciding. In our experience the gap between two quotes for the same brief is more often a difference in what was counted than a difference in efficiency.

Should we ask for a fixed price?

A fixed price is a real option when the scope is genuinely fixed and documented. When it is not, the price still moves, it just moves through change requests instead of through the estimate. Fixed price is a scope decision before it is a commercial one.

How much detail should an estimate have?

Enough that you can see which modules drive the hours. If you cannot tell from the document which parts are expensive, you cannot make trade-offs, and trade-offs are the only real lever you have over the budget.

What if we do not know our requirements yet?

Then the first thing to buy is discovery, not development. Deciding what you are building is cheaper than building the wrong thing and rebuilding it.