Offline-First Is a Feature: Building an App for Basements and Crawl Spaces
We ship a mobile app for contractors who write quotes on job sites. Job sites mean basements, crawl spaces, new construction with no wifi, rural properties with one bar of signal. The people using it have a customer standing next to them and thirty seconds of patience.
So we made a decision that sounds radical and is actually just old: everything lives on the phone. Local SQLite database. No backend. No account. No login screen. No sync spinner. The app works identically at 35,000 feet and in a poured-concrete basement, because it never needed the network in the first place.
What no-backend buys you
Latency is physics, not engineering. Every screen reads from a database that is microseconds away. There is no loading state to design because there is no loading. For a tool used mid-conversation with a customer, that's not polish — it's the product.
Privacy by architecture. Customer names, phone numbers, job prices — none of it touches our servers, because we don't have servers. Our privacy policy is short because the truthful answer to "what do you do with my data?" is "nothing; we never see it."
Operational surface area of zero. No auth outages, no database migrations at 2 a.m., no per-user hosting costs eating margin on a flat-priced product. A solo maintainer can sleep.
What it costs you
Honesty requires the other column. No backend means no cross-device sync — the phone is the source of truth, and losing the phone with no export means losing data, so export tooling isn't optional. It means schema migrations happen on the user's device: every database change ships as a versioned, transactional migration, appended and never edited, because you can't SSH into ten thousand phones and fix a bad one. And it means entitlements — trials, subscriptions — get validated against the platform's billing APIs with a local cache, rather than your own server.
None of these are dealbreakers. All of them are real engineering that the "just use a hosted backend" tutorial skips.
The release process is part of the architecture
Here's the part nobody warns you about: on mobile app stores, there is no rollback. Once a release is promoted to production, you cannot take it back — you can only halt the rollout and ship a forward fix with a new version number. Combine that with an offline-first app whose database migrations run on-device, and a bad release isn't an incident. It's a bell you can't unring.
Our process reflects that asymmetry:
- Merging never deploys. The default state of merged code is "not shipped." Releasing is a separate, deliberate act — a tagged version, built and uploaded as a draft that a human promotes after a final look.
- UI changes get verified on a real device before release, every time. Unit tests can't see a tab bar clipped by the system navigation or a save button hidden behind a keyboard. We learned this by shipping two hotfixes that a five-minute emulator flow would have prevented. That flow is now mandatory and scripted.
- Migrations are append-only and tested in integration, against real databases with real prior versions, because "works on a fresh install" tells you nothing about the ten thousand phones with last year's schema.
The bigger point
Offline-first gets framed as a compromise — the thing you grudgingly support for when connectivity fails. For field work, it's the opposite: the network is the edge case. Designing for the disconnected case first produced a faster, more private, cheaper-to-run product than the default architecture would have, and the constraint did most of the design work for us.
The best technical decisions usually come from taking one user reality — there is no wifi in a crawl space — completely seriously.