Begin with the reason this software should exist, not your preferred technology. What kind of user will use it day to day, with what frequency, mvp development cost 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 the requirements as given 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. Every bit as useful, state explicitly what you are not building. A written out-of-scope list prevents more argument during acceptance than any other single page. Also mark which parts are firm and which may still change — the difference changes the price, and pretending everything is fixed helps no one.
Write down the hard constraints. The list covers the platforms and services involved, the data you have and where it lives, security and compliance rules, expected load, supported browsers or devices and stacks you cannot change. If there is a hard date, explain what drives it: an experienced team will often rearrange the plan to hit it, but only if they know it exists.
Define what the word done means feature by feature. Acceptance criteria need not use special syntax: a plain-language note describing the expected behaviour will do. This one section shortens the sign-off process considerably and eliminates most late-stage disagreement.
Finally, state what you want in the response. Require a task-level breakdown, a written list of assumptions, the risks the outsourcing dedicated team sees and an optimistic and a pessimistic figure. Read a wide range as a signal about the brief: it tells you where your description is thin. At that point tighten that section and request a revised number — the second estimate tends to be far closer to reality.