Architecture should follow the user's operating reality, not a fashionable default.
Start with constraints
Some users work with unreliable connectivity, sensitive operational records, or devices that must remain useful for years. In those settings, an always-online architecture can turn a technical preference into an operational dependency.
Local-first design begins by asking what must still work when the network, subscription, or service is unavailable. The answer defines the product's minimum resilient state.
The trade-offs remain real
Local data reduces some dependencies but introduces others: backup clarity, device migration, conflict handling, and user responsibility. A good product makes those trade-offs explicit instead of presenting local-first as a universal answer.
- Define backup ownership
- Design safe export and restore
- Explain device migration
- Add cloud only where it creates value
Choose by workflow
The right architecture may be local-only, local-first with optional sync, or cloud-led. The decision should be made from collaboration needs, sensitivity, connectivity, lifecycle cost, and the consequences of downtime.
