How to Scope a Web App Project Without Underquoting

Most web app projects do not go wrong because someone built the wrong thing. They go wrong because the quote was produced before anyone understood what the thing was.

The underquote is rarely a maths error. It is a scope that omitted four or five items nobody thought to ask about, each of which turns out to be days of work.

Here is what to ask before a number leaves your office.

The cost drivers nobody puts in the brief

Integrations. Every external system the app touches is work, and third-party APIs are consistently worse documented than expected. Ask: which systems, do they have an API, who holds the credentials, and is there a sandbox to test against? A brief listing five integrations usually has a bigger integration cost than core application cost.

Permissions. "Users can log in" is a small piece of work. "Five roles, with different visibility per record, plus SSO against the client's identity provider" is a significant one. Get the roles enumerated and ask what each can see and do — not in general, but per record type.

Data migration. Moving from an existing system is routinely underestimated. Old data is inconsistent, contains cases nobody documented, and needs cleaning rules that require the client to make decisions. Treat it as its own workstream with its own estimate.

Reporting. Clients say "some reporting" and mean something specific they have not described. Ask for the actual reports, the filters, and whether they need export. Reporting against a live transactional database also has performance implications at volume.

Anything real-time. Live updates, notifications, presence, collaborative editing. Materially more complex than request-and-response, and frequently mentioned in passing as though it were a checkbox.

Compliance. In regulated sectors: audit trails, data residency, retention rules, encryption requirements, access logging. These are real engineering, and they surface late if you do not ask early.

Environments and deployment. Staging, CI, deployment process, and who can run it. A system only one person can deploy is a liability you inherit at handover.

Questions that surface hidden scope

Ask these in discovery, before quoting:

• "What system does this replace, and what happens to the data in it?"
• "Who uses this, and does everyone see the same things?"
• "What does someone do today that this should stop them doing?" — surfaces the real workflow, which is usually more particular than the brief.
• "What has to be true for you to consider this finished?" — turns vague ambition into acceptance criteria.
• "Which of these would you cut if the budget were half?" — reveals the actual priority order, which is invaluable later.
• "Who signs off, and have they seen this brief?" — the unnamed stakeholder who appears at week six is a classic timeline killer.
• "Is there a deadline driven by something external?" — a trade show or contract date is a hard constraint; a preference is not.

Write the exclusions down

The most useful section of a proposal is what it does not include. This is where change-request disputes come from, and an explicit list prevents almost all of them.

Typical exclusions worth stating: content population, third-party licence costs, hosting and running costs, SEO migration, email deliverability setup, native mobile apps, training beyond an agreed session, and support past an agreed warranty window.

None of that is unreasonable to exclude. All of it is unreasonable to leave ambiguous.

State your assumptions

Every estimate rests on assumptions. Write them into the proposal:

• "Assumes the client provides API credentials and a sandbox by week one."
• "Assumes designs are signed off before build starts."
• "Assumes a single stakeholder for approvals."
• "Assumes existing data is exportable in a structured format."

When an assumption breaks — and one usually does — the timeline conversation is already framed as a shared fact rather than a dispute.

Have a change process before you need one

Agree it up front: how a change is raised, how it is estimated, who approves it, and how it affects the date. Then use it.

The failure mode is not clients requesting changes; that is normal and expected. The failure mode is absorbing them silently to seem accommodating, until the deadline arrives and the accumulated unbilled work becomes visible all at once.

Distinguish clearly between a defect ("it does not do what we scoped") and a change ("we want it to do something different now"). The first is yours to fix. The second is estimated. Conflating them damages the relationship in both directions.

Structure the estimate honestly

A few practices that hold up:

Estimate in ranges early, fixed prices late. A range communicates real uncertainty. A precise number implies knowledge you do not have yet.

Sell a paid discovery phase for anything substantial. A short, fixed-fee engagement to produce a specification, with the build quoted afterwards from real information. Clients who will not pay for discovery are frequently the ones who would have been hardest to satisfy.

Break the estimate into components rather than one total — core build, each integration, migration, reporting, deployment. It makes the number defensible, shows the client what drives cost, and makes cutting scope a conversation rather than a negotiation.

Do not pad silently. A hidden buffer distorts the client's understanding of what things cost. Contingency stated as contingency is more defensible and survives scrutiny.

If you are quoting work you cannot staff

Scoping is where a delivery partner earns their fee before writing any code. A partner who scopes properly asks the technical questions you would rather not field live on a client call, and tells you which parts of the brief are not tractable before you have committed to them.

That is the front half of white-label web app development. What happens after the proposal is signed is walked through in how white-label development actually works.