Part 4 of the Keet Product Challenge · concept plan, not an official Keet document
First two 2-week sprints · weeks 1–4
When the phone buzzes, the message is there, and we measure it before we promise it.
Push already wakes phones today: I checked it on an iPhone with Keet killed. What users report since September is the gap after the buzz (see below). 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 a wake → sync → show 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, within seconds, see it buzz and open straight onto the message, on the Tecno, Infinix and Xiaomi phones our markets use: with a decrypted preview if spike 1 holds, with a generic alert if it does not. 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 · blind peers on for all new rooms · delivery states rolling out · 14-day baseline published
Sprints 3–6 · to Day 90
Widen the beta, device-linking fixes from the S1 suite, second blind-peer region, 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
Why this first
What users report today
About 60 of the newest Google Play reviews, read on 10 November 2026 (rating 4.4★, 2.9K reviews). Missing-notification complaints cluster in August and September, around one release; since October the pattern is different.
The buzz without the message
A notification arrives but the chat will not load (Nov 6); a message shows up a day late (Sep 30).
QR, link and recovery phrase all hang; a new identity on each attempt (Sep 28, Oct 28).
→ S1-6 adds linking to the nightly suite; fixes in sprint 3+
Full text on the lock screen
Privacy-minded users object to readable previews on a locked phone (Sep 30, Oct 10).
→ previews become a setting, hidden on the lock screen by default (S2-2)
Releases that break receiving
The most-upvoted recent review: an update stopped messages arriving (Sep 17, 155 found it helpful).
→ the delivery suite gates every rollout step (S1-6, S2-7)
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. Blind peers reach 100% of new rooms and delivery states start their staged rollout.
Sprint review demo: kill Keet on a Tecno phone, send from desktop, the phone buzzes (decrypted preview if spike 1 was a go), 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: behind a flag in S1, 100% of new rooms in S2, backfill of existing DMs and groups ≤ 100 starting in S2
Delivery states on desktop and mobile: Sending → ✓ Sent → ✓✓ Delivered (from batched recipient receipts, DMs only), plus "Will deliver when <name> is online". Staged rollout starts in S2, 100% in S3
Per-identity storage quotas (S2), so storage cannot be abused as rollout grows
EXPERIMENTAL internal + opt-in beta
Push tied to blind peers and the Android wake path with decrypted previews, hidden on the lock screen by default (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
Trust & safety tooling (report, block, payment warnings): starts when the T&S lead joins (~month 3); sprints 1–2 only threat-model claim links
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) once any upgraded member has registered the room. A mixed fleet never does worse than today: chats between two old clients behave exactly as they do now. 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 from ≥ 2,000 devices, by platform, country and device class, including WCU
Counters not in production, or < 500 opt-in devices
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 → message readable
p95 < 5 s from push to the message readable in the chat, 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 at 100% and core at ~90% 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. Core P2P has ~10% slack, used first for S2-1
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) and sends pushes (seen on an iPhone), so sprint 1 measures and extends what exists, 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.