How to Estimate a Web Project?

The short answer

A web project estimate is trustworthy when it shows its work. Not when it’s low, not when it’s fast, and not when it looks detailed.

A real estimate breaks the project into features, puts hours against each one, states the assumptions those hours depend on, names its own uncertainty, and explains what happens to the number when an assumption turns out wrong. A single figure with no visible reasoning isn’t an estimate — it’s a price. And a price given before discovery is a sales tactic.

If you remember one thing: ask the vendor what would make this number go up by 40%. A team that actually estimated the project answers in fifteen seconds. A team that guessed changes the subject.

Why the same brief comes back at 10x apart

You send one brief to five agencies and get $12,000, $28,000, $45,000, $90,000, and “let’s talk.” Most buyers conclude the market is irrational. It isn’t.

The first reason is that they’re not scoping the same product. Your brief said “user accounts.” One team read email-and-password. Another read SSO, role permissions, an admin panel, and GDPR-compliant data export. Both readings are honest. The gap between them is three weeks.

The second is that they’re not pricing the same certainty. A team that has built four marketplace platforms knows where the traps are — escrow logic, dispute flows, dual-sided onboarding — and prices them in. A team building its first doesn’t know what it doesn’t know, so its number is lower, right up until month three.

The third is that they’re not selling the same thing. Some quotes include discovery, design, QA, project management, deployment, and a warranty period. Others include developer hours and nothing else. The second number is always smaller and always incomplete.

Rates matter least. They explain a 2–3x spread, not 10x. When you see 10x, the problem is scope definition, not geography.

The useful reframe: you aren’t comparing prices. You’re comparing five interpretations of your idea. The cheapest one usually understood the least.

What has to be in the document

Six things.

A breakdown by feature rather than by phase — “Design: 120 hours” is a category, not an estimate. The assumptions the vendor made and you haven’t confirmed, written down, because every unstated assumption is a change request you’ll pay for later. A range rather than a point, because nobody has single-number precision before discovery. The non-build work — discovery, project management, QA, DevOps, handover — which realistically adds 40–60% on top of pure development hours and doesn’t disappear by going unmentioned. Explicit exclusions, since ambiguity always resolves in the vendor’s favour. And a short list of the unknowns that could move the number, which is the strongest single signal that you’re dealing with people who have done this before.

Missing three or more of these, and you can’t plan a budget around it.

How estimation actually works

Decomposition comes first, and it should go until each line is small enough that a senior person can size it confidently — roughly 4 to 40 hours. If a breakdown for a $30,000+ project has fewer than twenty lines, nobody decomposed anything.

Then each line gets sized three ways: best case, likely case, worst case, weighted as (best + 4 × likely + worst) ÷ 6. This exists because humans are systematically optimistic about work they haven’t started. Single-point estimates typically run 20–40% under actual on anything non-trivial.

Then multipliers. Undocumented legacy integrations add 20–40% to the features they touch. Regulated domains — fintech, health, gambling — add 25–50%. Real-time features like bidding or live tracking add around 30%. Native mobile alongside web isn’t a multiplier at all; it’s a second project. A design system built from scratch front-loads 80–150 hours and saves more than that later — but only if it’s in the estimate.

Then contingency, disclosed rather than hidden. With a detailed spec and documented integrations, 10–15%. With a clear vision but no spec, 20–30%. With “we’ll figure it out as we go,” 40% — or don’t fix-price it.

A vendor who says “we added 20% because the payment provider’s documentation is thin” is being professional. One who buries the same 20% inside inflated line items is teaching you not to trust the line items.

Seven questions that expose a guess

You don’t need technical knowledge to judge the answers. You’re testing whether they thought, not what they know.

1. What would make this number go up by 40%?
2. Which line are you least confident about, and why?
3. What assumptions did you make that I haven’t confirmed?
4. What’s in this number that isn’t development?
5. What happens when I change my mind in month two?
6. Show me a similar project — what was the final number versus the estimate?
7. If the budget were 30% lower, what would you cut first?

Question six is the best predictor of all. Teams that track estimate against actual are teams that estimate. Teams that don’t will find the question uncomfortable. Ask for the case studies behind the answer, not the logos.

Fixed price, T&M, or discovery first

Fixed price works when scope is genuinely fixed and documented, which is rarer than anyone admits. Time and materials works when scope will evolve and you’ll stay involved — but it gives you no number to show a board.

For anything over roughly $25,000, the right answer is usually a paid discovery and product audit phase followed by a fixed price. It feels like paying for a quote, and it isn’t: discovery produces a specification, wireframes, an architecture direction, and a risk register that you own and can take to any vendor. It costs 5–10% of the project and routinely strips 30% of the uncertainty premium out of the build price.

A fixed price given without discovery isn’t a commitment. It’s a bet, and the vendor priced themselves to win it.

Red flags

An estimate that arrived in under 24 hours for a project over $20,000. One number, no breakdown. No questions asked before the number appeared. A quote far below all the others — that vendor didn’t understand more, they understood less. No line for QA. A proposal that describes the vendor’s process instead of your product. “We’ll clarify the details during development.” A payment schedule that front-loads past 40% before anything is delivered.

U1CORE is a product studio for multi-sided platforms — marketplaces, exchanges, auction systems, and fundraising platforms. Over $720M has been processed through products we’ve built. We work across product design and custom software development, and we run discovery before anyone opens Figma.