Does routine feel lighter when shopping, tasks, and context live in one place?
Synchronize several residents' routines without losing authorship, recurrence, or household-level data isolation.
CASE FILE. 07 / MOBILE / HOUSEHOLD
Our Home
An iPhone app where couples and families share shopping, recurring tasks, and responsibilities with real-time synchronization.
- Expo SDK 57
- React Native
- TypeScript
- Supabase
- PostgreSQL
BRIEF. 01 / PROBLEM AND BOUNDARY
The product in one read.
A deliberate view of the current state. Metrics and the hypothesis remain editorial until public evidence can replace them.
- ROUTINE
- SHOPPING + TASKS EDITORIAL LABEL
- SYNC
- REALTIME + RLS EDITORIAL LABEL
- CAPABILITIES
- 5 frontend / backend / data / realtime / integrations
- PUBLIC DOOR
- NO PRIVATE SURFACE
SYSTEM TRACE. 02 / PRIMARY FLOW
Boundaries before frameworks.
React Native app → Supabase commands and channels → PostgreSQL with RLS, RPCs, and triggers → synchronized household projection.
- 01APP→
iOS client
Expo / React Native / TypeScript
- 02SYNC→
Realtime projection
Supabase channels / refresh
- 03DOMAIN→
Database commands
RPCs, triggers, and recurrence
- 04DATA
Household boundary
PostgreSQL / Auth / RLS
intent → policy → authoritative state → observable effectEXECUTION TRACE / ILLUSTRATIVE
One path. Every decision in view.
An editorial sequence for discussing contract, authority, and effect. It does not represent real production telemetry.
- APP
Sends the intent with task, new status, and authenticated session.
status.requested - DOMAIN
The RPC validates household membership and applies the transition.
status.changed | denied - DATA
Triggers record author and time and calculate the next occurrence.
history.appended - SYNC
The event invalidates the projection and each resident reloads household state.
household.converged
DECISION LOG. 03 / TRADE-OFFS
Every choice costs something.
Keep authorization and critical transitions close to the database; the app sends intents and reconciles the projection through Realtime.
- 01 / AUTHORIZATION
RLS and critical commands close to the database
- GAIN
- The household boundary remains valid outside the mobile interface.
- COST
- Migrations, grants, RPCs, and policies must evolve and be tested together.
- 02 / SYNC
Event invalidates; client reloads projection
- GAIN
- The MVP avoids rebuilding every concurrent mutation locally.
- COST
- Convergence performs extra reads and depends on well-handled recovery.
- 03 / SCOPE
One active household in the initial interface
- GAIN
- Creation, invitation, and routine reach use before a broader selector.
- COST
- The database supports multiple households, but navigation between them is deferred.
RELIABILITY. 04 / FAIL WITH CONTEXT
Failure mode. Signal back.
These are not published production metrics. They are risks the design must make observable and candidate signals for the next round.
- 01
Invitation and removal of the same resident happen almost simultaneously.
- 02
A monthly task completed near a time-zone boundary reopens on the wrong date.
- 03
The app misses events while suspended on iPhone.
- 01
Time between a change and convergence across devices in the same household.
- 02
RLS denials and failures by RPC, table, and resident role.
- 03
Recurrences reopened on the correct date by frequency and time zone.
INCIDENT DRILL. 05 / CONTAINMENT → RECOVERY → PROOF
When the hypothesis breaks.
Editorial resilience exercises, not real incidents or production runbooks. Each drill turns a failure mode into a response that can be discussed and tested.
DRILL-01Invitation and removal of the same resident happen almost simultaneously.SIMULATION / NATIVE
Response to: Invitation and removal of the same resident happen almost simultaneously.
- CONTAIN
- Serialize database entry, revoke invitations for the removed person, and check the block before creating membership.
- RECOVER
- Keep the account outside the household and require an explicit administrative decision for future unblocking.
- PROVE
- Repeat the transactional race and confirm no membership, a persisted block, and revoked codes.
DRILL-02A monthly task completed near a time-zone boundary reopens on the wrong date.SIMULATION / NATIVE
Response to: A monthly task completed near a time-zone boundary reopens on the wrong date.
- CONTAIN
- Preserve the current occurrence and stop rollovers derived from an inconsistent time reference.
- RECOVER
- Recalculate the next date on the server from the persisted rule and resume the task once.
- PROVE
- Run time-zone, month, and year boundary cases and verify status, next_due_at, and the automated event.
DRILL-03The app misses events while suspended on iPhone.SIMULATION / NATIVE
Response to: The app misses events while suspended on iPhone.
- CONTAIN
- Do not assume the in-memory projection remains current after an app-state change.
- RECOVER
- Revalidate session and context on return to active, then reload members, shopping, and tasks.
- PROVE
- Change the household on another device during suspension and confirm convergence after recovery.
DESIGN EXERCISE / REVIEW AGAINST REAL TELEMETRY AND RUNBOOKS BEFORE OPERATING
EVIDENCE. 06 / WHAT CAN BE DEFENDED
Facts in view. Gaps too.
Validate version 1.0 on physical iPhones before adding notifications and a shared calendar.
- Expo SDK 57 + React Native
- Supabase Auth, Postgres + Realtime
- Shared shopping and tasks
- Recurrence + status history
- RLS + in-app account deletion
- Version 1.0 prepared for iPhone
INTERVIEW MODE. 07 / DEEPEN THE CONVERSATION
Three points to open on the board.
Questions that connect the case to system design, product, and operations without turning a contextual decision into a universal rule.
- 01
How to design RLS and RPCs so the multi-tenant boundary does not depend on the client.
↗ - 02
When to replace invalidation plus refresh with incremental events or offline-first state.
↗ - 03
How to test recurrence, invitation concurrency, and mobile recovery without relying on the real clock.
↗
CASE FILE / 07