Start with the problem you are solving, not your preferred technology. Who will use it day to day, how often, and what happens today? An experienced team who knows what you are trying to achieve can propose a cheaper route to it; one who only sees a feature list will price exactly what you asked for.
Describe the scope as short scenarios: who does what, and what happens next. Just as important, state explicitly what is out of scope. A written out-of-scope list prevents more friction later than any other single page. Mark too which decisions are settled and which may still change — estimators price uncertainty, and pretending everything is fixed only hurts you.
List the constraints. The list covers systems you must integrate with, existing databases and their quality, rest vs graphql comparison compliance requirements, offshore vs nearshore outsourcing expected load, target platforms and stacks you cannot change. Where a date is genuinely fixed, explain what drives it: a team is usually able to rearrange the plan to meet it, but not if the date is a secret.
Define what the word done means for each item. Testable acceptance criteria need not use formal language: a short paragraph setting out what must be true when the feature works will do. This one section compresses acceptance testing dramatically and eliminates the most common source of disputes.
To close, ask for a specific format. Ask for an itemised estimate, the assumptions behind each number, the main risks and a low number and a high number. Read a wide range as information, not evasion: it usually points to where your description is thin. Then tighten that section and ask again — the revised figure will be the one worth planning around.