ADR-0002: Local-first, offline-only architecture

Context

The product must provide a reliable, private capture and reflection experience even when the device is offline or network connectivity is intermittent. Early roadmap and constraints favor a small scope for the MVP: minimizing operational complexity and surface area for privacy concerns.

Decision

We will adopt a local-first, offline-only architecture for the initial product phases.

We will persist and serve all user data on-device, and not depend on any remote services or network-based features in the baseline implementation.

Scope boundaries:

• Applies to all primary user data (InboxItem, ProcessedItem, DailyReflection, WeeklySynthesis, PersonalVision).
• Does not preclude future opt-in network features behind explicit ADRs.

Rationale

• Privacy: keeping data on-device reduces risk and simplifies privacy obligations.
• Reliability: core features must work without connectivity.
• Development velocity: avoids building and maintaining backend infrastructure for MVP.
• User trust: positions the product as privacy-first by design.

Consequences

• Positive:

  • Faster MVP iteration without backend dependencies.
  • Simplified deployment and fewer operational costs.
  • Clear privacy advantage for users.

• Downsides:

  • No built-in cloud sync, backup or multi-device support initially.
  • Some future features (shared data, remote ML) require additional ADRs and design work.

Follow-up work:

• Define a migration path and ADR for optional, opt-in sync/backup.
• Decide a secure export/import mechanism and backup strategy.

Alternatives Considered

• Hybrid (local-first with optional sync) — deferred: useful but adds scope and privacy complexity for MVP.

Notes

• Any future networked feature must be documented in a separate ADR that addresses privacy, opt-in, encryption, and server-side requirements.