You have a small architecture and explicit contracts. Now comes the decision nobody can make for you: where should this system live, who operates it, and what does that choice cost? There is no perfect answer — only tradeoffs recorded honestly enough to revisit.

The ADR: a short record of a consequential choice

An architecture decision record (ADR) is a short durable record of a consequential technical choice and its tradeoffs. One decision, one page, written when the choice is made — not reconstructed months later from chat history.

Keep this fixed shape:

• Context — what situation forced a choice, and what constraints applied (scale, skills, timeline, risk tier).
• Decision — what you chose, stated plainly.
• Alternatives considered — the serious contenders, each in a sentence.
• Why this choice now — the reasons that tipped the balance *at this scale, at this time*.
• Consequences — what gets easier, what gets harder, what new risk appears.
• Owner — who is responsible for this decision holding up.
• Review trigger — the observable condition that reopens the decision.

The trigger is the most important field. "We will revisit if needed" reopens nothing. "We will revisit when refresh jobs exceed web-request time limits on three consecutive weeks" assigns a tripwire. AI agents are good at drafting ADRs from your notes; only you can set the tripwire honestly.

Managed, self-hosted, serverless, VPS: the real tradeoff

Strip away vendor catalogs and four postures remain:

None wins universally. A solo builder serving 1,000 users trades control for sleep and picks managed. A team with unusual networking or long-running private workers may outgrow serverless timeouts and earn a VPS. The right answer changes with scale, skills, and risk — which is why the ADR records *why now*, not *why forever*.

A warning from Parts VI and VII: Supabase or Neon, Vercel or Cloudflare, object storage, a VPS, a worker — these are tools in an architecture, not the architecture by themselves. Naming a vendor is not a design. The design is which responsibilities each tool holds, which arrows connect them, and which contracts govern those arrows. Vendors change menus; responsibilities endure.

A real decision: Research Desk v1

Here is Research Desk's first ADR in plain language:

Context: Solo builder, first 1,000 users, public briefs plus private watchlists, one scheduled refresh. No team to operate servers, no long-running private compute.

Decision: Managed Postgres with integrated auth plus a hosted web deployment for v1. No personal VPS serving an API route.

Alternatives considered: a self-operated VPS for full control; a fully serverless-only design for scale-to-zero.

Why now: the managed stack ships sign-in, session handling, row-level policies, and backups on day one; the hosted deployment gives preview URLs and rollbacks that match the Part X delivery loop. A VPS would trade weeks of operating burden for control this product does not yet need.

Consequences: faster shipping and fewer 3 a.m. pages; in exchange, database-connection limits, provider quotas, and per-seat or usage pricing become real constraints to monitor.

Owner: the builder (you), reviewing monthly.

Revisit triggers: long-running private workers that exceed hosted time limits; unusual networking the platform cannot express; sustained workloads where VPS operating cost beats provider metering; or a team able to operate servers joining the project.

That last line is the discipline. The decision is allowed to be wrong later, because the conditions for "later" are written down now.

Cost is a design constraint

Architecture choices meter money the way API routes meter requests. Teach yourself to read the price tag beyond the sticker:

• Provider request limits and quotas — market-data calls, filing fetches, auth emails per month.
• Storage and database — rows, connections, backup retention, object-storage volume.
• Model calls — every AI-generated summary or refresh has a per-token price; a retry loop multiplies it.
• Egress and bandwidth — bytes leaving the platform, especially images and large brief payloads.
• Observability — log retention, metrics cardinality, alert destinations.

The low sticker price is not the only price. A "free tier" with a 10-second function timeout that kills your refresh job is expensive in debugging hours. A cheap VPS that needs weekend patching is expensive in attention. Ask an AI to estimate monthly cost from your expected flows — searches per day, briefs refreshed per hour, watchlist writes per user — then demand it cite which pricing dimension each number comes from. Guesses without dimensions are theater.

Practical exercise: write the ADR

Create DECISIONS.md (or docs/adr-001-hosting.md) and record your first stack decision:

1. Use the seven-field shape above: context, decision, alternatives, why now, consequences, owner, trigger. 2. Name one alternative you rejected and the observable condition that would revive it. 3. Link the ADR from ARCHITECTURE.md (Lesson 46.1) and from ROADMAP.md (Part X) — the decision must be findable from both the system picture and the plan.

Finish line: a DECISIONS.md entry linked from ARCHITECTURE.md and ROADMAP.md, naming the chosen data/auth/hosting stack, one rejected alternative, and a measurable revisit trigger. Record it through the normal Part X delivery loop — a branch, a task card, and a reviewed PR using the GitHub pull-request review flow — so the tradeoff gets a second reader before it becomes the system's foundation.

Verify: cover the decision and read only the trigger. Could a stranger check a dashboard and tell you whether the trigger has fired? If not, rewrite it with a number, a duration, or a named capability.

Common failure mode: listing vendors without consequences or triggers. "We use X" is inventory, not a decision. "We use X because Y, accept cost Z, and revisit when W" is architecture.

Check your understanding

1. Recite the seven ADR fields. Which one reopens the decision? 2. When does a managed stack beat self-hosting, and when does that flip? 3. Why are the tools from Parts VI–VII not "the architecture"? 4. What was Research Desk's v1 decision, and what three conditions would revisit it? 5. Name four cost dimensions beyond the sticker price.