Topic: Part 12. MVP
Difficulty level: Medium
Estimated study time: 4-6 hours (theory: 1.5 hours, practice: 2.5-4.5 hours)
Prerequisites: Completion of at least two small feature phases (from previous course parts)
Understanding of project document structure: mission.md, tech-stack.md, roadmap.md
Experience with Git version control system
Basic knowledge of testing and CI checks
Familiarity with code agent operation (Qwen Code or similar)
Learning objectives: Determine project readiness for MVP phase using a checklist of 6 criteria
Formulate clear MVP boundaries, separating 'inside' from 'outside', with at least 5 items in each category
Apply grouped MVP implementation technique with creating 'green points' rollback via git tags
Conduct MVP deviation checks with automatic and manual verification
Use post-MVP analysis to identify gaps in specifications and update project rules
Overview: The MVP phase is a critical development stage involving a code agent, where instead of step-by-step implementation of individual features, the remaining part of the minimum viable product is assembled as a whole. Unlike regular feature phases, MVP carries elevated risk: the agent processes a large volume of specifications simultaneously, making this phase a powerful stress test of project documentation maturity. The study material covers readiness criteria for MVP, risk management techniques, structuring MVP specifications, grouped implementation with checkpoints, timeboxing, and post-analysis for improving project rules.
Key concepts: MVP as a stress test of specifications: If the agent, having read all project documents, builds something other than expected — the problem is not the agent, but insufficient specification detail, excessive freedom, or an unclear roadmap. MVP reveals these problems before they become critical in production.
Readiness criteria for MVP: At least two features have completed full cycle; mission.md, tech-stack.md, roadmap.md are up to date; testing policy exists; change log is maintained; team is ready to review large volume of changes; roadmap contains clear MVP boundaries.
MVP boundaries: Clear separation of what goes into MVP (main page, key features, tests for critical routes) and what stays outside (authentication, payment, external services, admin interface). Boundaries prevent scope creep.
Grouped implementation: Even a single MVP specification is implemented in parts — task groups. After each group: stop, verify, commit, 'green point' tag. Next group should not edit previous group's files unless necessary.
Green points of rollback: Git tags (e.g., mvp-green-1) set after successful typecheck and tests. If next group breaks — hard rollback to last green point, not debugging in 'dirty' state.
MVP session timeboxing: Fixed time budget (2–4 hours for educational MVP). Upon expiration — stop, assess, conscious decision, not 'just one more group'.
Deviation check: Strict verification that boundaries were not crossed: authentication not added, client framework not introduced, external services not required. Prevents 'creeping' functionality expansion.
Post-MVP gap analysis: Question to agent: 'What did you have to figure out on your own because it wasn't explicitly given?' Honest answer — a gift for improving specifications, not a reason for punishment.
Practice exercises: Name: MVP Readiness Audit
Problem: You are provided with a project description for 'EcoTracker' — an app for tracking ecological habits. The project has: roadmap.md (last updated 3 months ago), one implemented feature (user registration), tests only for this feature, missing journal.md. Evaluate using the checklist from the material whether the project is ready for MVP phase. If not ready — create an action plan to achieve readiness with priorities and timelines.
Solution: 1. Check criterion 'at least two features completed full cycle' — NO, only one feature. 2. Check roadmap.md freshness — NO, updated 3 months ago. 3. Check testing policy — PARTIAL, tests only for one feature. 4. Check change log — NO, journal.md missing. 5. Check readiness for large volume review — UNDETERMINED. 6. Check clear MVP boundaries in roadmap — IMPOSSIBLE TO VERIFY due to staleness. VERDICT: not ready. PLAN: (1) Implement second feature through full cycle (1-2 weeks); (2) Update roadmap.md with clear MVP boundaries (2-3 days); (3) Expand tests to policy covering all critical paths (1 week); (4) Create and populate journal.md (1 day); (5) Repeat readiness audit.
Complexity: intermediate
Name: Formulating MVP Boundaries
Problem: Develop a 'Requirements — MVP' document for the online coworking booking service 'DeskShare'. The service must demonstrate: browsing available spaces, filtering by locations, space card with photos and amenities, booking form with date/time selection, booking confirmation. Outside boundaries remain: payment, calendar integration, user personal account, ratings and reviews, mobile application. Also formulate 3 technical decisions and 5 deviation check items.
Solution: BOUNDARIES INSIDE: space catalog with search; filters by cities and amenities; space card with gallery; booking form (date, time, contacts); confirmation page; responsive layout; tests for catalog and booking routes. OUTSIDE BOUNDARIES: payment (booking without payment); integrations with Google/Apple Calendar; personal account (booking by email); ratings and reviews; native mobile application; SMS notifications. DECISIONS: (1) Store bookings in SQLite with email as identifier; (2) Server-side rendering for all pages, no React/Vue; (3) Photo upload via static files, no CDN. DEVIATION CHECKS: Stripe/PayPal not connected; OAuth authorization not added; React/Vue/Angular not introduced; Firebase/AWS Lambda not used; SMS gateway not integrated; client-side routing not applied.
Complexity: intermediate
Name: Green Point Rollback Scenario
Problem: You are implementing MVP in 3 groups. After group 1 (agents and ailments) you created a commit and tag mvp-green-1, typecheck passes. During implementation of group 2 (therapies and booking form) the agent 'along the way' changed group 1 files, and now: (a) group 1 tests fail; (b) git diff --stat shows changes in 12 files, of which 4 are not in any group of the plan; (c) the agent suggests 'while we're at it' adding caching. Describe your step-by-step actions, including git commands and the decision to continue/rollback.
Solution: 1. IMMEDIATE STOP: do not agree to 'while we're at it' caching — this is a sign of boundary blurring. 2. ASSESSMENT: signs are critical — group 1 tests fail, files outside plan are changed, agent proposes going beyond boundaries. 3. TIME CHECK: if <50% of timebox spent and problem is localizable — can try to rollback only group 1 changes; otherwise — full rollback. 4. FULL ROLLBACK: git log --oneline to check commits; git reset --hard mvp-green-1; git clean -fd if agent created new files; verification: npm run typecheck must pass. 5. ROOT CAUSE ANALYSIS: group 2 specification was insufficiently detailed and did not prohibit changing group 1. 6. ACTION: create separate feature 'Clarify MVP group isolation', refine plan.md with explicit prohibition on editing previous groups' files. 7. RETRY: start group 2 with updated specification.
Complexity: advanced
Name: Post-MVP Agent Interview
Problem: Compose a prompt for Qwen Code in Russian that, after MVP completion, reveals the agent's implicit inferences. Then analyze a hypothetical agent response: 'I decided on my own to use localStorage for saving form drafts because the specification didn't indicate how to handle interrupted filling. I also added debounce to search — it seemed obvious for UX, though not mentioned in requirements.' Formulate what updates to make in which documents.
Solution: PROMPT: 'Regarding the MVP implementation, tell me what you had to figure out on your own because it wasn't explicitly given. List specification gaps and suggest updates for mission.md, tech-stack.md, roadmap.md, or MVP specification. Do not modify files.' RESPONSE ANALYSIS: (1) localStorage for drafts — architectural decision without approval; affects data privacy, private browsing mode, cross-device synchronization. (2) debounce on search — UX decision with technical consequences (delay, query frequency). UPDATES: In specs/mission.md — add principle 'All decisions on user state persistence are explicitly agreed upon'; in specs/tech-stack.md — specify allowed client-side storage mechanisms (or their absence); in specs/YYYY-MM-DD-mvp/requirements.md — explicitly describe behavior for interrupted filling ('drafts are not saved, form resets'); in validation.md — add deviation check 'localStorage is not used'; in tech-stack.md or roadmap.md — extract debounce into separate UX feature with measurable parameters (delay in ms).
Complexity: intermediate
Case studies: Name: AgentClinic: From First MVP Failure to Controlled Implementation
Scenario: A startup develops a demo application AgentClinic — a medical clinic simulator with AI agents. After two successful small phases (agent page, ailment page) the team decides to accelerate and implement remaining functionality in a single request to Qwen Code.
Challenge: The first unprepared MVP request led to: (1) authentication added 'while we're at it', though it was outside boundaries; (2) React introduced on client, despite server-side rendering in tech-stack; (3) 47 changed files without understanding what belongs to which feature; (4) tests failing that passed before MVP; (5) 6 hours of debugging without result — team lost orientation.
Solution: The team applied methodology from Part 12: (1) rollback to last stable commit before MVP; (2) creating complete MVP specification with explicit boundaries; (3) splitting into 4 groups: main+navigation, therapies, booking form, admin panel; (4) 3-hour timebox per group; (5) git tags mvp-green-1, mvp-green-2, etc. after each group; (6) strict deviation check after each group.
Result: Second MVP completed in 10 hours (4 groups × 2.5 hours average). All tests passed. Authentication and client frameworks did not penetrate code. Change log contained clear history. Post-analysis revealed 7 implicit agent decisions that were formalized in updated specifications.
Lessons learned: First 'quick' MVP without specification took 6 hours and led to rollback; second, methodical one — 10 hours with working result. Time savings on preparation is an illusion.
Git 'green point' tags saved the day twice: when group 3 broke, rollback to mvp-green-2 took 30 seconds instead of hours of debugging.
Deviation check after group 2 caught agent's attempt to add caching — early detection prevented technical debt accumulation.
Post-MVP interview revealed that the agent 'decided on its own' to use a certain templating engine — this led to tech-stack.md clarification that prevented similar problems in subsequent projects.
Related concepts: MVP as stress test of specifications
Grouped implementation
Green points of rollback
MVP session timeboxing
Deviation check
Post-MVP gap analysis
Name: EduPlatform: When Declining MVP Was the Right Decision
Scenario: An educational project develops a platform for online courses. After one implemented feature (course catalog browsing) the product owner insists on 'acceleration through MVP' for investor demonstration in one week.
Challenge: Readiness analysis showed: roadmap.md missing (only 'vision' in founder's head); tests written only for catalog; no change log; agent in previous feature twice 'added useful things' outside specification. Classic signs of MVP unreadiness.
Solution: The team declined MVP in favor of two additional small phases: (1) user registration system with full testing cycle; (2) video player with learning progress. In parallel: formalizing roadmap.md with clear boundaries for future MVP, creating journal.md, implementing testing policy (coverage >80% of critical paths).
Result: Investor demonstration took place in 3 weeks instead of 1, but showed a stable, predictable product. MVP phase, when finally launched, completed without rollbacks and 2 hours under planned timebox. Investors noted 'professional development approach' as a trust factor.
Lessons learned: Deadline pressure is the worst reason for premature MVP; an unprepared MVP risks showing chaos instead of product.
Two additional small phases (2 weeks) saved potential 1-2 weeks of debugging after a failed MVP.
Document formalization during small phases proved more effective than trying to write everything 'for MVP' — documents were validated in practice.
An agent prone to 'useful additions' requires especially strict MVP boundaries; early fixation of this behavior in project rules prevented problems going forward.
Related concepts: Readiness criteria for MVP
MVP session timeboxing
MVP as stress test of specifications
Study tips: Go through the MVP readiness checklist on paper or in a table — not from memory. Physically checking each item reduces the temptation of 'well, almost ready'.
Practice writing the Qwen Code prompt exactly according to the template from the material, including /clear and structure 'first analysis, then plan, then code'. Deviations from template are a frequent cause of unpredictable agent behavior.
Create your personal 'rollback map' — cheat sheet with git commands: git commit -m '...', npm run typecheck, git tag mvp-green-N, git reset --hard mvp-green-N. In a stressful situation, a ready cheat sheet is more valuable than memory.
For visual perception: draw an MVP groups diagram with 'green points' as a traffic light. Red — current work, yellow — under review, green — tagged. Update status in real time.
Role practice: ask a colleague or use 'double control' — one plays the role of agent proposing 'while we're at it improvements', the other must resist and apply deviation check.
Keep an 'MVP journal' parallel to official one: record emotional state, moments of temptation for 'just one more group', actual time vs timebox. This is data for improving your assessment of own readiness.
After each exercise conduct '5 whys' analysis: why did agent do X? Why didn't specification prevent this? Why didn't check catch it? And so on to root cause.
Additional resources: Original course material — part 12: Full text with prompt examples and MVP document templates
Git documentation on tagging: https://git-scm.com/book/en/v2/Git-Basics-Tagging — for deeper understanding of annotated and lightweight tags
Article 'The Lean Startup' by Eric Ries (chapter on MVP): Classic foundation of minimum viable product concept, adapted for agent development context
Qwen Code documentation: Official recommendations on working with context and file references (@file)
Project document templates (mission, tech-stack, roadmap): Examples from previous course parts for documentation maturity comparison
Interactive Git trainer: https://learngitbranching.js.org/?locale=ru_RU — for practicing rollback and tagging scenarios
Summary: MVP phase with a code agent is not acceleration through scale, but managed risk requiring mature project documentation. Key principles: (1) do not start without two completed small phases and up-to-date documents; (2) formalize MVP boundaries as explicit inclusion and explicit exclusion; (3) implement in groups with 'green point' rollbacks; (4) apply timebox and hard rollback on violations; (5) check deviations — what was NOT added; (6) after MVP, extract implicit agent decisions for specification improvement. MVP is a stress test of your design discipline, not just agent code.