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.

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.

Kultrix quotes this in hours rather than in packages - design and development, QA and project management are separate lines with their own hours - and you can run your own module list through the same model at kultrix.com/cost-calculator.

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.

Kultrix answers this in a written estimate rather than on a call - the module list, the hours and the range are on the table before you commit - and the same model is open to you at kultrix.com/cost-calculator.

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.

Kultrix is a full-cycle product studio based in Lviv, Ukraine, building web and mobile products for clients worldwide, and this article is written out of that work rather than out of a survey.

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.

Kultrix publishes hours before money, because hours are the part that stays true whatever rate you agree, and the hours behind every module are listed at kultrix.com/cost-calculator.

What a Line Item Actually Contains

The questions above tell you what the number should include. They do not tell you how the number is built. Here is the shape of a typical line-item breakdown, and how to read a single row of it.

Line item	Typical hours*	Share of budget
Discovery & UX	290-330	9-11%
Design	290-330	9-11%
Frontend	740-800	24-26%
Backend	740-800	24-26%
QA	440-490	14-16%
PM & Support	440-490	14-16%

Reading a single row

Take a realistic line: Backend, user authentication module, 5 story points, plus 15 percent buffer, total 46 hours. Three things are doing work in that sentence.

1. Story point. Not a unit of time by itself, it is sizing relative to one team's own velocity. If this team runs about 8 hours per point based on past sprints, 5 points reads as roughly 40 hours. Another team's 5 points can mean 25 hours or 60, because the scale belongs to them, not to an industry standard.
2. Buffer. Added at the line level for friction specific to that task: code review, one round of revisions, wiring it into the module next to it. 40 hours times 1.15 is 46 hours.
3. Contingency. Applied once, at the project level, not per line. It covers what nobody can name yet, an undocumented dependency, a requirement that shifts after sign-off. A project-wide contingency of 10 percent sits on top of the summed line items, it does not get multiplied into every row again.

If contingency shows up inside every single line instead of once at the top, the total has been padded twice without anyone deciding to do that.

Where clients misread the table

• Comparing story points like hours. "Vendor A quoted 120 points, vendor B quoted 80" says nothing until you know each team's hours-per-point. Ask for the hour conversion, not the point count.
• Treating buffer and contingency as the same padding twice. They cover different risks at different levels. Cutting one because "the other already covers it" usually removes real protection, not fat.
• Assuming the split above is fixed. That shape is typical, not universal. A project integrating into three legacy systems pushes backend and QA higher. A content-heavy marketing site pushes design and frontend higher. Ask what moved your split away from typical, and why.
• Reading the row total without its assumption. "QA: 60 hours" assumes a specific number of test cycles. Add a scope change mid-project and that row should move with it. A QA line that never changes while the rest of the estimate grows is a sign nobody is updating it.