A clear place for daily routines
Ellumi is a pre-launch mobile companion for people managing their own medication, supplement, and everyday wellness routines. The product is designed to bring those routines into one clear daily view, with Ellie the Elephant providing a warm, consistent presence.
The first release is intentionally personal. It focuses on the routines someone enters for themselves, rather than caregiver sharing or dependent profiles. That boundary keeps the first product understandable while leaving room for future care relationships to be considered separately.
Start with what someone already follows
The core experience is organized around four simple places: Today, Routine, History, and You. A person can create a routine, choose fixed daily or weekday times, review the day ahead, record an occurrence, and correct the record later.
The product does not recommend treatment, calculate doses, infer clinical values, or provide medical advice. Medication amounts and instructions stay as user-entered information. That is both a product boundary and an engineering constraint: the system records a person's routine without pretending to decide what that routine should be.
Designed to be built, then tested in the real world
The storyboard established the interaction model before the native build. The implementation foundation uses React Native and Expo with TypeScript and Expo Router. Supabase provides the planned account and remote data layer, while Expo SQLite, SecureStore, and Expo Notifications cover local persistence, session credentials, and device reminders.
The important part is the relationship between those tools. A routine is not only a screen state. It has an owner, a schedule, a time zone, a version, local records, and a path to sync. Notifications are not only a button in the interface. They are a device capability with permissions, operating-system behavior, and acceptance checks that still need to happen on physical iOS and Android builds.
Engineering the boundaries
01 / Keep local work durable
Ellumi is designed to remain useful when the network is unavailable. The local data layer uses an encrypted SQLite path gated by SQLCipher feasibility, with SecureStore holding the account-specific key. A local write records the change and its outbox action atomically, so a routine or log action is not shown as complete while its retry path has disappeared.
The sync model uses stable operation identifiers and keeps pending work recoverable. When the remote service is available, Supabase is the source of truth for routine definitions, schedules, and log actions. When it is not, local state can remain visible and the pending operation can wait for a later foreground or reconnect cycle.
02 / Put ownership at the data boundary
The design uses Supabase Auth and Postgres with row-level security enforced in the database. User-owned tables use auth.uid() = user_id for read and write access, while composite constraints or checked functions protect relationships between routines, schedules, and occurrence logs.
That boundary matters because a mobile client can be modified. The app should not be the only place that decides whether a child record belongs to a user's routine. Sprint 1 verification records local migration, ownership-constraint, idempotent log-action, recurrence, and time-zone tests against disposable PostgreSQL data. Applying the same policies in a real Supabase project remains an acceptance step.
03 / Treat notifications as a device constraint
The app wraps Expo Notifications behind a typed service instead of depending on JavaScript timers in the background. The product model also treats reminder delivery as subject to device permissions and operating-system behavior. It does not promise guaranteed or emergency-grade alerts.
The verification protocol covers permission changes, lock-screen privacy, background and terminated states, reboot, force-stop, time-zone travel, daylight-saving transitions, and pending-request limits. The source project records the wrapper and protocol, but physical-device observations, signed development builds, and a configured Supabase project are still pending.
What is verified today
The current Ellumi work has a documented visual direction, a typed Expo foundation, automated tests, strict TypeScript checks, database migration and ownership tests, local persistence coverage, authentication flows, and notification setup work. The source project also records the limits of that evidence clearly.
This is not a released app yet. Real Supabase configuration, email redirects, signed iOS and Android development builds, physical-device notification checks, and the remaining release acceptance rows still need to be completed before the product can be treated as ready for public use.
A foundation that keeps the next decision visible
Ellumi's most useful engineering outcome so far is not a claim about scale or adoption. It is a foundation that keeps product boundaries visible: personal routines first, local work recoverable, ownership enforced where the data lives, and device behavior tested where it actually occurs.
The next step is evidence, not decoration: connect the approved service configuration, build on real devices, and replace these intentional visual slots with public screenshots or a reviewed conceptual diagram when those assets are safe to share.