How to plan and ship a SaaS MVP with Claude Code

Start with a user and a problem, not a list of screens. For a hypothetical appointment product, the first outcome might be: a customer chooses an available time and receives confirmation. Write down what counts as success, what can be manual, and what is outside the release. Payment plans, advanced analytics, and calendar synchronization may be useful later; do not add them simply because the coding agent can generate a starting implementation quickly.

Create a short Markdown brief containing the target user, the outcome, acceptance checks, technical constraints, and open questions. Keep stable test commands in repository instructions. Give Claude Code one task from that brief and ask it to explain the intended behavior before editing. At the end, record the files changed, checks performed, unresolved issues, and the next action. A transcript can explain how the session unfolded, but the brief should identify what still applies. If the next session begins with a different scope, pause and reconcile the difference instead of letting implementation speed choose the product.

Create a project inside your workshop rather than opening a separate workshop for every feature. Put repository and environment links in Inventory. Use Health for evidence of working behavior and missing checks. Place bounded implementation tasks in Work, lasting scope limits in Authority, and accepted trade-offs with reasons in Decisions. These blocks orient the agent without asking it to read every exploratory conversation.

Choose one first task, such as validating the appointment confirmation path. Connect Claude Code, select the correct project, and have it read the current brief before work. Ask it to flag conflicts between the repository and the record. Keep a proposed architectural change separate from an accepted decision. When the task ends, review the handoff against the actual code and test output. A proposed fix should not become a claim that the release is ready merely because the agent wrote a confident summary. Update the current next action rather than leaving completed work on the list. Preserve evidence links so a later session can investigate without repeating the whole analysis.

Before launching, walk the core path with realistic input. Check failure states, access, and recovery, not only the happy path. Write down which environment was tested and which checks remain undone. A merged branch does not establish that production serves the change. A working demo does not prove customer demand. Record those boundaries explicitly so the next agent does not continue from an exaggerated completion claim.

Keep the release task small enough to verify. If an agent proposes a larger redesign during final checks, ask whether it blocks the user outcome or can wait. Record the human answer and rationale. After release, choose the next task from observed problems rather than resurrecting every deferred idea. For a later tool change, use the shared-context workflow. The aim is a resumable SaaS MVP, not a permanent planning exercise that grows faster than the product.