How to estimate an app project for a client

Most estimates miss for the same reason scopes do: they are made from the idea of the app rather than from its plan. The screens nobody listed, the error states and the admin tools are not in the number, so they turn up later as an overrun.

Count what the specification commits to, and estimate each part separately.

• Screens and their states.
• Server operations — the API endpoints.
• Entities in the data model.
• Integrations with external services.
• The work around the features: security, accessibility, testing and deployment.

A range with its drivers is easier to accept than a single figure. When the client can see that the server operations and a payment integration account for most of the effort, the discussion moves from “why so much” to “what do we need first”.

Every estimate carries uncertainty. State a range, list the assumptions it rests on, and name the open questions that could move it. Answer those questions before you commit to a fixed price.

The estimate says how much work there is. The price is a commercial decision on top of it: your rates, the risk you take on, your margin and the relationship with the client. Keeping the two apart lets you revisit either one without reopening the other.

When the scope changes, compare the new plan with the approved one and estimate only the difference. A change request that arrives with its own estimate is much easier to agree than a surprise at the end of the project.

In Throughplan, the estimate is written after the specification and prices what the specification actually contains: its endpoints, its entities and its acceptance criteria. It cites the drivers behind the number, and it is marked out of date whenever the plan changes.

While the wireframe is still being drawn, no estimate is shown at all, because a number read off an unfinished plan invites being quoted. The client documents describe the scope of work; the price is always yours to set.