Start with the work, not the feature list
Describe what happens today. Who performs the task? What information do they need? Where does work stop or get repeated? A short example of a real process is often more useful than a long list of screens. Remove personal or confidential data from any samples you share.
Name the first user and the first outcome
A customer portal and a staff dashboard can share a backend, but they solve different problems. Pick the first audience and the task the first release must complete. Write down what you are deliberately leaving out.
List the systems that must remain
Include the tools, APIs, payment providers and databases the project must work with. Note who controls access and whether there is a test environment. An integration without documentation or a sandbox can materially affect the estimate.
Make constraints explicit
Share the budget range, target date, approval process, content responsibilities and required devices. Distinguish a fixed external deadline from a preferred launch date. This gives your development partner room to propose a realistic first release.
Define acceptance in observable terms
“Easy to use” is a goal, not a release criterion. A more useful example is: an authorized operator can create a request, assign it to a colleague and see its latest status without editing a spreadsheet. Include the failure and recovery paths too.
Ask for assumptions alongside the estimate
A useful proposal states inclusions, exclusions, dependencies and support arrangements. Changes are normal; an explicit baseline makes their effect on cost and timing easier to discuss.