How To Write A Project Brief That Earns A Reliable Estimate

Begin with the business problem, not your preferred technology. What kind of user will use the system, how many times a day, and what happens today? A vendor who knows what you are trying to achieve can propose a cheaper route to it; someone handed only a feature list prices your assumptions along with the work.



Set out the scope as concrete flows: what the user does and what the system does in response. Every bit as useful, list what you are not building. A written out-of-scope list saves more friction later than any other single page. Indicate as well which decisions are settled and which are still open — estimators price uncertainty, and hiding it helps no one.



Set out your constraints. These include existing systems the mvp software development has to talk to, the data you have and where it lives, security and compliance rules, traffic expectations, supported browsers or symfony vs laravel devices and any technology you are committed to. Where a date is genuinely fixed, say what depends on it: an experienced team will often resequence the work to meet it, but not if the date is a secret.



Say what done means feature by feature. Testable acceptance criteria do not need any formal notation: a short paragraph setting out what a user should be able to do will do. This single habit shortens the review at the end by a surprising margin and removes the usual argument at handover.



Finally, ask for a specific format. Ask for a task-level breakdown, a written list of assumptions, the risks the team sees and a low number and a high number. Read a wide range as a signal about the brief: it normally identifies where your description is thin. At that point clarify that area and request a revised number — the next version tends to be the one worth planning around.