How to write a startup MVP brief
A clear one or two page brief makes scoping conversations more useful. This guide gives a structure founders can fill in before talking to any developer, including us.
Discuss your projectStart with the problem and the user
Write in plain sentences. Who has the problem, how do they handle it today, and what is painful about that? If you cannot describe the user in a few lines, the product is probably too broad.
- Who is the first user, specifically?
- What do they do today instead?
- What is the single most painful step?
- Why would they switch to your product?
Describe the core flow
List the steps from a user's first visit to the moment they get value. Keep it to the shortest path. Everything on that path is in the MVP, and everything else is a candidate to leave out.
- Entry: how do users arrive and sign up?
- Core action: what do they do that matters?
- Outcome: what do they get?
- Return: what makes them come back?
Prioritise features honestly
Sort every idea into three groups: must have for the core flow, nice to have later, and not now. Be strict. A good MVP often has fewer features than founders expect.
- Must have: needed for the core flow to work
- Later: useful but does not test the main assumption
- Not now: interesting ideas to revisit with evidence
Constraints, risks and success measures
Write down what limits the project, and how you will know it worked.
Success should be observable: a number of people completing the core action, a set of pilot users, or feedback from a defined group. Avoid targets you cannot measure.
- Budget range and timeline you are working with
- Technical or regulatory constraints, such as handling health or payment data
- Languages needed, such as Hindi and English
- Existing assets: brand, content, data, accounts
- Integrations required, such as payments or messaging
- Who decides, and how quickly can they respond?
- How you will measure success in the first few weeks
What to send us
Send the brief as a message or short document through the contact form. Rough is fine. We reply with questions, point out scope risks and suggest a first phase. We do not promise outcomes, but we will be direct about what is realistic.
Frequently asked questions
What if I only have an idea?
Write the problem and user sections first. We can build the rest together in a scoping call.
How long should the brief be?
One to two pages is enough. Clarity matters more than length.
Should I include designs?
Sketches, screenshots of similar products and rough notes all help. Polished designs are not required.
Is my idea kept confidential?
We treat enquiry details as private. If you need a formal agreement, ask before sharing sensitive detail.