Selection by job, not popularity. The fewest model providers, tools, databases, services, and deployment surfaces that can produce the first useful result — each with a stated permission, cost, and reason. That is the whole lesson, and it prevents most final-project failures.

Fewest moving parts that prove the job

Every added provider, database, and surface multiplies failure modes: another key to leak, another bill to watch, another log to find, another permission to misconfigure. The minimum stack asks the opposite question: what is the smallest set that completes one valuable path for one user?

Five durable distinctions govern every choice:

• Local versus cloud. Build and test locally where iteration is cheap; run in the cloud only what must stay online (a queue, a scheduled fetch, a shared review page).
• Test versus production. Test data, test keys, test database — so experiments cannot corrupt real users or real money.
• Read versus write. Default to read-only. Every write permission (send email, publish, charge, delete) earns a named gate in Lesson 90.5.
• Proposal versus action. A model drafts; a human or a narrow rule approves before anything external happens. Drafts are cheap; actions have consequences.
• Direct model output versus verified evidence. Model text is a proposal until checked against a source, a calculation, or a test. The brief's claim is not real because the model wrote it; it is real because a filing confirms it.

Apply them to the local service launcher, the lesson's reference case. A landing page, a small form writing to one database, one calendar integration, one notification path, and one human review queue suffice. That is five components, one database, one surface. It does not need a multi-agent platform, a vector store, three model providers, or a dashboard suite. Each of those is a named deferral with a trigger, not an oversight.

The four decisions

Every final project must record four decisions explicitly:

1. Model / provider approach. Which model(s), through which provider, for which transform — plus fallback. One provider for v1 unless two jobs genuinely differ (e.g., cheap structuring versus careful drafting). Note context needs, cost per run, and what happens on failure. 2. Data / tool source. Where facts come from: filings API, calendar API, form input, search. Name the source, its freshness, its limits, and its key handling. 3. Storage and deployment. Where state rests and where code runs: one database, one host. Local-first with one deployed preview is usually enough for v1. 4. Identity / payment — only if v1 needs them. Most first releases do not. Manual invoicing, a booking email, or a free pilot teaches faster than wiring auth and billing before anyone returns. If v1 charges, name the provider, the event, and the refund rule.

For Sonariq v1: one model provider with two named calls (structure, draft); filings plus market-data APIs as sources; Markdown plus one Postgres; no auth, manual pilot billing. For the Classroom v1: one provider for draft assistance; Markdown files in git as storage; static hosting; no payment at all.

Exercise: write STACK-CHOICES.md

Create FINAL-PROJECT/STACK-CHOICES.md. Every component gets five lines: job, permission, cost/limit, alternative, verdict.

# STACK-CHOICES — [Project], [date]

## Decision 1 — Model/provider
- Chosen: [provider + model + which transform]
- Job: …
- Permission: [keys held where; no write access beyond …]
- Cost/limit: [$/1k runs, rate/quote caps]
- Alternative considered + why deferred: …

## Decision 2 — Data/tool source
- (same five lines per source)

## Decision 3 — Storage + deployment
- (same five lines; include local→preview→prod path)

## Decision 4 — Identity/payment (or explicit NOT-NEEDED)
- Needed for v1? [yes/no + reason]
- If yes: provider, event, refund/cancel rule

## Permission + boundary summary
- Read-only by default: [list]
- Write permissions granted: [each with its gate → 90.5]
- Test vs prod separation: …

Finish line: a deliberate stack — typically 3–6 components, one database, one surface — with every permission, cost, and deferral reason written down. No mysterious services.

Verify: for each component, ask "if this bill tripled or this key leaked tomorrow, what breaks?" If the answer is vague, the permission or cost line is vague. Then count providers, databases, and surfaces. If any count exceeds two for v1, justify it in writing or cut it.

Common failure mode: résumé stacking — choosing tools to learn rather than to ship. The symptom is three overlapping services doing one transform. Its mirror is hidden production: testing against the live database or live calendar "just this once." Test and prod separate from day one, even when prod is one pilot user.

Saying no on paper

Every stack choice closes a door loudly enough that future-you hears it. Write the rejected alternative and its trigger for return: serverless functions deferred until the scheduler runs hourly; a second model provider deferred until one call demonstrably fails the quality bar; team auth deferred until the second pilot asks for shared access. These sentences prevent midnight re-architecture driven by a blog post. They also make costs reviewable: one provider bill, one host bill, one data bill. When Lesson 90.9 sets caps, each cap maps to exactly one line in STACK-CHOICES, and the pause order is obvious because the dependency order was drawn in Lesson 90.2.

Check your understanding

1. Why does read-by-default with named write gates reduce both security and quality risk? 2. When should identity/payment be deliberately excluded from v1? 3. Name the launcher's five sufficient components and one thing it correctly defers.

Next

The stack is chosen and bounded. Lesson 90.5 draws the tighter boundary around the riskiest part — what your agents and automations may do, prepare, and never touch.