Most estimation mistakes are visible in the quote before anyone writes code. A number with no list of work behind it, no line for testing, a single date with no range: each one tells you the estimate will move. You don’t need to be technical to spot them. You need to know what to look for.
If you’re a founder or product owner about to accept a quote, from us or anyone else, run these eight checks first. Two of them cover rules that changed in 2025 and 2026, and the section after them shows how our own estimate ties every hour to work you agreed to.
| Mistake | How it shows up in a quote | The check |
|---|---|---|
| 1. Pricing a feature list | “User accounts: 40 hours” with no detail | Every line traces to a user story with acceptance criteria |
| 2. Taking the brief at face value | Payments priced without refunds or failed cards | Ask what each feature includes and excludes |
| 3. One number instead of a range | “$12,000, 6 weeks” | A range, plus what would move it up or down |
| 4. An ideal 8-hour day | Hours divided by 8 to get days | Ask how many focused hours a week the plan assumes |
| 5. Missing the work around features | No lines for QA, release or store review | QA, release and outside services have their own lines |
| 6. Ignoring the rules for your market | Accessibility or platform rules not mentioned | The rules that apply to you are in the scope |
| 7. No change control | “Small” requests added without a new number | Every change gets an estimate before work starts |
| 8. Never checked against past work | Hours from memory or from a template | The vendor compares estimates with what finished projects took |
“User accounts” can mean an email sign-up, or social login, password reset, two-factor codes and account deletion. Two teams can price the same words at 20 hours and at 200, and both can be honest. The gap comes from what each one pictured.
A user story with acceptance criteria closes that gap. “As a customer, I can reset my password by email; the link expires in an hour” is something you can price and later test. If a vendor can’t write the stories yet, the scope isn’t ready for a fixed number. A short discovery comes first. Ours is a 1-week sprint for $3,000 that counts toward the build on our MVP development page.
Founders describe the product they see. Developers build everything around it. “Users can pay” turns into payment provider setup, failed cards, refunds, receipts and an admin view of who paid.
Inherited code is the biggest hidden item. When Livetag came back to us after another contractor, there was an existing codebase and stack to work with under strict deadlines. We built the team around the stack already in the code and delivered in two iterations: refactoring first, new features second. Before you accept a quote for a takeover, ask whether the vendor has read the code. If not, the estimate is a guess about someone else’s work.
A single number hides how sure the estimator is. A range shows it, and the reasons behind the range tell you where the risk sits: “the top end assumes the bank API needs a workaround” is useful, “+20% just in case” is not.
The wording matters too. When this article first ran, Oleksii Zherebnykh, a business analyst at Rocketech, put it this way: “Saying ‘We’ll need from 80 hours’ instead of ‘We’ll need up to 80 hours’ helps minimize the negative response in case of delays.” An estimate is a forecast. Our guide to agile project estimation challenges explains why a forecast is not a commitment, and how it gets better with every sprint.
Nobody codes for eight hours straight. Reviews, meetings, questions, waiting for access and fixing yesterday’s bug all take time from the same day. In Atlassian’s State of Developer Experience 2025, a survey of 3,500 developers and managers, developers said they spend only 16% of their time coding. Half of them lose 10 or more hours a week to inefficiencies.
If a quote turns hours into days by dividing by eight, the dates will slip even when the hours are right. Ask how many focused hours a week the plan assumes for each person.
Testing, release and outside services take hours like any feature. They are also the lines that vanish first when a quote has to look cheap.
App stores add their own work, and the rules change every year:
On a personal account, the last one adds at least two weeks to a launch plan before the first public download. Store review needs room in the plan too. On Traza, a booking app for tattoo artists with a launch date already promised, we sent the app to review early instead of polishing it until the last day. It was approved on both stores.
Some requirements come from the law, not from your feature list. In the EU, accessibility requirements apply to products and services placed on the market after 28 June 2025, including online shops, ticketing platforms and banking services. Service businesses with fewer than 10 employees and under €2 million in turnover are exempt (Your Europe, European Commission).
Whether a rule covers your product is a question for a lawyer. Whether the estimate includes the work is a question for the vendor. If you sell in the EU and the quote doesn’t mention accessibility at all, ask.
Scope changes during a build, and it should. The mistake is letting changes in without a number. Each “small” request eats time planned for something else, and the overrun shows up at the end, when it’s too late to choose.
A simple rule works: every change goes into the backlog with an estimate, and something of the same size moves out or the budget moves up. On Traza, the custom calendar grew bigger than planned. We cut it to a first version and moved push notifications and booking creation forward, because artists needed those more. When the client later added two more epics, they still fit inside the agreed budget.
An estimate made from memory repeats the same blind spots. The fix is dull and it works: write down what each finished project took and compare it with the estimate. Over time that record shows what a team always underestimates, such as integrations, store review or data migration.
Ask a vendor how they check their numbers. A useful answer names a method, such as “we compare with booked hours on similar finished projects”.
Our project estimate turns your brief into user stories. You confirm what is in scope, and every hour in the budget traces back to a story you kept. Uncheck a story and its hours come off. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour. You get an hours range, a budget range and a number of weeks. It is a planning range, not a fixed quote.
Here is an example run of our estimate’s math with sample inputs: a payments app built on a licensed payment provider, with onboarding and identity checks, balances, transfers and a back-office panel. Every input is an assumption. Only the arithmetic is ours.
| Phase | Hours |
|---|---|
| Discovery and UX: onboarding and identity check flows, wireframes | 22 |
| Design: UI kit and key screens | 22 |
| Frontend: mobile app (onboarding, balance, transfers) and back-office panel | 74 |
| Backend: accounts and ledger API, security, audit log and limits | 72 |
| Integrations: payment provider and identity check vendor | 28 |
| QA: test plan, regression and security checks | 32 |
| Release: app store and production | 10 |
| Total | 260 hours, a budget of $8,700-18,000, about 4 weeks |
Integrations, QA and release come to 70 of the 260 hours. Those are the lines a feature list leaves out.
The same run also asks whether the build pays back, from five guesses: $6 of revenue a month per active user, a 60% margin, 18 months as a customer, $25 to win one and 400 new users a month. With those guesses each user leaves $4 a month and $72 over their lifetime, or $47 after the cost of winning them. 285 users pay for a $13,350 build, the middle of the range, and the build is paid back in month 13. Change any guess and the math updates. The point is to see which guess your plan depends on. You can estimate your MVP’s cost and timeline the same way in about four minutes.
A market number is a sanity check, not an estimate. Across 95 agencies, the median published MVP starting price is $13,234 and the median promised timeline is 6 to 12 weeks (Rocketech MVP Price Index 2026, H2). Those are published prices, not what agencies charge after scoping. Our own MVP builds typically cost $5,000-15,000 and take 2-4 weeks, because the first release is kept narrow.
Pricing a list of features instead of user stories with acceptance criteria. The same words can mean 20 hours to one team and 200 to another. Stories make the scope specific enough to price and to test.
Usually because work was left out, not because developers were slow. The usual gaps are testing, release, store review, integrations, rules such as accessibility, and changes that went in without a new estimate.
A range, with the reasons for each end. A single number hides how sure the estimator is, and it turns a forecast into a promise before the scope is fixed.
A first planning range can take minutes if the brief is clear. A fixed price needs written scope, which often means a short discovery first.
For an ongoing team, estimation mistakes affect capacity and cash as well as release dates. Review our dedicated-team service and the Livetag case to discuss prioritization, reporting and the boundary between forecast effort and a contractual commitment. Explore dedicated development team and the Livetag case study.
Discuss team capacity and estimation uncertainty
Start with an AI-assisted project brief covering scope, budget, market assumptions and risks. Review its hypotheses before making a commitment.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.