The finished company is not the first release. The first release completes one valuable path for one user, proves it with evidence, and leaves everything else in an honest backlog. This lesson plans that release — small enough to begin this week, serious enough to learn from.

The release vocabulary

• Prototype — a throwaway learning sketch. Proves a question, earns no users.
• Minimum useful version (MVU) — the smallest release one real user completes end to end and values. This lesson's target.
• Acceptance criteria — the testable conditions that mean "this path works."
• Release scope — the one flow included, stated as inputs, steps, and outputs.
• Dependency — what must exist first: a source, a key, a human reviewer, an approval.
• Milestone — a dated checkpoint with a decision attached.
• Backlog — everything deliberately deferred, ranked. A promise to decide later, not a graveyard.
• Test — the check proving the path works: manual script, automated check, or both.
• Preview — the private-but-real environment where the user tries it before production.
• Production — the live system real users touch, with logs, costs, and support.
• Rollback — the pre-planned return to the last good state when the release fails.

The release rule follows directly: one path, one user. Defer dashboards, broad integrations, complex roles, and automation that do not prove the job. Each deferred item names its trigger for return ("add team roles after three single-user pilots renew"). Deferral with a trigger is planning; deferral without one is wishing.

The sequence that earns production

AI-assisted coding rewards clean windows and branches — Part X's discipline applied to v1:

spec → small tasks → implementation branch
→ review + test → preview → user feedback
→ decision log → production when earned

Separate truly independent work into its own window and branch: frontend, backend, research fetch, fixes. Merge only after review. Keep TASKS.md current so any session can orient (Lesson 90.3) and pick up the next safe task without re-reading the whole history.

For the analyst brief, the sequence is concrete: SPEC the one-page brief → task the fetcher alone → review the fetcher on two real tickers → branch the draft step → human source-check on three briefs → preview with one pilot analyst → log the go/no-go → production as a manual-send pilot. The calendar launcher is identical in shape: form → database → calendar → notify → review queue, each reviewed before the next merges.

Preview deserves emphasis. It is not a demo on your laptop; it is the production-shaped environment with test data and one real user. The preview criterion is binary: can the user complete the path without your help while you watch silently? If you narrate, prompt, or hot-fix mid-session, preview failed — fix the path, not the demo.

Exercise: create FIRST-RELEASE.md

Create FINAL-PROJECT/FIRST-RELEASE.md:

# FIRST-RELEASE — [Project], [date]

## One user flow (numbered, 5–9 steps)
1. [user does …] 2. [system does …] … → [observable outcome]

## Acceptance criteria (testable, each with how-checked)
- [criterion — checked by: manual script / automated test / human review]

## Explicit non-goals
- [dashboard / integration / role / automation — deferred until (trigger)]

## Dependencies
- [source / key / reviewer / approval needed before build]

## Tasks + branches (small, each ≤ half a day)
- [task — branch name — reviewer]

## Test plan
- [unit/integration/manual checks; which must pass before preview]

## Preview criterion
- [the silent-watch test + who the preview user is + date]

## Rollback
- [last-good state; how to revert; who decides; how users are told]

## Milestones
- [date — checkpoint — go/no-go decision]

Finish line: a release plan you can begin this week — one flow, testable criteria, named non-goals, tasks with branches, a preview test, and a rollback you could execute tired at midnight.

Verify: read the flow to your preview user. Ask: "would you do these steps for this outcome?" Then pre-mortem the rollback: describe the revert commands, the decision-maker, and the user message. If any answer is "we will figure it out," the plan is incomplete.

Common failure mode: the悄悄 expanded scope — "just one more integration" added mid-build without updating SPEC or criteria. Freeze the flow at preview; new ideas go to the backlog with a trigger. Its mirror is skipping preview: shipping from a laptop demo straight to production. Preview is where embarrassment is cheap. Use it.

Freezing scope without freezing learning

Locking the flow does not lock your mind. Feedback during preview goes to two buckets: breakers that block the go decision (the user cannot complete step three) and learnings that enrich the backlog (users ask for exports). Breakers get branches and re-preview; learnings get triggers and dates. This separation keeps the release small while honoring what preview teaches. Log both in DECISIONS so the reviewer in Lesson 90.10 sees not just what shipped but what was heard and deliberately deferred — the mark of a team that listens without sprawling.

Branch hygiene deserves one concrete rule: a branch lives at most three days or one task, whichever ends first. Stale branches accumulate conflicting assumptions and rot the orient-first habit from Lesson 90.3. Merge or close on schedule, log the outcome in TASKS and DECISIONS, and cut the next branch from a fresh read of memory. Small branches merged after review beat heroic branches reconciled under pressure.

Check your understanding

1. How does an MVU differ from both a prototype and the finished company? 2. Why do clean windows and branches matter more, not less, when AI writes fast? 3. What makes a preview criterion pass/fail rather than a vibe?

Next

You can ship one path safely. Lesson 90.7 ensures the shipment teaches — an evidence loop that turns behavior, comments, cost, and retention into decisions.