Inspiration

My twins were born seven years ago, and there was no baby app built for parents of multiples. Every tracker I found assumed one baby, so I logged everything twice, by hand, exhausted, with no way to compare how my two were doing side by side. That gap stuck with me for years. Handsful is the app I needed then, built now for the parents living it today.

What it does

Handsful is a baby tracker built for twins, triplets, and more. One tap logs a feed, diaper, sleep, or note for every baby at once instead of repeating the same entry per child. Parents can compare each baby's patterns side by side, share real-time access with up to five caregivers, and use an opt-in AI feature to help prep for pediatrician visits.

How I built it

Handsful is a React Native (Expo) and TypeScript app on Firebase, with Cloud Firestore for data, Cloud Functions for server-side logic, and Firestore Security Rules enforcing family and caregiver boundaries. RevenueCat handles subscriptions, gating a 14-day free trial and a $6.99/month or $59.99/year plan. I built it solo: nights and weekends around a full-time role, handling design, implementation, testing, and release myself, from the App Store and Play Store listing down to individual Firestore rules.

Challenges I ran into

Multi-caregiver support meant the family data model couldn't be single-owner; every family, entitlement, and log needed rules that treated caregivers as equally trusted but still bounded. Closing that properly took two passes: a client-side cap on caregiver invites first, then a second look that found the real gap. Firestore rules had two unbounded paths, an existing member could rewrite the caregiver list to any size, and a raw document create could seed more caregivers than the cap allowed from the start. The fix was a single rule that bounds growth rather than absolute size, so it can never brick a family that's already at or over the cap for legitimate reasons like a pending removal.

The scarier one showed up during v1.0.2 pre-launch testing: a real purchase went through on Apple's side, but the app kept showing "trial" instead of unlocking premium. The purchase had succeeded, but Firestore had no record of it at all, not stale data, nothing. Tracing it meant two dead ends before the real one, a mistaken function name that made the logs look empty, then log entries that showed the webhook firing correctly but being rejected every time. It came down to an Authorization header that didn't match the secret Firebase was expecting, a mismatch that had been silently failing since the very first deploy, weeks earlier, with nobody having exercised a real purchase against it until that test. Fixing it meant re-syncing the secret between RevenueCat and Firebase; the deeper lesson was that testing entitlement by hand-editing Firestore proves the app reads state correctly, it proves nothing about whether a real purchase can reach that state at all. That's now a standing check before any release touching payments.

What I learned

Building for multiples means every assumption baked into "normal" baby apps, one baby, one primary caregiver, has to be rebuilt. Security and trust between caregivers isn't a feature to bolt on, it has to be part of the data model from the start. And the parts of a payment system that never get exercised in testing are exactly the parts that will fail silently in production.

What's next

v1.0.4 is already in planning: consolidating the app's quick-action logging into fewer, smarter categories so tracking stays fast even as the feature set grows. Beyond that, I'm exploring ways to make logging even lower-friction for caregivers, like a home screen widget or lock screen notification so a feed or diaper change can be logged without even opening the app.

Built With

Share this project:

Updates

Submission history