Why I built a baby tracker after a week of trying every other one

Kisho — Wed, 20 May 2026 20:31:57 +0000

The honest origin story isn't "I saw a gap in the market." It's that my twins were born a few weeks early, premature babies need closer feeding tracking than full-term ones, and after a week of trying every baby tracker on the App Store, my partner and I went back to a paper notebook.

The notebook was terrible. I lost it. The handwriting at 4am was unreadable. One of the babies peed on it. But the cognitive load of using it was still lower than any of the apps we'd tried — apps that wanted us to finish a 7-step onboarding before logging a single feed, or open three nested dropdowns to record a wet diaper.

So I built PooPeeMilk. One rule: logging an event takes one tap and zero thought. iOS now, Android next. This post is the technical write-up — what's in the stack, why each piece is there, and what I'd change.

What it actually does

Logs the four things new parents care about — feeds (breast or formula, with volume), diapers (wet or dirty), weights, and milestones with photos. From those logs it generates a 24-hour "rhythm ribbon" pattern view and a pediatrician-ready PDF for appointments.

Core logging is free. Multi-baby support, shared caregivers, milestone photos, and PDF export sit behind a subscription.

The stack

Three packages in one workspace:

Mobile: Expo + React Native (new architecture enabled)
Backend: Next.js App Router on Railway
Database: Postgres via Prisma
Photo storage: Cloudflare R2
Marketing site: separate Next.js app, also on Railway
Auth: passwordless email codes (Resend + JWT)
Payments: RevenueCat
Translations: GPT-4o-mini at build time

The interesting bits aren't the choices themselves — most of them are unsurprising for a 2025 indie stack — but why each one over the obvious alternative.

Expo vs bare React Native

I spent about a day debating this and then realised it wasn't actually a debate. I'm one person. EAS Build, Expo Modules (image manipulation, file system, sharing, localisation, push), and OTA updates are not things I want to wire up by hand. The new architecture closes the perf gap for an app of this complexity.

The free tier alone — 15 builds/month and OTA updates to 1,000 MAUs — comfortably covers where I am, and the upgrade path is fine once usage grows.

Passwordless email codes for auth

I considered the usual menu: Apple/Google sign-in, magic links, passwords. The audience decided it:

Sleep-deprived parents on a single device will not remember a password
Caregiver invites (partner, grandparent) need to work straight from an email

The flow is standard. Client POSTs an email; backend stores a hashed code with a TTL and ships it via Resend; client confirms the code; backend returns a JWT used as a bearer token from then on. Middleware verifies it on every request. Rate-limited, obviously.

Magic links would also have worked, but on mobile they involve universal links and the occasional "open in browser" failure mode. Six-digit codes just work everywhere.

Photo uploads: presigned R2 URLs

Naive version: POST image bytes to the backend, backend proxies to object storage. That burns server memory, adds latency, and makes you pay egress twice. So the client requests a presigned URL, uploads directly to R2, then tells the backend "the photo is at this key."

R2 over S3 specifically because egress is free. Parents will eventually want to pull their photos back out for a memory book — paying outbound bandwidth on every export would have been painful.

RevenueCat over rolling my own

Two SDKs (StoreKit, Play Billing), two webhook formats, two sets of edge cases (refunds, family sharing, grace periods, billing retries, restore flows) — the cost of doing it yourself is high and the failure modes are silent until a user emails you saying "I paid and the app doesn't think so."

RevenueCat is also genuinely indie-friendly on pricing — free until you cross a monthly tracked revenue threshold. As a solo dev who hasn't validated the market, "free until you have revenue" is the whole pitch.

Railway for hosting

Backend, marketing site, and Postgres all live there. I've used Heroku for years and did a stretch on Vercel + a separate managed Postgres. Railway is the first host where the app, the database, the env vars, the logs, and the deploys feel like one product instead of four services you've duct-taped together. For a solo project where every context-switch costs, that integration is worth more than any individual feature.

Things I'd change

Write tests sooner. Not more tests. Not 100% coverage. Just sooner. Moving fast as a solo dev means the regressions you ship are in the code paths you weren't thinking about that week. Four or five end-to-end tests on the critical flows — sign in, log an event, see it appear, hit the paywall — would have caught at least three TestFlight bugs.

Think harder about the data shape before the schema. My Event table is union-shaped — feeds, wet diapers, and dirty diapers all live in one table with optional columns. Fine for the write path, awkward for stats queries. A polymorphic schema would have been cleaner, but I'd only have known that after writing the stats queries. Maybe the lesson is: write the hardest read query first, then design the table.

What's next

Android is the big one. iOS-only right now because that's what my partner and I had, and shipping to one platform end-to-end is faster than trying to do two at once. But Android is the bigger global share — especially in the regions where the marketing site is getting traffic — and because it's Expo, the lift is small.

If you're building in the parenting space (or just curious about the code decisions), the app is on the App Store. Happy to nerd out about any of this in the comments.

DEV Community: Kisho