You chose the wedge: one person, one job, one finish line. Now resist the urge to build a tiny copy of the final company — logo, pricing page, five tabs, and a quarter of each feature. Version one is smaller and smarter than that: the smallest thing that creates a real outcome and teaches you what to build next.

V1 creates an outcome and a lesson

A v1 has two jobs. First, deliver the wedge outcome for a real person this week — the house-price brief that informs a real offer, the support queue that gets Monday routed. Second, teach you what actually happened: where users hesitated, what data was missing, which output they trusted enough to act on.

That is why v1 needs five things, no more and no less:

1. One primary user flow. The wedge journey, end to end. Search → brief → save. Upload → triage → approve. Nothing parallel. 2. Honest states. Loading, empty, error, and denied — designed, not discovered. "No comps found in this radius" beats a spinner that never ends. "Data unavailable — try again shortly" beats a half-rendered brief. 3. Enough trust and safety for the data involved. Whatever the risk demands: source links on every claim, owner-only edits, no leaking one user's watchlist to another. 4. A way to observe usage. Logs of what happened, not vibes about what might have. Which searches ran, which briefs were saved, where errors clustered. 5. An easy way to speak to early users. A reply-to address, a feedback button, office hours with Dana the paralegal. V1 without contact is a message in a bottle.

Miss the flow and nothing works. Miss the states and the first error ends the relationship. Miss trust and you ship harm. Miss observation and contact and you learn nothing — which means v2 is a guess.

Prototype, alpha, beta, production — pick your promise

These words describe how much promise you are making, not how much code you wrote:

• Prototype: disposable, for learning. Shown to one or two people. "Does this brief format even help?" Throw it away freely.
• Private alpha: usable by named invitees only. The filing brief Dana uses on real Friday dockets. Support burden is a conversation. Breakage is forgiven if you fix it fast.
• Public beta: anyone can try, with visible limits. "Public launch, watchlists are private, refresh is daily, support is email-only." Policies exist because strangers arrived.
• Production: the full promise — onboarding, support, security review, rollback plan, status expectations. Part XI machinery running at full weight.

Most wedges should live as prototypes for days and private alphas for weeks before any public beta. A private preview can be genuinely useful — Dana's deadlines met every Friday — long before public onboarding, pricing, and policies are ready. Do not let launch theater rush you past the learning.

Research Desk v1: what ships and what waits

Concrete beats abstract. Research Desk v1 is:

Ships: search a company → receive a brief with visible source links → save or remove one private watchlist item. Empty state when no brief exists. Error state when the provider times out. Owner-only watchlist writes. Usage logs. A feedback link.

Deliberately deferred: no portfolio tracking, no social feed, no analyst marketplace, no autonomous trading, no team workspaces, no alerts engine. Each deferred item goes on the roadmap with the evidence that would justify it — "add alerts after 20 users save the same ticker twice."

The same discipline applies anywhere:

• Used-car shortlist v1: paste links → ranked five with reject reasons → save. No dealer portal, no financing, no messaging.
• Trip filter v1: constraints in → three options out → save. No booking, no reviews, no group planning.
• Support triage v1: upload queue → routed drafts → approve/reassign. No auto-send, no customer-facing bot, no analytics suite.
• Salary bands v1: role + city → sourced band table → save. No offer-letter generator, no HRIS sync.
• Filing brief v1: docket in → deadlines + owners → export. No client portal, no e-filing.

Every "no" is a gift to the "yes." Each deferred feature is a question v1 data will answer.

MVP does not mean leaky

"It is only an MVP" is not permission to leak private data, skip authorization, or ignore validation. Everything from Part XI still applies, scaled to the risk:

• Auth: watchlists, shortlists, and matter lists are owner-only from day one. Test the denial, not just the save.
• Validation: tickers normalized, addresses bounded, uploads size-limited, inputs rejected loudly.
• Tests: at least the Given/When/Then checks for the one flow, including unauthorized and error cases.
• Logs: request IDs, failure reasons, save/remove events — enough to reconstruct Friday's incident on Monday.
• Rollback: know how to revert the deploy that broke Dana's workflow before she finds out.

A filing brief that mixes two clients' matters is not a rough edge; it is a breach. A salary-bands tool that stores submitted pay data without consent and deletion is not lean; it is liable. Small scope, full seriousness.

Exercise: write V1-SCOPE.md → roadmap and cards

Create a one-page V1-SCOPE.md for your wedge:

# V1 Scope — House-Price Comparables Brief

## User flow
Enter address + radius → view 5 sourced comps → save search.

## Acceptance checks
- Given valid address, when comps exist, then 5 cards render with source links in <10s.
- Given no comps in radius, when searched, then honest empty state, no save prompt.
- Given signed-out visitor, when saving, then denied + routed to sign-in, nothing written.
- Given provider timeout, when brief requested, then error state + logged request ID.

## Trust boundaries
- Only public deed/listing sources; no private seller data.
- Saved searches visible only to owner. No sharing in v1.
- Every price carries source + date; no price predictions.

## What will be observed
- Searches, saves, empty/error counts, save-to-return rate.
- Weekly 15-min call with two buyers.

## Deliberately deferred
1. Agent team workspaces (need: 10+ repeat savers asking to share).
2. Alerts on new comps (need: repeat searches on same street).
3. Offer-price suggestion (need: trust in sourced comps first + legal review).

Then convert it the Part X way: each acceptance check becomes a task card with its contract, and the deferred list becomes the roadmap — ordered by evidence, not enthusiasm.

Finish line: a V1-SCOPE.md with flow, acceptance checks, trust boundaries, observation plan, user contact, and three explicit deferrals — ready to become a roadmap and task cards.

Verify fast: hand the scope to a builder and ask, "what would you *not* build?" If they cannot answer from the file, the deferrals are too vague. Common failure: acceptance checks without the unauthorized and error cases — the exact cases Part XI taught you never to skip.

Check your understanding

1. What are the five requirements of a v1? 2. How does a private alpha differ from a public beta? 3. What ships and what is deferred in Research Desk v1? 4. Why does "it is only an MVP" never excuse missing authorization or logging?

Next

Class 54 is complete: you can name the outcome, pick the shape, choose the audience, drive the wedge, and scope a v1 that learns. Class 55 asks the bigger question — why AI makes narrow applications like these newly viable, and where their durable advantage comes from once anyone can build.