Mariel Desailly

Start with the business problem, not a list of screens. Which people will use this, how often, and how is the job done today? An estimator who knows what you are trying to achieve will suggest a cheaper route to it; someone handed only a feature list prices the list as written.

Define what is included as user stories or scenarios: what the user does and what the system does in response. Just as important, state explicitly what the first release deliberately excludes. An explicit exclusion list removes more disagreement later than any other single page. Mark too which items are decided and which may still change — the difference changes the price, and dedicated teams vs freelancers hiding it helps nobody.

Set out your constraints. These include systems you must integrate with, the data you already hold and its condition, compliance requirements, user volumes, target platforms and stacks you cannot change. If there is a hard date, say what depends on it: a team can often rearrange the plan to hit it, but only if they know it exists.

Say what the word done means for each item. Testable acceptance criteria need not use special syntax: a short paragraph setting out what must be true when the feature works is enough. This one section shortens the review at the end considerably and removes the usual argument at handover.

To close, ask for a specific format. Request a task-level breakdown, the assumptions used, whatever the team considers risky and an optimistic and a pessimistic figure. Read a wide range as a signal about the brief: it usually points to where your description is thin. From there rewrite that part and ask for angular consulting services a new estimate — the next version will be the one worth planning around.