Part 4 of the Keet Product Challenge · concept plan, not an official Keet document
First two 2-week sprints · weeks 1–4
Make messages arrive when the app is closed, and measure it before we promise it.
The board deck says we build reliability first (Stage 0, "Fix the core"). The deep dive picks the design: blind peers plus content-free push, "P2P-first, not P2P-only". These four weeks turn that into a measured baseline, two answered technical unknowns, and an end-to-end push path in the hands of internal and beta users.
By the end of sprint 2 we can send a message to an Android phone with Keet closed and watch it buzz within seconds, on the Tecno, Infinix and Xiaomi phones our markets use. We also know today's real delivery rate, so the Day-90 targets rest on data.
Sprint 1 · weeks 1–2
See the problem, de-risk the unknowns
Exit: baseline counters live in production · both spikes have a go/no-go · new rooms register with 2 blind peers behind a flag
Sprint 2 · weeks 3–4
Messages reach a closed app, end to end
Exit: push works for internal + opt-in Android beta · delivery states in production · 14-day baseline published
Sprints 3–6 · to Day 90
Widen the beta, media two-core split, push to every linked device, iOS previews if spike 2 allows, onboarding A/B
Day 90: baseline WCU, delivery and cost per MAU · targets re-set · onboarding < 60 s · Keet Pay go/no-go
Who builds what
Split across core P2P, mobile and desktop
Planned for the current team: hiring the board-approved roles (+2 core P2P, +2 mobile, +1 SRE) takes about three months, so new people land for Stage 1. Capacity is in engineer-days per sprint after reserving 30% for live bugs, support and on-call. The bars are computed from the tickets below.
Team (assumed size)
Owns in sprints 1–2
Sprint 1 load
Sprint 2 load
Why core P2P carries most of it
Blind-peer registration, push and quotas are shared plumbing. Once they work, every client gets reliability by calling them. Mobile cannot finish until core exposes the "a blind peer holds it" ack.
Why mobile is the tightest
Both hard unknowns are mobile OS limits: Android killing background apps and iOS extension memory. Sprint 2 mobile is planned at 100%, so the spike outcome decides what we cut (see the rules at the end).
Why desktop goes first on UI
Desktop has no store review and stays online longer, so delivery states land there in sprint 1 for internal dogfooding. Mobile reuses the same state model in sprint 2.
Sprint 1 · weeks 1–2
Goal: measure today's delivery, answer the two riskiest technical questions, and land blind-peer registration behind a flag.
Sprint review demo: the live baseline dashboard; the spike 1 video of a cold-started Android worklet decrypting a message; a room created on staging appearing on two blind peers.
Sprint 2 · weeks 3–4
Goal: messages reach a closed app end to end, through content-free push, for internal users and an opt-in Android beta. Delivery states ship to everyone.
Sprint review demo: kill Keet on a Tecno phone, send from desktop, the phone buzzes with a decrypted preview, desktop flips from ✓ Sent to ✓✓ Delivered. Then the same on an iPhone with a generic notification.
Release policy
What ships stable and what ships experimental
Everything new sits behind a remote flag. "Stable" means production users get it through a staged rollout (5% → 25% → 100%), and each stage is gated on the device-lab delivery suite and crash-free sessions. "Experimental" means internal builds and an opt-in beta channel, off by default.
STABLE to production users
Opt-in delivery counters with a plain-language privacy disclosure (S1)
Blind-peer registration for new rooms, then a backfill of existing DMs and groups ≤ 100 (S1 → S2)
Delivery states on desktop and mobile: Sending → ✓ Sent → ✓✓ Delivered, plus "Will deliver when <name> is online" (S2)
Per-identity storage quotas and a second blind-peer region (S2)
EXPERIMENTAL internal + opt-in beta
Content-free push and the Android wake path with decrypted previews (S2)
iOS generic notifications via the Notification Service Extension, TestFlight only (S2)
60-second onboarding v1: silent key, receive without backup, backup before the first send (S2, flag off in production)
NOT IN SPRINTS 1–2 on purpose
Keet Pay code. Discovery only: interviews, legal and store pre-review, threat model. Beta after Stage 0 exit (~month 6)
Media two-core split, iOS previews, mention-only in large rooms: sprint 3+, and iOS previews depend on spike 2
User-run blind peers, Android always-connected mode: later experiments
Compatibility and rollback. Push is additive. Older clients still get blind-peer catch-up when they open the app ("option B" in the deep dive), so a mixed fleet never loses messages. Rollback is one server flag: push off, which returns everyone to option B within minutes. We drill that rollback once in sprint 2 before any beta user gets push.
End of sprint 2
How we know we are on track
Ten checks, reviewed with the CTO at the sprint 2 review. Green means the Day-90 checkpoint and the month-6 Stage 0 exit (delivery ≥ 99.5%) are still realistic. Targets below Stage 0 exit levels are intentional: this is week 4, on lab devices and a small beta.
Check
Green at end of sprint 2
Red
Source
1. Baseline exists
≥ 14 days of opt-in counters by platform, country and device class
Counters not in production, or too few opt-ins to segment
S1-1
2. Unknowns decided
Spike 1 and spike 2 each have a written go/no-go; Holepunch has answered all 4 questions
Either spike still "unclear", or no answer on token registration
S1-3, S1-4, S1-2
3. Offline reach (lab)
≥ 95% of messages to a closed-app recipient arrive within 60 s of reconnecting (Stage 0 exit: ≥ 99%)
< 85%
S1-6 suite
4. Sender → first blind-peer copy
p95 < 10 s on the lab Android devices
p95 > 30 s
S2-4
5. Push → notification shown
p95 < 5 s on Tecno, Infinix and Xiaomi; iOS generic alert shows with the app killed
Android wake does not complete in the FCM window
S2-2, S2-3
6. Battery
< 2% per day added on Tecno/Infinix-class phones
> 4% per day
S1-6 harness
7. Privacy holds
Payload audit: zero message content or contact identifiers in any push or counter
Any leak (stop-ship)
S2-1, S1-1
8. No regressions
Crash-free sessions ≥ baseline in the beta; rollback drill done
Crash-free drops > 0.5 pt
S2-7
9. Onboarding
Median link-tap → first message < 60 s in ≥ 10 tests on low-end Android
> 90 s, or users stall on the key step
S1-7, S2-6
10. Keet Pay discovery
≥ 30 of 60 interviews done; counsel engaged on money transmission and store rules
< 15 interviews, or no counsel
S1-8, S2-8
8–10 green → on trackSprint 3 widens the Android beta, starts the media two-core split, and moves push toward stable for DMs.
5–7 green → re-planCut experimental scope (onboarding v1, iOS extension work) and put the freed people on the red reliability checks. Day 90 holds.
< 5 green, or a stop-ship → escalateReview with the CTO and Head of Product within 48 h. If the Android wake path is a no-go, the fallback is a generic notification that syncs on open, and we say at Day 90 what that does to the month-6 date.
What could break this plan
Risks and dependencies
Risk
Early signal
Response
Android wake does not fit the FCM window on low-end phones
Spike 1 p95 near or above budget on Tecno/Infinix
Ship a generic notification and sync on open; keep high FCM priority for DMs only; revisit with Holepunch on worklet start time
Push-token registration path differs from our assumption
Holepunch answer in week 1
S2-1 adapts to the actual path. If the gateway is not ready, push stays internal and sprint 2 ships delivery states and blind peers only
Backfilling existing rooms to blind peers costs more than planned
Storage per room in the S1 staging run
Backfill DMs first, then groups ≤ 100; quotas from S2-5; cost per MAU tracked from sprint 2
Opt-in rate too low for a usable baseline
Opt-ins after 7 days
Clearer disclosure copy, an in-app ask after the first successful delivery, and re-weighting on the device panel
Mobile capacity at 100% in sprint 2
Burn-down at mid-sprint
Pre-agreed cut order: S2-6 onboarding first, then S2-3 iOS; the reliability tickets are not cut
Explicit assumptions
What I assumed, to confirm in week 1
Team today: 3 core P2P, 3 mobile, 2 desktop, 1 QA, 1 designer, plus a PM. Real numbers change the bars, not the order.
Keet already runs blind peers (per support.keet.io), so sprint 1 extends existing infrastructure, not builds it.
Holepunch core engineers answer within the first week: token registration, blind-peer-initiated push, per-message expiry, per-device writers.
App Store and Play review take 1–3 days. Production changes land in the first half of a sprint, flag flips in the second.
The opt-in counters fall within the existing privacy policy once the disclosure is updated. Counsel signs off in sprint 1.
Figures are planning estimates. The Day-90 baseline replaces them.