A better brief for your first build

Tell the team who will use the product, what those people do today, and what is difficult about it. Include what you have learned from potential users, if you have it.

Separate evidence from assumptions. “Three customers asked us for this” and “we think customers might want this” lead to different discussions. Both are useful when labelled honestly.

Write the main journey in plain language: where the user starts, what they do, and what success looks like. Add the staff or admin tasks needed to make the service work.

Separate must-have features from ideas for later. If you cannot decide what belongs in the first release, make that part of the discussion rather than turning every idea into a requirement.

Gather designs, sketches, brand assets, product links, API documentation, and notes about any existing code. Say which materials are ready and which still need work.

Do not put passwords or production secrets in an enquiry form. Describe the systems first; access can be arranged through the appropriate channel when the work requires it.

Include your budget range, any meaningful deadline, and why that date matters. An investor conversation, a customer pilot, and a public release may each require a different level of readiness.

Identify who can make product decisions and review the work. A clear decision-maker and regular feedback help avoid delays caused by unanswered questions.

These prompts are enough to start a useful conversation:

Aim to leave with a clearer scope, the important unknowns, and a list of what the team needs to estimate the work. It is reasonable for a developer to ask questions before promising a price or date.

You can send Hanxio a rough version of this brief. We will review the idea and discuss the next steps with you.