Describe the app and intended audience.
Provide the store links, supported platforms and priority market. Explain the main user task in plain language. A consultant should not have to infer the product promise from a category label alone.
If the app serves several audiences, state which one matters for this project. Keep the current product distinct from planned features so recommendations do not depend on something unavailable.
Name the problem and the decision.
Explain what prompted the request: a decline, a launch, unclear positioning or an internal capability gap. Describe the decision you need help making rather than preselecting every deliverable.
A request for new screenshots may hide a broader audience issue. Link relevant observations and say which explanation is still uncertain. Use diagnostic guidance to frame the question.
Summarise the evidence and changes.
List available reports, known releases and acquisition changes. State the date range and important limitations. You can describe available data without uploading private account material in the initial enquiry.
Use a change log to identify the timeline. Do not include passwords, credentials or individual user data in the brief builder.
Explain implementation and constraints.
Name who can provide product answers, approve copy, design assets and publish updates. Include real deadlines and why they matter. State any budget boundary you want the provider to consider, without treating it as a quoted fee.
These details help distinguish recommendations from production needs. Compare ownership models if the internal responsibility is still unclear.
Use the brief to review the proposal.
Ask the provider to explain scope, exclusions, delivery roles and evaluation against your stated problem. Preserve the brief and any agreed changes so the engagement has a common starting point.
The builder creates a local draft that you can download and edit. It does not submit an enquiry. Use the contact form when ready, and proposal guidance to assess the response.
