Why Storkie exists
Storkie started the way most baby trackers probably should: with a newborn, a 3 a.m. feed, and a parent wondering why every app for this moment either looked like a hospital chart or paid for itself with the data inside it.
I’m Chris. I built Storkie to track my own baby’s days, and I kept building it because the alternative bothered me: the most tender record a family keeps, sold back to them as a subscription while it quietly trains someone else’s models. Storkie is my answer. Warm where the night is long, fast where your hands are full, and built so the record you keep belongs to you.
It is a one-parent operation, built in the open a little every week. You can see what is on the bench right now on the Building Storkie page, and the commitments the whole thing rests on in The Storkie Promise.
How Storkie is built
The short version, for the technically curious: Next.js and React on Vercel, Postgres on Supabase with row-level security per family, Clerk for sign-in, and AI through server-side tools. A few decisions worth explaining:
One source of truth, always in sync.
Storkie is online-first on purpose. Early prototypes explored offline-first sync engines, and every one of them traded away the thing that matters most in a two-parent night: both phones agreeing on what just happened. One database, row-level security per family, and live updates won.
AI on the server, consent at the front.
Ask Storkie and voice logging run through server-side tools that read your data only after you switch on Personalized answers, and only to answer the question you just asked. No always-on analysis, nothing baked into a model.
A promise we can keep, not encryption theater.
Storkie says "we won't" and means it, rather than claiming "we can't" and quietly breaking it the moment a feature needs to read your data. The trade-offs are written down in plain English on The Storkie Promise page.
Questions, ideas, or just want to say hi? hello@storkie.app reaches me directly.