📱 Android Early Access — Sequencing Plan

Ordered for testability: get each feature into a state QA can exercise as early as possible, so we collect feedback while there's runway to fix. Keeps the proposed priority order, front-loads the access spine, fills the gaps.
Ship by
Jun 24
Donald back 22nd

Milestone roadmap

M0 · Access spineowner: Rhys · parallel

Installable Dev/Alpha/Beta build + Google login + minimal onboarding that reaches the home/call screen. Internal QA confirmed via Firebase App Tester — Alex is in and testing today. M0 now narrows to external/Play distribution for the Open Testing launch.

Exit: Play Open Testing track live; external testers can install via the Play listing.
PMF-3175 Play tracksInternal QA on Firebase App Tester ✓
M1 · CallsSinger / Amos / Rhys

Highest-risk, highest-value, mostly there. Reconnect on drop, session resume, network handover, 5001 recovery.

Exit: QA places a call, survives wifi↔LTE handover, recovers from drops.
PMF-2849 epicPMF-2782 reconnectPMF-2870 /v1/reconnectPMF-3071/3072 handoverPMF-3067 5001PMF-3095 Charlie+Simone ✓PMF-2866 Telecom hold
M2 · TextsAmos (focused)

Chat reconnect, character-switch history UX, send-button stall recovery.

Exit: QA holds a text conversation, switches characters, recovers from stalls.
PMF-2794 epicPMF-3047 reconnect RPCPMF-3048 switch UX#17369 send button
M3 · Waitlist flowDonald

Confirmed launch requirement. In-app gate (GET /waitlist/status → app-or-waitlist-screen) + waitlist entry screen + Statsig waitlist_auto_approve for early-adopter admission. Reuses iOS waitlist infra end-to-end.

Exit: non-allowlisted users hit the waitlist screen; Statsig auto-approve admits early adopters into the app.
PMF-3090 Statsig gateClient gate logicWaitlist entry screen
M4 · SDUI cardsRhys

Framework, shell, carousel, Search card all done. Finish card content + post-call rendering.

Exit: QA sees cards in-call and in the post-call activity sheet.
PMF-2719/2720/2721 ✓PMF-2927/2930 ✓PMF-2722 #7 AgentFilePMF-2724 #9 post-callPMF-2723 #8 ExtSearch
M5 · Push + universal linksRhys / Donald

In-scope per the Open Testing commitment. FCM plumbing → permission prompt → text/waitlist push → deep-link tap-through. + gap: universal links.

Exit: QA receives a push and deep-links into the right screen.
PMF-3085 epicPMF-3182 FCM plumbingPMF-3086 permissionPMF-1960 text pushPMF-3100 waitlist pushPMF-3087 settings
M6 · AnalyticsDonald

Final polish: verify waitlist_joined / waitlist_approved events fire on Android, web→app funnel from sesame.com/beta, Rudderstack + Bitdrift sinks. Mostly-built framework needs Android wiring + verification.

Exit: joined/approved events verified; web → in-app funnel intact.
PMF-3089 beta opt-inwaitlist_joined/approvedRudderstack/Bitdrift

Progress by milestone

M0 Access spine · 1/2
M1 Calls · 1/5
M2 Texts · 0/3
M3 Waitlist flow · 0/3
M4 SDUI cards · 2/4
M5 Push + links · 0/5
M6 Analytics · 0/3
Bar length = items in that milestone; solid fill = done, faded = remaining. Counts exclude parent epics and stretch items. Longest bars (M1 Calls, M5 Push) carry the most outstanding work.

Gaps the original list was missing

➕ Add to scope

  • Distribution / release plumbing — Play tracks (PMF-3175), Firebase suffix builds, signing. The true M0; nothing is QA-able without it.
  • Onboarding flow — gender, agent audio sampler (CHA-55), greeting. Sits between login and calls/texts.
  • Universal / deep links — required by Open Testing + push tap-through + sesame.com/beta hand-off.
  • Profile / character parity — confirm release profiles reach Android (PMF-3194 was canceled — verify it's covered).

⛔ Out of scope for 6/24

  • Apple Sign-In on Android (PMF-3215) — deferred post-launch. Ticket stays open in Linear as backlog. iOS-user migration via Apple ID will require pickup before that funnel is meaningful.
  • Android Auto (PMF-2704, PMF-2708) — backlog, Level 4, partner application + production rollout. Separate train.

❓ Confirm with team

  • Waitlist promotion cadence (time / count / manual) — sizes the M6 analytics work + M3 admission policy.

Items to validate in Linear

Plan items that don't reference a Linear ticket — confirm whether each needs to be tracked, is already covered by an existing issue, or can be dropped.