How to scope an app project with a client

A client usually arrives with a vision: what the app is for, and a handful of screens they can already picture. What they rarely have is the rest — the screens that make the whole thing work. Sign-up and password recovery, settings, empty and error states, admin tools and notifications are all part of the app, and none of them is in the first brief.

When the scope is agreed on the vision alone, those screens surface during development. Someone then has to absorb the extra work, and the conversation about who pays for it starts after the contract is signed.

Good scoping moves that discovery forward, to a point where it is still cheap: before the estimate, and before the quote.

List who uses the app and what each of them needs to get done. A booking app, for example, has at least a customer, a provider and someone who administers both.

• Every role that signs in, including your client’s own staff.
• The main task each role comes to the app to do.
• What each role must never see or change.

Roles are where unplanned scope hides most often: each one brings its own screens, permissions and notifications.

For each main task, walk the path a user takes, screen by screen, and ask what happens at every step when things do not go to plan.

• What does the user see before there is any data?
• What happens when a payment, an upload or a request fails?
• Can the action be cancelled or undone, and until when?
• Where does the user land when they are done?

A clickable wireframe makes this concrete. A client who can click through a flow notices a missing step far sooner than one reading a list of features.

Before you estimate, review the whole plan for what is missing rather than for what is there. The usual gaps are screens nothing links to, dead ends with no way back, forms without validation messages, and states nobody designed: empty, loading, failed and expired.

Write each open question down and agree an answer with the client. An assumption you record now is an argument you do not have later.

Developers need more than screens. The specification describes each screen’s behaviour and required fields, the data the app stores and the server operations it needs.

Keep it tied to the wireframe, so that a change to a screen is also a change to the specification. A specification that lives in a separate document starts drifting from the design with the first revision.

An estimate built from the specification can be explained line by line: this many screens, these server operations, these integrations. An estimate built from the idea can only be defended by experience, and it is the first number a client pushes on.

Present the effort, the assumptions behind it and what is out of scope. Set the price on top of that as a decision of your own.

The scope will still change once development starts. Agree up front how: the approved version of the plan is the baseline, and every change is compared with it and estimated before anyone builds it.

Throughplan was built for this workflow. You describe the app to an AI assistant, which draws the screens and the navigation between them as a clickable wireframe.

• Built-in agents check the plan for missing states, unreachable screens and unclear requirements.
• The frontend, backend and database specification is written from the agreed plan, followed by an effort estimate that shows what drives it.
• Your client opens the project from a share link and comments on the screen they are looking at.
• On Pro and higher plans, you approve the specification and compare later changes with the approved version.