Why we ship local-first software

Most apps treat the network as a given. Open the app, fetch from the server, render the result. It works beautifully in a demo — and falls apart the moment you're on a train, in a stadium, or anywhere the signal drops.

We build the other way around. The device is the source of truth; the network is a bonus. We call it local-first, and it shapes every decision that follows.

What local-first actually means

Three properties, in order of importance:

1. Every write hits the device first. Tapping a button changes local state instantly — no spinner waiting on a round trip.
2. Sync happens in the background. When there's a connection, changes reconcile quietly. When there isn't, nothing breaks.
3. The UI never lies. What you see is the real, current state of your data — not an optimistic guess that might roll back.

"Offline isn't an edge case. For half our users, it's Tuesday."

Why it feels better

There's a subtle thing that happens when the network stops mediating every interaction: the app feels faster than it has any right to. No loading states between taps, no layout shift when data arrives late, no "pull to refresh" because there's nothing to wait for.

In CricVerse, the scorer taps a run and the total moves in the same frame. In Lunara, the calendar is just there — no account, no fetch, no cloud. That immediacy is the whole point.

The trade-offs

Local-first isn't free. Conflict resolution gets real once two devices can edit the same thing offline, and you have to design for it deliberately rather than hoping a last-write-wins server sorts it out. But for the apps we build, that cost buys something users feel every single day — and that's a trade we'll take.