[ Guide ]
How to scope an MVP without building too much
Most MVPs run long for one reason: they try to answer every question at once. A good scope answers one question well. Here is how to get there before anyone writes code.
Start with the one thing you need to learn
An MVP is a test, not a smaller version of the finished product. Write down the single most important assumption behind your idea, such as "busy clinic managers will book staff through an app instead of a group chat".
Everything in the first version should help you prove or disprove that. Anything that doesn’t can wait.
Map the shortest path to value
Sketch the journey a first user takes from landing on the product to getting the result they came for. Then cut it down.
- One type of user, not every role you will eventually have.
- One core flow, done properly, rather than five done halfway.
- Manual work behind the scenes where it saves building (you can approve sign-ups by hand at first).
- Off-the-shelf pieces for login, payments and email instead of custom ones.
Sort features into must, later and never
List every feature anyone has mentioned. Mark each one "must" only if the core flow breaks without it. Most lists end up with far fewer musts than expected, and that is the point.
Keep the "later" list. It becomes your roadmap once real users tell you which items matter.
Decide how you will measure it
Before launch, agree what success looks like: a number of active users, a conversion step, repeat use within a week. Add the analytics to track it as part of the build, not after.
Build it so version two isn’t a rewrite
Small scope doesn’t mean throwaway code. Use a mainstream stack, keep the code in your own repository and ask for documentation at handover, so the next team (or the same one) can keep building on it.
What to bring to a first call
You don’t need a full specification. These are enough to start a useful scoping conversation:
- The problem and who has it
- The assumption you want to test
- Any deadline that matters (a launch, a pitch, a season)
- Examples of products you like and why
Common questions
- How small should an MVP be?
- Small enough to test your main assumption with real users, and no smaller. If a feature doesn’t help answer that question, it belongs in a later version.
- Should an MVP be web or mobile?
- Usually web first, because it is faster to change and works on every device. Go native when the idea depends on things like the camera, location or push notifications.
- Who owns the code of my MVP?
- You should. With Zecro, you own the code, designs and accounts from day one, with documentation at handover.
Get a plan for your project, free.
See what you'd get, the typical stack and your first two weeks, then we'll write it up for your business.