Launch page restructure
Status: EXECUTED 2026-08-10. Kept only as the record of why the page is shaped this way. The live page is the source of truth. Subject: docs/business/launches/README.mdRelated: alpha-readiness gap map (2026-08-03), #825 (colleague onboarding umbrella), #840.
The problem
Phases are categorical: they group work by KIND (merchant system, analytics, legal). I then mapped releases to whole phases, which says "all of Phase 4 ships for Beta". That is wrong in both directions, and we already have proof: the 2026-08-03 gap map lists merchant onboarding seam: application-review to provision as Tier 1, alpha-gating. It sits in Phase 4 in the current page, which claims Beta. A venue cannot run an Alpha session if a merchant cannot be provisioned without an admin hand-bridging the middle.
The categories are useful. Using them as release buckets is what boxes us in.
Structure
Release at the top, phase subsections inside it. Operator's call, after rejecting a flat release-first table: the release is the top-level heading, and phases stay as subsections within it. A phase appears under whichever releases need it, carrying only that release's tasks, so Safety can hold block and report in Alpha and venue certifications later.
Columns: Task | Category | P | Description | Why | Status | Issues. Phase is the subsection, so it leaves the row.
Worked examples are near the bottom of this plan. Phase numbers stay stable across releases, so "Phase 2" always means safety.
| Option | What it does | Risk |
|---|---|---|
| Release, then phase subsections (chosen) | Answers "what is left for Alpha" in one section while keeping categorical context | A phase's work is split across releases, so "all merchant work" needs a search rather than a scroll |
| Flat release-first table, phase as a column | Densest possible view | Rejected: loses the contextual grouping that makes a long list readable |
| Phase-first, add a "required for" column | Smallest change from today | The question the page exists to answer stays scattered across ten sections |
P-ratings
Deliberately three values, because a four-point scale invites arguing about P2 versus P3:
| Rating | Means |
|---|---|
| P0 | Blocks the release. If it is not done, we do not ship. |
| P1 | Should be in the release. Shipping without it is a deliberate, stated choice. |
| P2 | Wanted, cut without ceremony if time is short. |
P-rating is per release: a task can be P0 for Beta and absent from Alpha entirely.
What moves to Alpha
First pass, from the gap map and from what Alpha actually requires operationally. This list is the thing to argue with:
| Task | Currently | Proposed | Why |
|---|---|---|---|
| Merchant provisioning seam | Phase 4 (Beta) | Alpha P0 | Gap-map Tier 1. Today an admin must hand-bridge application to provisioned merchant |
| Venue creation from admin | not listed | Alpha P0 | Gap-map Tier 1, and it landed in #786 / PR #788; needs recording as done |
| Lantern TTL copy defect | not listed | Alpha P0 | Gap-map Tier 1: UI says 48 hours, server says 2 |
| Live two-account E2E | not listed | Alpha P0 | Gap-map Tier 2: the loop was verified by reading code, not by running it |
| Offer moderation gate | Phase 4 (Beta) | Alpha P1 | Gap-map Tier 3 decision; an Alpha with live offers and no gate is a trust risk |
| iOS PWA push verification | Phase 8 (Launch) | Alpha P1 | If Alpha users are on iPhones, push is part of the experiment, not a launch detail |
| Attribution | Phase 6 (Beta) | Alpha P0 (operator) | Alpha runs with real offers, so proving they worked is part of the experiment rather than a Beta refinement |
| Embers | Phase 9 (Launch) | Alpha (operator) | Badges shape which behaviors people repeat, so they need to exist while we are measuring behavior, not after |
What the two operator moves imply
Both are defensible and both grow Alpha, so worth saying out loud rather than discovering in November:
- Attribution in Alpha pulls its dependencies in with it. Attribution reads the event pipeline (built) and merchant offers running live (built), but the receipt itself does not exist yet, and it is the piece with an open design question: no-POS venues get an in-app animated redemption at the counter, POS venues likely a barcode scan. Alpha with one or two venues is actually the ideal place to test the no-POS path, since it needs no merchant systems integration. Recommend scoping Alpha's attribution to the no-POS path only and leaving barcode/POS for Beta.
- Embers in Alpha means the badge system ships before we know which behaviors deserve badges. That is the tension: badges shape behavior, so having them during the measurement changes what we measure. Options are to ship a deliberately small set (showed up, lit a lantern, met someone) and treat the set itself as a hypothesis, or to instrument the behaviors now and grant badges retroactively. Recommend the small fixed set, chosen to reward the two things Alpha exists to prove.
Alpha now carries roughly ten P0 items against a December target. That is not obviously wrong, but the date deserves a fresh look once this table is settled, which is question 1 in the review list below.
Newly agreed additions
- Hire a second engineer (Business, P0 for Public Launch, P1 earlier). The ideation matrix calls it "the biggest single unlock", and it is now load-bearing for rule 21: every PR needs a senior engineer other than the author to approve, which currently has nobody to satisfy it.
- Trademark status corrected to in-progress with real detail: no conflicting USPTO registrations for "LANTERN", "OUR LANTERN" available, classes 35 / 42 / 43 targeted, costs approximately $1,450 US and $3,126 international, Madrid Protocol deferred until US registration completes.
- Quick wins (agreed): top-10 venue selection at signup, interest-based venue filtering (#319), QR code friend linking. All Alpha P1 or P2 candidates; they are small and they make an empty-feeling map less empty.
Ideation matrix
Recommendation: keep the Google Doc as the idea home and link it. Pull individual items into the phase tables only when we commit to them.
Mirroring it into the repo recreates the exact failure this branch spent a day undoing: two copies, one updated, the other quietly lying. The matrix is a thinking space where ideas churn, and the repo is where committed work lives. The boundary is commitment, not format.
The neighborhood chat room line ("real-time neighborhood chat rooms of what is happening in an area, each neighborhood its own room, anyone can type") belongs in the matrix, not in the phases, until we decide on it. Worth noting when it is written up: it is adjacent to Bonfires (group presence) and it inverts our privacy posture, since an open room anyone can type in is a moderation surface with no venue boundary and no anonymity guarantee to lean on. That does not kill it, but it makes it a spec-level decision rather than a feature row.
The partner's area-rating app
Her partner has a working prototype that rates potential areas, and it is where the Lantern admin-portal design ideas came from. Four ways to bring it in:
| Option | What it looks like | Cost | Best when |
|---|---|---|---|
| Port the model (recommended) | Take the scoring METHODOLOGY, reimplement in our BigQuery/Dataform stack against our data | Medium build, zero ongoing dependency | Market selection runs a few times a year, not in realtime |
| Periodic data import | He exports scores, we ingest as a table the admin portal reads | Low | We want his numbers now and can re-import when they change |
| Live API | His app exposes an endpoint, our services call it | Low build, ongoing dependency on his uptime and his roadmap | Scores need to be fresh constantly (they do not) |
| Embed the app | iframe it into the admin portal, the way the docs site already is | Lowest | We want his UI, not his data, in front of us |
Recommendation: port the model, or start with a one-off import to unblock market selection now. Market choice is a slow decision, so a live integration buys nothing and adds a dependency on someone else's prototype staying up.
Flag before any of it: this is his work. Whose IP is the methodology, and what does he get? That is a conversation and possibly a written agreement, and it should happen before we build on it rather than after. Worth pairing with the cofounder-agreement thread already in the governance work.
Operator's preferred direction, which supersedes the four options above: build an app creation portal for non-engineers, so he can build and maintain the app himself against our infrastructure rather than handing us a model to port. Filed as #849, deliberately marked as needing a spec first: the audience question (internal only versus external) and the data-access question (what can a hosted app read or write) decide most of the cost, and everything a created app can reach becomes a permanent part of our privacy surface. Not Alpha-blocking.
The four integration options stay on the table as the interim answer, since the portal is a platform build and market selection is a decision we want sooner than that.
Steps
- Agree the Alpha reshuffle table above (this is the real decision; everything else is mechanical).
- Restructure the page: release-first sections, task rows gaining Phase and P columns, phase definitions moved to a reference section.
- Fold in the agreed additions (engineer, trademark detail, quick wins).
- Re-point cross-references that name phase numbers (SEALED_IDENTITY already fixed once; re-check after renumbering).
- Gates: em dash, md tables, link resolver.
Executed
The page was rebuilt on 2026-08-10 and is live at docs/business/launches/README.md. Read that, not this.
The worked examples that used to sit here were removed because they went stale within hours and contradicted the real page: they showed a Beta section holding POS attribution and merchant dashboards after both had moved to Alpha. A planning doc that keeps a copy of the thing it planned is the same drift trap this branch spent the day removing elsewhere.
Final shape, for the record: two releases (Alpha December 2026, Beta Summer 2027), phases as subsections inside each, lettered sub-areas inside Phase 1, and Recruitment last. Alpha carries essentially everything, including legal, hardening, mobile, and go-to-market. Beta carries exactly two items, safety locations and venue certifications, both needing outside organizations and funding.
The decomposition question this raises
Her example nests Merchant System under Phase 1, but merchant system is currently Phase 4. Both readings are coherent and they produce different pages, so this is the last thing to settle before executing:
| Option | Shape | Consequence |
|---|---|---|
| A. Fewer, broader phases with lettered sub-areas | Phase 1 Core mechanics holds 1.A App build, 1.B Merchant system, 1.C Admin portal, 1.D Splash site. Phases become "kinds of concern" (build, safety, recruitment, legal) and sub-areas become "which surface" | Matches her example exactly. Fewer phases to remember. Sub-area becomes the thing you scan for, and "merchant system" stops being a phase-level noun |
| B. Keep the ten phases, add sub-areas only where a phase is large | Merchant system stays Phase 4, but Phase 1 still splits into 1.A app / 1.B admin where useful | Smaller change, keeps existing phase numbers stable for cross-references. Her example would then read as 1.B being something other than merchant system |
Recommendation: A, because it is what she drew, and because "core mechanics" honestly does cover the merchant build (it is all the same product surface, just a different audience). The cost is renumbering, which means re-checking cross-doc references to phase numbers, a known trap we already hit once with SEALED_IDENTITY.
Example 1 above is written in shape A so it can be judged directly.
Ordering convention either way: engineering-heavy sub-areas first within a phase, since that is where the volume sits, with business and operational areas after.
Open questions
- Is the Alpha reshuffle right, now that it is roughly ten P0 items against December? Offer moderation and iOS push were my judgment rather than evidence, and attribution and Embers were yours. If the list is right and the date is tight, the date is the thing to move, not the list.
- Do phases keep numbers, or become names only? Numbers are referenced elsewhere; names survive reordering.
- Does the gap map merge into this page, or stay a separate frozen audit? It overlaps now, and two lists of Alpha-gating work is the same duplication trap.