Ready Together only earns its place if practicing on two phones gives two people something they would not get from reading the same instructions on one shared screen.
The product promise is deliberately simple: knowing what to do is not enough. Everyone needs to practice it. The difficult part is proving that a shared practice creates clearer responsibility instead of extra setup.
That sounds obvious when the product is described in a pitch. It is not obvious in a physical test. A second device can create clearer responsibility and independent participation—or it can add setup friction to something that was simpler on one phone.
I do not want architecture, automated tests, or a polished interface to answer that product question for me. The next gate is deliberately physical: one Android phone, one iPhone, one shared practice, and thresholds strict enough to force a real decision.
The question behind the test
Authorities already publish preparedness guidance. Messaging apps already let a household communicate. Ready Together is exploring a narrower missing layer: can each person receive an explicit responsibility, start at the same time, keep going when one phone loses connectivity, and finish with one factual improvement the group can act on?
If the experience is only a checklist displayed twice, two devices are complexity—not value. The test therefore asks more than whether both apps can reach the last screen.
What changed before the physical run
Since I first wrote this experiment, the implementation has moved from a room skeleton to one bounded practice journey. The app now explains the single supported scenario before it creates or restores a private room. That preflight names the approximate duration, the purpose of using more than one phone, the connectivity boundary, and the fact that this is a drill—not a real alert.
After both participants are ready, the organizer can schedule an authoritative start. Each participant receives a semantic role and responsibility, while the countdown is derived from the server-confirmed time rather than either phone's wall clock. If connectivity disappears after the practice has begun, bundled instructions remain available and an accepted local action can wait for reconciliation.
Completion now leads to one collective report. It presents observed participation and assigned responsibilities, then selects one factual next focus: include a nonresponder, clarify an unconfirmed responsibility, or practice again. A compatible report already observed by a device can be reopened honestly as stale or offline; it is never presented as a safety score or proof that a household is prepared.
What automation proved before the phones
The repository contains the shared drill state machine, semantic roles, canonical start time, offline action reconciliation, and one authoritative collective report. Native Share and QR present the same expiring invitation. Automated suites cover deterministic assignment, strict contract decoding, scheduling, duplicate and delayed delivery, restore, offline action replay, report projection, and fail-closed incompatible states across shared JVM, Android-host, server, and iOS compilation checks.
That evidence matters, but it stops at the boundary it actually observed. It does not prove that a camera scans the QR reliably, that an operating system opens the link as expected, that two physical screens begin together, or that a first-time participant understands the report.
The physical Gate A
The planned experiment has seven measurable parts:
- Complete ten invitation-to-report trials: five through Share and five through QR, in both platform directions.
- Join the intended practice in under one minute in every successful trial.
- Show the shared start on Android and iPhone within one second.
- Keep one phone offline for at least one minute, continue locally, and reconcile one action exactly once.
- Converge on the same report revision, with every assigned responsibility represented once.
- Have at least four of five first-time viewers identify one observed result and one improvement in ten seconds, without coaching.
- Have at least four of five first-time lead participants prefer two devices and name a concrete benefit they observed.
The invitation is also tested adversarially. Same-device, expired, revoked, reused, and concurrent attempts must fail without revealing private room facts or turning an invalid capability into access.
The test is allowed to say no
Gate A has three legitimate outcomes:
- Continue: the physical journey and the product-value thresholds pass.
- Redefine: the technology is stable, but people reveal one narrow comprehension or value problem worth retesting.
- Stop: people prefer one phone, cannot name a separate-device benefit, or the journey cannot become reliable within the calendar.
A stop result would be uncomfortable, but useful. Adding more maps, feeds, notifications, or gamification would not rescue a core interaction that people do not value. Building in public should make that decision harder to hide, not easier to spin.
What I am not claiming yet
No physical trial result is recorded today. I am not claiming that Android and iPhone have completed this journey, that starts are within one second, that offline recovery works on real devices, or that a household prefers the experience.
Ready Together is also not an earthquake alert or early-warning system, and it is not released in either store. A practice report is limited evidence about one exercise; it is not a safety score or certification.
What I will share after the run
The next version of this field note will replace thresholds with counted observations: completed and failed trials, join times, visible start deltas, reconciliation results, report consistency, and the final continue, redefine, or stop decision.
I will share failures as failures and omit names, exact locations, invitation tokens, credentials, medical details, and private analytics. The interesting outcome is not a perfect demo. It is learning whether two people discovered something together that one phone would have missed.