I built Snug Tonight from concept to working product, then ran 5 QA review cycles to harden it for App Store submission. Here's how I made the technical decisions, designed the architecture, and shipped a production-ready app.
I built Snug Tonight V1 using AI-assisted development — I owned the product vision, the UX, the architectural decisions, and the quality bar; I used AI as a code-writing collaborator I could direct, review, and iterate with. This let me focus on what I do best as a PM: defining the experience, making trade-offs, reviewing every output critically, and pushing the product to the standard I wanted. The result is a React Native app built with Expo — a deliberate choice for a mobile-first experience that works on iOS and iPadOS. Download from the App Store, complete the 5-step onboarding, and you're dressing your child in under 60 seconds.
| Technology | React Native app built with Expo SDK 54, Expo Router, and TypeScript with 4-tab navigation (Tonight, Morning, Wardrobe, Settings), SVG illustrations, multi-child state management |
| Styling | React Native StyleSheet with custom theming system (custom color palette for dark/light modes) |
| Weather API | Open-Meteo (free, no API key, CORS-friendly, global coverage) |
| Geocoding | Device Geolocation API (iOS/Android native) + Open-Meteo Geocoding Search |
| Backend & Auth | Supabase (PostgreSQL + Auth) with Apple and Google SSO, cloud sync for cross-device data |
| State Management | React Context with multi-child state, AsyncStorage for local persistence, Supabase for cloud sync |
| Clothing Illustrations | SVG illustrations code-drawn, color-coded by warmth level |
| Data Persistence | AsyncStorage for local cache + Supabase cloud sync for cross-device access |
| Hosting Target | App Store via Expo EAS Build (iOS / iPadOS) |
| Build Approach | AI-assisted development — I owned the product vision, UX decisions, architecture, and quality bar; AI wrote the code under my direction and review |
| Build Cadence | Initial scaffold sprint, then five QA review cycles to harden the app for App Store submission (privacy manifest, RLS policies, sign-out race conditions, error boundaries) |
Every architectural choice I made was guided by one question: "What gets a working, beautiful product to sleep-training parents fastest?" Using AI-assisted development, I didn’t need to be an expert in React Native — I needed to be an expert in the product. I made the technical decisions, the AI wrote the code, and I tested and iterated until it was right.
I chose: A mobile app, not iOS/Android native code.
Why: Instantly accessible. Works cross-platform with Expo. Works on all devices. South African users with Android phones (70%+ market share) get access immediately.
Trade-off: Expo’s managed workflow means some native features need workarounds, but push notifications work via Expo Notifications and the ecosystem covers all V1 needs.
I chose: Organized, reusable code with Expo Router for navigation.
Why: Clean components with shared design, organized file structure, and TypeScript to catch errors early.
Trade-off: Already organized — easy to add V2 features.
I chose: Open-Meteo for weather data.
Why: Completely free. No API key needed. Works globally, including South Africa. Gives hourly forecasts so I can find tonight's coldest point. No limits for V1 scale.
Trade-off: I can't measure indoor room temperature yet (that comes in V2).
I chose: Built-in dark/light mode with automatic switching.
Why: Parents use the app at bedtime (dark screen) and morning (light). It switches automatically at 18:00. The deep purple/indigo palette feels warm and calming.
Trade-off: Keeps the code simple for V1 without heavy styling libraries.
I chose: Each child gets their own data — wardrobe and history stored separately.
Why: Many parents manage multiple children. Each one needs: name, age band, avatar, clothing items (with warmth ratings), and a history of how each night went.
Trade-off: Free tier supports 1 child; Premium unlocks up to 10 child profiles. Data syncs to cloud via Supabase for signed-in users, with local AsyncStorage as offline fallback.
I built a recommendation engine that maps temperature and child's age to a specific outfit. It uses a lookup-based approach — simple, predictable, and based on established paediatric sleep safety guidelines. The engine also incorporates a feedback learning system that adjusts recommendations based on how parents rate the previous night's outcome.
The engine takes two inputs — tonight's temperature and the child's age band — and produces a complete outfit recommendation including garment type, layering order, and safety guidance. It covers multiple age bands and temperature ranges to handle everything from hot summer nights to cold winter conditions.
Here's what I shipped for V1, mapped to every PRD requirement:
| Screen | Purpose | Key Elements |
|---|---|---|
| Onboarding One-time (5 steps) |
Parent profile creation and first-time setup | Welcome, enable location (optional), temperature unit (°C/°F), child's age band + name, wardrobe items |
| Tonight Tab Daily Evening |
Tonight's temperature + get recommendation | Baby selector, weather forecast (temp, condition, high/low, overnight low 12AM–6AM), hourly forecast, manual slider (10°–35°C), auto-loaded recommendation with outfit and layers, evening tip, safety badge |
| Morning Tab Daily Morning |
Sleep quality log & feedback loop | Sleep quality (1–5 stars), outfit feedback (🥶 Too cold / ✅ Just right / 🥵 Too warm), night wake-ups counter, notes field, 7-night history, pattern insights |
| Wardrobe Tab Baby management |
Manage saved clothing items | Missing for tonight alerts, categories (Bodysuits, Sleepsuits, Sleep Bags & Suits, Swaddles & Layers, Sleep Layers), laundry tracking (Clean/Laundry status), warmth labels, substitute suggestions |
| Settings Tab Preferences |
App settings and account | Apple/Google sign-in, °C/°F toggle, notification preferences, child profile management, premium subscription, Privacy Policy, Terms of Service, account management |
I initially built V1 for speed and validation, deferring several features. Through 5 QA review cycles, I resolved the most critical ones before App Store submission:
| Original Limitation | Status | What I Did |
|---|---|---|
| Device-only persistence Data only saved on device |
Resolved | Added Supabase cloud sync — child profiles, wardrobe, and history sync across devices with offline-first fallback |
| No user accounts Couldn't sync across devices |
Resolved | Added Apple Sign-In and Google Sign-In via Supabase Auth with secure session management |
| No push notifications Parents had to remember to open the app |
Resolved | Added bedtime reminders and morning feedback prompts via Expo Notifications |
| Static recommendation logic Same rules for all users |
Resolved | Added feedback learning system — recommendations adjust per-child based on parent feedback history |
| No monetisation No way to generate revenue |
Resolved | Added RevenueCat-powered in-app subscriptions with freemium model |
| Photorealistic illustrations Code-drawn SVG garments |
Future | SVG illustrations work well for V1. Higher-fidelity visuals planned for a future update. |
As the PM, I didn't write the code — but I was deeply involved in building this product. Here's what I actually did during development:
| What I Did | How I Did It | Why It Matters |
|---|---|---|
| I wrote clear requirements | I created a PRD with 18 unique recommendation mappings, detailed user stories, acceptance criteria, and wireframes | The engineer could build without asking what I meant. That saved so much back-and-forth. |
| I managed scope ruthlessly | I prioritised features by impact: core recommendation first, then cloud sync and accounts, then engagement features like streaks and sharing | I kept the build focused on what matters most, while protecting my revenue model. Iterating through 5 review cycles added features in the right order. |
| I checked the design quality | I made sure all 4 screens felt warm, calm, and worked well on mobile phones | Parents notice whether a product feels caring or rushed. That feeling matters to retention. |
| I tested edge cases | I made sure the app didn't break: no location? → manual input. No weather data? → use the slider. Extreme temperatures? → show warnings. | Real parents will break anything that doesn't handle the unexpected. These details build trust. |
| I tested every feature | I checked each feature against the acceptance criteria I wrote in Stage 3 | I own the definition of "done." If it doesn't meet what I promised, it doesn't ship. |
| I documented the shortcuts I took | I wrote down everything I deferred to V2, ranked by urgency, with solutions planned | This prevents surprises later and shows I understand the trade-offs between speed and perfection. |