You do not need a complete specification to start a project conversation. A little shared context can still make an estimate more useful. The goal is to explain the work well enough to identify assumptions, discuss trade-offs, and choose the next step.
Explain what needs to change
Start with the problem and the people affected by it. Describe the current process, the friction it creates, and what a better outcome would look like. A request to build a dashboard is less informative than an explanation of the decisions that dashboard should help someone make.
Separate the first release from later ideas
Make two short lists: what the first version must do and what could come afterwards. The lists can change during discovery. Their value is in making priorities visible. If everything is essential, explain which outcome you would protect if the available time or budget became smaller.
Name the systems and responsibilities
Mention existing software, payment providers, data sources, or accounts the product may need to connect to. Explain who will supply content, review designs, and make decisions. You do not need to solve every technical detail yourself. Naming these dependencies gives the studio somewhere sensible to start its questions.
Share constraints without disguising them
If there is a fixed event, launch window, or budget range, say so early. Explain which constraints are firm and which are flexible. A useful proposal should connect the scope to those realities rather than relying on assumptions that only become visible after work has begun.
Ask what the estimate assumes
An early estimate may depend on unresolved decisions. Ask which parts are included, which are excluded, and what information would change the proposal. Agree how changes will be discussed. A clear estimate is a basis for a working conversation, with enough detail to understand the commitments on both sides.
