Define an MVP before you build it
Start with one user, one useful workflow and a clear way to learn from the first release.
An MVP should let a specific group of people complete a useful task and give you evidence about what to build next. It is not the full product with unfinished screens. Before estimating development, decide what the first release needs to teach you.
This guide is a working brief for that conversation. Its examples are illustrative, not results from a CodeRoasters client engagement.
Choose one user and one problem
“Small businesses” is too broad to guide the first workflow. Name a person in a situation: an administrator who needs to approve visitor access, or a supervisor reviewing a field report. Describe what they do today and what prevents them from finishing the task well.
Do not assume the person buying the software is its only user. Record who enters information, who checks it and who acts on it. You can focus the first release without ignoring the people who make the workflow possible.
Identify the assumption you need to test
Ask what must be true for the idea to work. Will people use this workflow? Can you obtain the required information? Does the proposed process resolve the problem without creating another one?
A prototype may answer a usability question before production software is needed. The GOV.UK Service Manual describes using prototypes to test risky assumptions. That is a useful principle here, not a requirement to adopt the government’s delivery process.
Choose the smallest experiment that can answer your current question. A clickable prototype can explore navigation; it cannot establish whether a live integration will handle real data correctly.
Draw the complete core workflow
Illustrative example: a resident announces a visit, a guard checks the authorization, and the entry is recorded. The first version needs a clear beginning and a useful end. A report builder or a large settings area may be less important than handling an expired authorization clearly.
Write down the ordinary path and two or three likely exceptions. For each step, identify the user, the information required and the result. This often reveals missing work that a list of screens would overlook.
Make the boundary visible
| Include in the first release | Defer until there is a reason |
|---|---|
| One end-to-end task | Several loosely connected use cases |
| Necessary permissions and error states | Every possible role configuration |
| A way to inspect whether the task worked | A custom reporting suite |
| A clear support and correction path | Automation of every exception |
Deferring a feature is not the same as forgetting it. Keep a short list of what is outside the first scope and why. Revisit it after observing actual use rather than allowing it to enter development silently.
Define evidence before launch
Pick a small set of questions: can a user finish the task without assistance? Where do they stop? Which records need correction? Does the workflow fit the setting where it will be used?
Choose targets only after understanding the current process. Do not select impressive-looking numbers because a dashboard has space for them. Combine observation with feedback, and be explicit about what the first release cannot prove.
Bring this brief to a development conversation
- Who is the first user?
- What job are they trying to finish?
- What do they use today?
- Which assumption needs testing first?
- What is the smallest complete workflow?
- What is outside the initial scope?
- What evidence will guide the next decision?
This brief creates a better starting point for product design and development. If an existing tool may already solve the problem, first read our guide to SaaS versus custom software.