Start with the problem you are solving, not a list of screens. What kind of user will use it day to day, how often, and what happens today? A vendor who knows what you are trying to achieve can propose an alternative that costs less; one who only sees a feature list prices the list as written.
Define what is included as concrete flows: what the user does and what the system does in response. Just as important, write down what you are not building. An explicit exclusion list saves more disagreement during acceptance than almost anything else in the document. Mark too which items are decided and which are still open — the difference between laravel and django changes the price, and hire experts react native app developers hiding it helps nobody.
List the constraints. This means systems you must integrate with, existing databases and their quality, regulatory obligations, traffic expectations, supported browsers or devices and infrastructure that is already decided. If there is a hard date, explain what drives it: a team is usually able to cut the right scope to protect it, but not if the date is a secret.
Say what completion means feature by feature. Testable acceptance criteria do not need formal language: a short paragraph describing what must be true when the feature works will do. That one addition compresses the review at the end considerably and closes off the usual argument at handover.
One last thing, state what you want in the response. Require a breakdown by feature or module, the assumptions behind each number, whatever the team considers risky and a low number and a high number. Treat a wide range as a signal about the brief: it tells you the part of the brief that needs work. Then clarify that area and ask for a new free development estimate — the next version tends to be the one worth planning around.