Break the scope down until each piece is arguable
-
List deliverables, not activities
"Checkout with saved cards" is something the client can accept or reject. "Backend work" is not, and an estimate built from it cannot be defended line by line when the total is questioned.
-
Price each piece against a known comparison
Estimate a feature by naming the closest thing already built and the ways this one differs. It is more accurate than a fresh guess and it makes the reasoning visible.
-
Separate the discovery from the build
Where the requirements are genuinely unknown, quote a fixed discovery phase whose deliverable is a firmer estimate. Guessing the whole project is how a project is priced twice.
-
State what is not included, item by item
The exclusions do more work than the inclusions on a project of any size, because everything unstated is assumed by whoever assumes most generously.
Integrations carry the risk
Anything depending on a system you do not control — a payment provider, a CRM, a shipping API, a client's existing database — is where estimates break, because the work is not writing the call but discovering what the other end actually does. Price integrations separately, say which version or endpoint the figure assumes, and treat sandbox access as a prerequisite rather than a detail.
Content is the usual delay
What moves a development number up
- Migrating data from an existing system, which is bounded by the old data's quality and not by the new schema
- Support for older browsers or specific devices, which is testing effort rather than build effort
- Accessibility conformance to a named standard, which touches every screen rather than being a phase
- Rounds of design revision beyond an agreed number, which is the most common scope creep in the trade
- Environments, deployment pipelines and handover documentation, none of which appear in any screenshot
Hold the price for twenty-one days
Valid for 21 days, and it is a scheduling figure rather than a cost one. The estimate assumes particular people are free in a particular window, and a project accepted two months later is quoted against a team that no longer has that gap. Say what the figure assumes about availability, so that a late acceptance is a conversation about dates rather than an argument about price.
Common questions
- Should development be estimated in hours or by feature?
- By feature, wherever the scope is known well enough. A client can accept or reject a deliverable; an hour count invites a negotiation about speed rather than about what is being built.
- What should a discovery phase produce?
- A firmer estimate. It is quoted separately and fixed, and its purpose is to replace the guess about the unknown part of the project with something both sides can commit to.
- Why do integrations blow up estimates?
- Because the effort is in finding out how the other system behaves rather than in writing the code that talks to it. Naming the version, endpoint and sandbox the figure assumes is what keeps that discovery from being unpriced.