An MVP is a question, not a small product
The purpose of a first version is to find out whether something is true: will people use this? will they pay? does it solve the problem? Everything in scope should help answer that. Everything else is delay.
The hard part is not deciding what to build. It is deciding what to leave out, and living with it.
1. Pick one user and one job
Not "small businesses". One specific person, and the one thing they need to get done. A clinic receptionist needs to rebook a cancelled appointment in under a minute.
If the description contains the word "and", you have two products.
2. Walk the path end to end
Write down every step that user takes, from arriving to finishing the job. Then build the whole path, thinly, rather than part of it thoroughly.
A booking flow with plain screens that works from start to finish can be tested with a real user. A beautiful calendar with no way to confirm a booking cannot.
3. Write the "not in version one" list
This is the most useful document in the project. Put on it everything that came up and was cut:
- Team accounts and permissions
- A mobile app
- Integrations
- Reports and exports
- Settings for anything that could simply have a sensible default
Write it down so that nothing is forgotten, and so that "not now" does not have to be argued again every week.
4. Fake what you can
Some things can be done by hand until the idea is proven:
- Onboarding by a person instead of a wizard
- An invoice sent manually instead of a billing system
- A weekly email written by you instead of a notification engine
If doing it manually becomes painful, that is good news. It means people are using the product.
5. Budget for the plumbing
The features nobody lists are the ones that eat the schedule. Every real product needs:
- Sign-up, sign-in and password reset
- Transactional email
- Payments, if you are charging
- Error tracking and basic analytics
- A privacy policy and terms
- Somewhere to deploy it, and a way to deploy again tomorrow
None of this is the idea. All of it has to exist before a stranger can use it.
6. Decide what "done" means before you start
Agree, in one sentence, what would make version one a success. Ten clinics use it for a month and at least half keep using it. Without that sentence, every new idea looks essential, because there is nothing to measure it against.
What a good scope looks like
At the end you should have four things on one or two pages: the user and their job, the path from start to finish, the cut list, and the definition of success. If the path cannot be built in around three months, cut again — not because three months is magic, but because past that point you are no longer testing an idea, you are building a product on a guess.
This is how we approach the first weeks of any custom software project. It is also worth checking, before any of it, whether you should be building at all.
Working on something like this? See how we approach custom software development.