Reading: Part 12. MVP

Lesson 1 of 5 in module «Part 12. MVP»

You are viewing the lesson without signing in. Sign in to save progress and take tests.

Source

Part 12. MVP

The MVP phase differs from a regular feature phase. Here you ask the agent to implement not one small piece, but the remaining part of the minimum viable product. This is risky. You should only do this if the project rules, specifications, tests, and verification are already mature enough.

MVP is useful as a stress-test of your own specifications: if the agent, having read the constitution and feature specs, builds something other than what you expect, the problem is not just the agent. Most likely, the specifications gave too much freedom or the roadmap was unclear.

When to try MVP

A suitable moment:

at least two features have already gone through the full cycle;
mission.md, tech-stack.md, roadmap.md are up to date;
there is a testing policy;
there is a changelog;
you are ready to review a large volume of changes;
the roadmap contains clear MVP boundaries.

An unsuitable moment:

the very first phase of the project;
no tests;
the roadmap is vague;
the agent already frequently oversteps boundaries;
you cannot allocate time for review.

MVP request for Qwen Code

/clear
Read @QWEN.md, @specs/mission.md, @specs/tech-stack.md, @specs/roadmap.md
and all existing feature specs in @specs/.

We are considering the MVP branch.
Do not implement anything yet.

First:
1. find the minimal set of remaining roadmap items needed for MVP;
2. list the risks of implementing them together;
3. ask me three groups of questions about MVP boundaries, decisions, and verification.

After answers:

Create specs/YYYY-MM-DD-mvp/requirements.md, plan.md and validation.md.
The plan should be split into groups so I can ask to implement it in parts.
Do not write implementation code yet.

Example of MVP boundaries

# Requirements — MVP

## Boundaries

MVP must make AgentClinic a coherent small demonstration:
- home page;
- agents and ailments;
- therapies;
- appointment request form;
- dashboard summary;
- responsive styles;
- tests for critical routes.

## Out of scope

- Authentication.
- Payment.
- Email sending.
- Administration interface for editing.
- External deployment.

## Decisions

- Use SQLite tables and seed data.
- Store submitted forms locally.
- Render everything on the server.
- Use existing layout and CSS conventions.

MVP verification

For MVP, verification must be stricter than for a small feature:

## Automated checks

- npm run typecheck passes.
- npm test passes.
- Route tests cover /, /agents, /ailments, /therapies and /appointments.
- Database tests cover migrations and seed data.

## Manual checks

- In a fresh clone, npm install, npm run seed and npm run dev work.
- Main navigation leads to all MVP pages.
- Appointment form handles valid and invalid input.
- At 375px mobile width, layout does not break.
- Changelog describes the MVP branch.

## Out-of-scope verification

- Authentication is not added.
- Client framework is not added.
- External services are not required.

Implementing MVP in groups

Even if the MVP specification is a single one, the implementation does not have to be done in a single command.

Implement only group 1 from @specs/2026-05-05-mvp/plan.md.
Run the necessary checks.
Stop and list the changed files.

Then:

Implement group 2.
Do not edit files from group 1 unless verification requires it.

This way you preserve checkpoints that are convenient to verify.

When to stop: timeboxing and rolling back to the last green point

The MVP branch tends to grow. The agent implements group 1, then group 2, then starts "along the way" fixing group 1 for group 3 — and after an hour it is unclear what state the repository is in.

Fix two things in advance: time budget and rollback point.

Time budget. Agree with yourself (or with the team) on a timebox for the session. For a learning MVP, this is 2–4 hours. When the timebox expires, not "just one more group" — stop, assess, decide.

Rollback point. Before each group of tasks, make a commit, even if it is intermediate. After the commit, run npm run typecheck and record that this point is green:

git commit -m "MVP group 1: agents page"
npm run typecheck
git tag mvp-green-1

If the next group breaks everything and within a reasonable time you do not understand how to fix it — roll back to the last green state:

git reset --hard mvp-green-1

This is not a defeat. This is a signal that the MVP specification was not detailed enough for a specific group — it needs to be refined with a separate small feature instead of forcing it in the MVP branch.

Signs that it is time to stop before the timebox expires:

the agent returns to the same group twice in a row and does not close it;
git diff --stat shows changes in files that are not in any group of the plan;
after the next implementation, tests that passed before stop passing;
the agent starts asking "can I also…" — this means the MVP boundary is getting in the way, and the specifications need to be fixed, not the boundary moved.

After MVP, ask about gaps in specifications

One of the best questions:

Based on the MVP implementation, tell me what you had to infer yourself because it was not explicitly specified.
List the gaps in the specifications and suggest updates for mission, tech-stack, roadmap or the MVP specification.
Do not modify files.

If the agent honestly answers "I decided X myself", this is a gift. Record X in the specifications if the decision is important.