Most health apps start with a backend. Auth service, Postgres, REST API, push notification server, analytics pipeline, the works. Then they figure out what the app should actually do.
Regimio went the other way. We started from a constraint: no server stores user data in v0. Everything runs on-device. The backend can come in v1 if and only if it's needed for a feature.
Here's the architecture, the trade-offs, and what we'd change.
The stack at v0
- Expo SDK 54 with Expo Router v4
- TypeScript strict
- Zustand (state)
- AsyncStorage-backed local persistence
- react-native-svg (charts and body map)
- expo-notifications (local notifications only · no APNs/FCM)
- Health integrations (planned after MVP)
- Sentry (opt-in only, scrubbed of values)
- RevenueCat (subscription entitlement state)
Total backend infrastructure: zero.
Total monthly server cost for free-tier users: zero.
Why app-local state first
The MVP has one rule: the daily tracking loop must work without an account and without a Regimio server. The current implementation keeps the stack, schedule, dose logs, check-ins, labs, weight, body measurements, settings, and access state in app-local storage.
That gives us:
- Fast first launch and fast logging
- No server-side user-data database to operate
- One local state model that is easy to reset during testing
- A simple erase flow that clears local Regimio app data
The Zustand split
The app uses focused Zustand state slices, deliberately kept small:
useStore // compounds, protocols, vials, logs, metrics, labs, settings
access helpers // free, trial, and Pro feature access
math helpers // reconstitution, schedule, and formatting
The app hydrates local state on launch and writes user changes back to app-local storage. State in memory, local persistence on device.
We considered a single global store with selectors. Splitting was the right call because:
- Each store has a single responsibility and a clear ownership boundary
- Re-renders are scoped · touching
logDose()doesn't re-render score components - Testing is straightforward · pass a mock store to a screen, assert the output
State persistence
The pattern looks like this:
const useStackStore = create<StackState>()(
persist(
(set, get) => ({
compounds: [],
addCompound: (input) => set((state) => ({
compounds: [...state.compounds, normalizeCompound(input)],
})),
// ...
}),
{
name: "regimio-stack",
storage: createJSONStorage(() => AsyncStorage),
// App-local storage is the persistence layer for MVP.
}
)
);
This is what makes Regimio's home screen feel instant. There is no server round-trip to show today's stack, missed-dose state, vial math, or check-in history.
Why no backend for v0
Three reasons:
1. The product doesn't need one. Regimio's daily loop is: open app → see today's stack → log a dose → see the next dose. None of that requires a server. The state lives on your device because that's where it's used.
2. Privacy is a precondition. A server with user data is a server with breach exposure. A server with no user data is just an app that happens to charge for in-app purchases.
3. Operations cost. Free-tier users are 95% of our user base in early days. If every free user costs $0.001/month in compute, that's $100/month at 100,000 users. Multiply by signup growth, lambda cold starts, and 24/7 monitoring · suddenly there's a server team. We don't need one yet.
Where backend is being deferred · and what it'll add
v1 will add:
- Native subscription validation through Apple, Google, and RevenueCat.
- More explicit backup/export controls for users who want to move data between devices manually.
- Multi-device sync research only after the MVP privacy model and store disclosures are updated.
v2 may add:
- Lab PDF import (Pro roadmap) · only after the beta app is stable and the privacy model is explicit.
- Anonymized aggregate insights ("among 1,200 users on a similar Tirz ladder, the median plateau started week 12") · strictly aggregate, never traceable to a user.
v3+ would add:
- Multi-user / caregiver mode (read-only delegate)
- Real-time wearable streaming from third-party APIs
Even in v3, the user's data never leaves their device unless they explicitly enable a feature that needs it. The default position is local-first, forever.
What we'd change
Three honest critiques:
1. App-local migrations still need discipline. Local state is easier than a server, but schema changes still need careful migration, test fixtures, and erase/export paths.
2. Local persistence means device responsibility. If a user deletes the app without exporting, the local data goes with it. That is the honest trade-off of a no-account MVP.
3. Local notifications on Android are 95% reliable. Not 99%. The Android lifecycle has more aggressive battery optimizations that occasionally delay or drop a scheduled notification. We've added a fallback that re-schedules on app open if the missed-window check sees a gap. iOS has been bulletproof.
Why this is the right architecture for this product
Regimio's user is sensitive to:
- Privacy (private protocols, sensitive health values)
- Speed (logging beats Excel only if it's instant)
- Reliability (notifications must fire)
- Cost (free tier must be sustainable)
A local-first architecture optimizes every one of those. A backend would compromise privacy, add network-latency to logging, add a remote-push reliability concern, and create per-user infrastructure costs.
The trade-off: we can't run server-side analytics on user behavior, we can't push remote feature flags as cheaply, and we can't easily orchestrate features that span multiple devices yet. We're fine with all three for MVP.
The constraint as feature
The whole privacy posture of Regimio · "your data stays on your device" · only reads as credible because the architecture backs it up. If we had a Postgres database storing user doses, the marketing line would be empty. With app-local storage and no Regimio cloud database, the marketing line is the architecture diagram.
Architecture is the product, for the people who care about this.
The privacy posture walks through what that looks like for users. The security page covers the threat model and engineering practices.