An MVP feature list starts with one user job
An MVP is the smallest version of an app that lets a real person finish one useful job. MVP means minimum viable product. It is not a list of every feature you may want later.
For an AI-built app, start with one user, one problem and one finished result. Then keep only the screens and rules needed for that path. This gives a coding agent a job it can build and gives you a result you can check.
A running example: an appointment booking app
Imagine that a consultant needs clients to book an open time. The first user is a client. Their job is to choose an open time and receive a clear confirmation.
The first version does not need team accounts, recurring bookings, calendar sync, reminder emails or reports. Those can be useful later. They are not needed for one client to book one open time.
1. Write the user job before you list features
Write one sentence in this shape: a person can do one thing and get one result. For the booking app: a client can choose an open time and get a booking confirmation.
This sentence is the test for every feature idea. If the idea does not help the client finish that job now, save it for later. Do not make the agent decide whether it belongs.
- User: a client who needs to book a time.
- Problem: the client cannot see which times are open.
- Result: the client chooses one time and sees that it is booked.
2. Keep only the parts needed for the first path
Walk through the job from start to finish. Name each thing that must exist for the path to work. For the booking app, the client needs to see open times, select one, enter the needed details and see a saved confirmation.
Add the rules that protect the path. A time that is already booked must not appear as open. A second click must not create a second booking. A failed save must tell the client what happened instead of pretending the booking worked.
- Show only open times.
- Let the client select one time and enter the required details.
- Save one booking for that time.
- Show a confirmation after the save succeeds.
- Show a useful message when the save fails.
3. Put later ideas outside the first version
A later list protects a good idea without making the first build larger. Put ideas there when they do not help the current user finish the current job.
For this example, calendar sync, reminder emails and team roles are later ideas. Each one adds new people, data rules and failure cases. Build the booking path first, learn from it, then decide which later idea deserves its own feature brief.
4. Turn the feature list into checks before AI writes code
A feature list says what belongs in the app. Acceptance criteria say how you will know it works. Write the checks before the coding task starts so the agent has clear boundaries and you have a fair way to review the result.
For the booking app, automate rules that the app can reliably check. Then use the main flow yourself. Automated tests can catch a duplicate booking rule. A manual check can catch a confusing confirmation or a missing next step.
- An available time can be selected and saved.
- A booked time cannot be selected again.
- A double click does not make two bookings.
- A failed save keeps the entered details visible and explains what to do next.
Keep the MVP plan next to the build work
A small list is only useful if the next coding session can read it. Keep the user job, feature boundary and checks with the task they belong to. That stops the plan from becoming a forgotten note in an old chat.
CodeSpring keeps the app map, feature notes, PRDs and Kanban tasks together. You can use the map to keep the first version visible, make a PRD for one feature and hand the coding agent one task with checks instead of asking it to build the whole app.