The opportunity
Roger trains personal reliability through proof feedback, not generic todo management: you make commitments (Axioms), gather evidence (Proofs), and a red/yellow/green signal lets you and a small trusted circle see how consistently you follow through. The original architecture put authority on a macOS home-base daemon with a local database — which limits resilience, multi-device access, and the team-style processing the product now needs.
The hypothesis
Moving the authority model to a Firebase-native platform — Firestore as the canonical live-state source, Cloud Functions Gen2 for all background processing, and SES as the single email channel — makes state durable, multi-surface, and operable without a desktop hub. If the migration holds state consistency throughout, the product gains reliability and reach while the macOS daemon is retired on schedule.
Current state → future state
| Current state | A macOS home-base daemon and local SQLite hold authority; the browser extension collects telemetry into it. |
| Problem / pain | Single-host authority limits resilience, multi-device access, and serverless background processing. |
| Who is affected | Users tracking commitments and the trusted circle who sees their signal. |
| Impact focus | Durability · reach · operational simplicity. |
| What success looks like | Firestore is the live-state authority; Cloud Functions derive all state; the macOS hub is cleanly decommissioned (FB16). |
| What would improve | Consistent state across surfaces, reliable telemetry capture, and no webhook mesh writing outside Firestore. |
| Constraints & risks | The legacy daemon must stay active during the migration window; no data loss or continuity gap during cutover. |
How impact is measured
- Live-state authority consistency — agreement between surfaces with Firestore as the single source of truth.
- Migration epics completed — progress through the FB01–FB16 migration plan.
- Telemetry capture reliability — share of work-app signal reliably recorded as events.
Why it’s a Lab case
It is a bounded, sponsored migration with a measurable end state and a hard decommission milestone — the kind of governed platform move, with a single declared authority and a staged cutover, that becomes a reusable migration pattern for other single-host systems going serverless.
The exact system may be different. The pattern is what matters: a real workflow, a measurable pain, and a bounded first proof point.
Tell us your version →