WaterTracker, Easy Fasting, Gym Tracker, BreathHold Coach, the four Legi & Amenzi reference apps, BacIstorie, BacGeografie — none of them talk to a server we run. No API, no database, no hosting bill, nothing to page us at 2am. Everything lives on the device, backed up through Apple's own iCloud. That's not a limitation we work around; for the kind of apps we build, it's the default we start from and only abandon on purpose.
What "no backend" actually buys you
It's not just cheaper — though a studio running nineteen apps with zero server infrastructure is a real cost advantage. It's that an entire category of failure disappears. There's no outage that takes an app offline for users who already downloaded it. No API version to keep backward-compatible for people still on last year's build. No database migration that has to run flawlessly against production data at 2am before a release. The app either works on the device or it doesn't, and that's a much smaller surface to get right.
App Review moves faster when there's nothing to review but the binary
A reviewer testing a no-backend app can't hit a staging bug, a rate limit, or a login flow that depends on our infrastructure being healthy at the exact minute they're testing. What they see is exactly what every user sees, every time. It also simplifies the privacy side of submission — when nothing leaves the device, the App Privacy nutrition label is short and genuinely accurate, not a best-effort summary of a data pipeline we'd have to audit before every release. Fewer places for the label to drift from the code.
Local-first doesn't mean single-device
The trade-off people usually assume — no server means no sync — isn't actually true anymore. Gym Tracker's workout history and My Mustang's maintenance log both sync across a user's devices through CloudKit, which rides on the user's own iCloud account instead of infrastructure we'd have to run. It gives us real multi-device sync, encrypted in transit and at rest, without a single line of server code and without ever seeing the data ourselves. That last part isn't a minor detail — it's the actual privacy story, and it holds up because it's structural, not a policy we promise to follow.
Where the pattern actually breaks down
We reach for a real backend when the product genuinely needs one thing CloudKit can't give it: data shared between different users, not just synced across one user's own devices — a leaderboard, a shared roster, anything with a server-side source of truth that has to reconcile conflicting writes from strangers. None of our current portfolio needs that, which is itself a product decision, not an accident — we've generally scoped ideas away from that requirement rather than take on the operational load it brings. If a client project genuinely needs it, we build it properly; we just don't default to it because a roadmap template says apps need a cloud.
The real cost isn't engineering time, it's product scope
Skipping a backend doesn't save much implementation time on a v1 — CloudKit sync has its own learning curve. What it actually protects is everything downstream: the on-call burden, the deprecation timeline for an old API version, the security surface of a server that has to keep running for years after the app that made money is a rounding error. For a studio shipping many small, independent apps instead of one large one, that ongoing cost multiplies by app count in a way that's easy to underestimate at launch and expensive to discover later.
"No backend" isn't a rule we follow blindly — it's a default we make a client re-earn out of, by pointing at a specific requirement a local-first architecture actually can't meet. Most of the time, for the apps we build, that requirement never shows up.