Start with the business problem, not your preferred technology. Which people will use this, with what frequency, and how is the job done today? An experienced team who grasps the purpose often proposes a simpler way to reach it; one who only sees a list of screens can only price exactly what you asked for.
Describe the scope as user stories or scenarios: what the user does and laravel vs django performance what the system does in response. Every bit as useful, list what you are not building. A written out-of-scope list prevents more disagreement later than the rest of the brief combined. Mark too which parts are firm and custom web application development pricing which are still under discussion — the difference changes the price, and pretending everything is fixed only hurts you.
Set out your constraints. The list covers the platforms and services involved, the data you already hold and its condition, security and compliance rules, traffic expectations, supported browsers or devices and any technology you are committed to. Where a date is genuinely fixed, say what depends on it: a good team can often rearrange the plan to hit it, but not if the date is a secret.
Write down what done means feature by feature. Clear acceptance criteria do not require formal language: a short paragraph describing what must be true when the feature works is sufficient. This single habit reduces acceptance testing dramatically and eliminates most late-stage disagreement.
One last thing, state what you want in the response. Ask for a task-level breakdown, a written list of assumptions, the main risks and a low number and a high number. Treat a wide range as useful information rather than evasion: it tells you where your description is thin. At that point rewrite that part and ask again — the second estimate is far closer to reality.