Open with the problem you are solving, not a feature list. What kind of user will use this, how often, and what happens today? A vendor should you outsource or hire in house who grasps the purpose can propose an alternative that costs less; a team that receives only a feature list prices exactly what you asked for.

Describe the scope as user stories or scenarios: a walk through each important path. Every bit as useful, list what the first release deliberately excludes. A written out-of-scope list saves more disagreement later than any other single page. Also mark which decisions are settled and which may still change — honest teams price those differently, and pretending everything is fixed helps no one.

Set out your constraints. This means the platforms and services involved, the data you already hold and its condition, security and compliance rules, expected load, which devices matter and stacks you cannot change. If there is a hard date, explain what drives it: an experienced team is usually able to rearrange the plan to protect it, but not if the date is a secret.

Define what done means feature by feature. Clear acceptance criteria need not use special syntax: a plain-language note setting out what a user should be able to do will do. That one addition shortens acceptance testing considerably and software development technologies closes off most late-stage disagreement.

Finally, ask for a specific format. Require a breakdown by feature or module, the assumptions used, the risks the team sees and a range rather than a single figure. Read a wide range as information, not evasion: it tells you the part of the brief that needs work. Then tighten that section and ask for a new estimate — the revised figure will be the one worth planning around.