Apps people actually keep installed.
Native-grade mobile apps for products that have to work on a three-year-old phone, on hotel Wi-Fi, in an airport with one bar. Offline-aware, fast, and wired into the same backend as the web — so you ship one product, not two that drift apart.
The network is the hard part.
A mobile app lives where the connection doesn't. The interesting engineering isn't the screens — it's what the app does in the elevator, on the plane, on the third bar of signal. We design for the offline case first; the online case is the easy one.
An engagement starts with the real device and the real network: which phones your users actually carry, where they use the app, what has to work without signal. We come back with an architecture — usually one shared API with the web, a sync model, and a release plan that respects the App Store's patience.
We hand over a codebase that doesn't rot between store reviews: typed, tested, with CI that builds both platforms and a release process your team can run. Or we stay on for the long tail of OS updates. Both are fine.
Devices, architecture, build, store.
Four phases that start on a real phone and end in a store, not the other way around.
Devices
The phones and networks your users actually have, the moments they actually use the app, and the offline cases that have to hold. Evidence, not assumptions.
Architecture
One API shared with the web, a sync and conflict model, navigation and state. The diagram is boring on purpose; the elevator case is designed, not discovered.
Build
Native-grade UI, real device testing, performance budgeted on the slow phone. Crash reporting and analytics in from the first build, not bolted on at the end.
Store
Submission, phased rollout, and a process your team can run for the next OS update. The release is part of the product, not an afterthought.
What we actually do.
The parts of mobile that decide whether the app stays on the home screen.
Cross-platform & native
React Native by default for one team and one codebase; native modules or full Swift / Kotlin when the product genuinely needs it.
Offline-first & sync
Local-first data, conflict resolution, and a sync model that survives a bad connection without losing the user's work.
Performance on real phones
Startup time, jank and battery measured on the cheap device, not the flagship. Budgets enforced in CI.
Shared backend
One API powering web and mobile so the two products don't quietly diverge. Push, deep links and auth done once.
Release engineering
Reproducible builds, phased rollouts, over-the-air updates where the stores allow, and a calm submission process.
App stores & compliance
Review guidelines, privacy nutrition labels, permissions and the paperwork that keeps the app from being pulled.
Tools we keep returning to.
One codebase where it pays, native where it counts. The store is not the place to be surprised.
Swift · Kotlin
TanStack Query
Push · Auth
Sentry · CodePush
Recent mobile builds.
Most of it lives behind a store login. These are the ones we can describe.
Guest app that worked offline
A resort guest app that holds itinerary, room key and messaging without signal. Daily active use 3× the old web wrapper it replaced.
Housekeeping, in hand
An offline-first ops app for housekeeping teams on weak property Wi-Fi. Tasks sync cleanly; zero lost updates across a year in production.
One API, two clients
Rebuilt a mobile client on the same GraphQL API as the web. Feature parity stopped drifting; release cadence halved.
Fast on the cheap phone
Cut cold start from 4.6s to 1.2s on the low-end device the field actually uses. Crash-free sessions above 99.7%.
Related services.
A mobile app rarely arrives alone. These usually come with it.
Got an app idea
that has to work offline?
Tell us a little about who carries it and where. We reply within two working days, in plain language, with an honest read on whether we're the right team.