Start with the reason this bespoke software development should exist, not a list of screens. Who will use the system, how often, and how is the job done today? An estimator who knows what you are trying to achieve can propose a cheaper route to it; a team that receives only a feature list will price exactly what you asked for.
Set out the scope as concrete flows: what the user does and what the system does in response. Just as important, write down what the first release deliberately excludes. A written out-of-scope list prevents more argument at delivery time than almost anything else in the document. Also mark which parts are firm and which are still open — the difference changes the price, and hiding it only hurts you.
Set out your constraints. The list covers the platforms and services involved, the data you already hold and its condition, compliance requirements, traffic expectations, which devices matter and stacks you cannot change. Where a date is genuinely fixed, explain what drives it: a team can often cut the right scope to hit it, but not if the date is a secret.
Say what done means for each item. Acceptance criteria do not require formal language: a short list describing what a user should be able to do is sufficient. This single habit reduces the review at the end considerably and closes off the usual argument at handover.
Finally, say what you expect back. Ask for a task-level breakdown, a written list of assumptions, laravel or django whatever the team considers risky and an optimistic and a pessimistic figure. Take a broad range as information, not evasion: it tells you where your description is thin. From there rewrite that part and ask for a new estimate — the next version tends to be far closer to reality.