Begin with the reason this software should exist, not a list of screens. Which people will use this, how many times a day, and how is the job done today? An estimator who grasps the purpose often proposes a cheaper route to it; a team that receives only a list of screens will price exactly what you asked for.
Define what is included as short scenarios: who does what, and what happens next. Equally important, list what you are not building. An explicit exclusion list saves more disagreement during acceptance than the rest vs graphql comparison of the brief combined. Indicate as well which items are decided and which may still change — estimators price uncertainty, and hiding it outsourcing company helps no one.
List the constraints. This means the platforms and kubernetes development services involved, the data you already hold and its condition, security and compliance rules, node js development outsourcing user volumes, which devices matter and stacks you cannot change. Where a date is genuinely fixed, say why: a good team is usually able to resequence the work to meet it, but not if the date is a secret.
Say what done means for each item. Acceptance criteria do not need any formal notation: a short list describing the expected behaviour will do. That one addition reduces the sign-off process dramatically and closes off the usual argument at handover.
Finally, say what you expect back. Request a breakdown by feature or module, the assumptions used, the main risks and a low number and a high number. Take a broad range as information, not evasion: it usually points to exactly which requirement is unclear. Then clarify that area and ask again — the next version will be the one worth planning around.