This is where I turned my vision into a buildable plan — writing the requirements, user stories, success metrics, and a prioritised roadmap.
A free mobile app (React Native/Expo) that tells sleep-training parents exactly how to dress their baby for the entire night, based on tonight's weather forecast and the child's age.
As a sleep-training parent, I face this dilemma every night: how do I dress my child for sleep when I won't enter the room again until morning? Room temperature fluctuates overnight (typically 2–5°C between 7pm and 3am), the dressing guidelines change depending on the child's age, and getting it wrong means either overheating (a SIDS risk factor) or a cold baby who wakes up and breaks weeks of sleep training.
Right now, parents like me check a weather app, Google a TOG chart, and try to do mental maths — all while managing a fussy baby at bedtime. The only dedicated product (Sleep Like Goldilocks) costs ~R700 and needs physical hardware. There's no free, digital, age-aware solution that recommends clothing for the entire night.
That's the gap I'm filling. Snug Tonight takes two inputs (child's age + room temperature or location) and instantly gives a specific, age-appropriate clothing recommendation based on the overnight temperature forecast and paediatric safety guidelines.
I needed to be clear about what I was building and what I was deliberately leaving out. Non-goals aren't failures — they're focus decisions. They tell engineers "don't build this yet" and show that I'm making intentional trade-offs.
I wrote each feature as a user story — the same format I use at work. Each one describes what the user wants and why, and the acceptance criteria define exactly when it's "done." These are what I'd hand to an engineer to build from.
This is the heart of Snug Tonight — the logic that maps room temperature + child's age to a specific outfit. I built this based on paediatric safety guidelines (Lullaby Trust, Red Nose, AAP), TOG rating standards, and established sleep consultant guidance.
| Room Temp | TOG | What Baby Wears | Safety Note |
|---|---|---|---|
| Below 16°C / 61°F | 3.5 TOG | Long-sleeve bodysuit + footed pajamas + 3.5 TOG swaddle | ⚠️ Room may be too cold. Consider heating. |
| 16–18°C / 61–64°F | 2.5 TOG | Long-sleeve bodysuit + 2.5 TOG swaddle | |
| 18–20°C / 64–68°F | 1.0 TOG | Long-sleeve bodysuit + 1.0 TOG swaddle | |
| 20–22°C / 68–72°F ✨ | 1.0 TOG | Short-sleeve bodysuit + 1.0 TOG swaddle | ✅ Ideal range |
| 22–24°C / 72–75°F | 0.5 TOG | Short-sleeve bodysuit + 0.5 TOG swaddle | |
| Above 24°C / 75°F | 0.2 TOG | Diaper only + 0.2 TOG swaddle (or just a muslin wrap) | ⚠️ Overheating risk. Use fan, no swaddle. |
| Room Temp | TOG | What Baby Wears | Safety Note |
|---|---|---|---|
| Below 16°C / 61°F | 3.5 TOG | Long-sleeve bodysuit + footed pajamas + 3.5 TOG sleep sack | ⚠️ Room too cold for baby. |
| 16–18°C / 61–64°F | 2.5 TOG | Long-sleeve bodysuit + 2.5 TOG sleep sack | |
| 18–20°C / 64–68°F | 1.0–2.5 TOG | Long-sleeve bodysuit + 1.0 TOG sleep sack | |
| 20–22°C / 68–72°F ✨ | 1.0 TOG | Short-sleeve bodysuit + 1.0 TOG sleep sack | ✅ Ideal range |
| 22–24°C / 72–75°F | 0.5 TOG | Short-sleeve bodysuit + 0.5 TOG sleep sack | |
| Above 24°C / 75°F | 0.2 TOG | Diaper + short-sleeve bodysuit only (no sleep sack) | ⚠️ Overheating risk. Cool the room. |
| Room Temp | TOG/Layer | What Baby Wears | Safety Note |
|---|---|---|---|
| Below 16°C / 61°F | 2.5 TOG or Blanket | Long-sleeve PJ top + PJ pants + 2.5 TOG sleep sack or warm PJs + light blanket | |
| 16–18°C / 61–64°F | 2.5 TOG | Long-sleeve PJ top + PJ pants + 2.5 TOG sleep sack or PJs + light blanket | |
| 18–20°C / 64–68°F | 1.0 TOG | Long-sleeve PJ top + PJ pants + 1.0 TOG sleep sack | |
| 20–22°C / 68–72°F ✨ | 1.0 TOG | Short-sleeve PJ top + PJ shorts + 1.0 TOG sleep sack or cotton PJs + light blanket | ✅ Ideal range |
| 22–24°C / 72–75°F | 0.5 TOG | Short-sleeve PJ top + PJ shorts + 0.5 TOG sleep sack or thin blanket | |
| Above 24°C / 75°F | Light | Short-sleeve PJ top + PJ shorts or just a bodysuit — no blanket | ⚠️ Keep room ventilated. |
I needed to define how I'd measure success — not just "does it work" but "are parents actually using it every night?" I set up four types of metrics: a primary metric (the one number that tells me the app is delivering value), input metrics (the things that drive that number), health metrics (things that should stay stable), and watch metrics (things I check to make sure I'm not causing problems).
I used RICE scoring to decide what to build first. RICE stands for Reach, Impact, Confidence, Effort — it gives each feature a score so I'm not just going with my gut. The formula is: Score = (Reach × Impact × Confidence) / Effort. Higher score = build it first.
| Feature | Priority | Reach | Impact | Confidence | Effort | RICE |
|---|---|---|---|---|---|---|
| Core temp → clothing engine | Must | 10 | 3 | 100% | 2 | 15.0 |
| Overnight forecast integration | Must | 10 | 3 | 90% | 3 | 9.0 |
| Morning sleep log (stars + outfit + wake-ups + notes) | Must | 8 | 3 | 95% | 2 | 11.4 |
| Digital wardrobe with categories & laundry tracking | Must | 8 | 2 | 95% | 2 | 7.6 |
| SVG outfit illustrations | Should | 8 | 2 | 85% | 3 | 4.5 |
| Pattern detection (e.g., runs warm) | Should | 6 | 2 | 80% | 2 | 4.8 |
| Dark mode with auto-toggle | Should | 8 | 2 | 95% | 1 | 15.2 |
Instead of a fixed timeline (which always breaks in reality), I organised my features into Now / Next / Later. "Now" is what I'm building in V1. "Next" is what I'm confident I'll build after launch. "Later" is ideas I'm exploring but haven't committed to yet.
| ID | Requirement | Priority |
|---|---|---|
| FR-01 | Accept child's age selection across 3 bands (0–3mo, 3–12mo, 12+mo) for recommendations | Must |
| FR-02 | Accept room temperature input via manual entry (slider + number) | Must |
| FR-03 | Support °C and °F with toggle | Must |
| FR-04 | Fetch overnight low temperature via weather API based on device location or city search | Must |
| FR-05 | Generate clothing recommendation based on temp + age using defined logic table | Must |
| FR-06 | Display safety badges (Cold/Ideal/Warm) for temperature appropriateness | Must |
| FR-07 | Morning log: star rating (1–5), outfit feedback (Too Cold/Just Right/Too Warm), wake-up counter, optional notes | Must |
| FR-08 | Digital wardrobe with 5 categories (Bodysuits, Sleepsuits, Sleep Bags & Suits, Swaddles & Layers, Sleep Layers) and laundry status tracking | Must |
| FR-09 | Show SVG illustration of recommended outfit layers | Should |
| FR-10 | Insights dashboard: avg sleep rating, % just right, avg wake-ups, pattern detection | Should |
| FR-11 | Auto-detect evening hours and switch to dark mode (6pm–7am) | Should |
| FR-12 | 5-step onboarding flow: Welcome, Location (skippable), Temp Unit, Baby Stage + Name, Wardrobe Setup. Ends with option to add another baby or get started. | Must |
| FR-13 | Support multiple child profiles (Free: 1, Premium: up to 10 child profiles) with per-child wardrobe and recommendations | Must |
| FR-14 | “Missing for Tonight” alert when recommended items aren’t in wardrobe, with substitute suggestions | Must |
| FR-15 | City search — type any city worldwide for weather data when location access is denied | Should |
| ID | Requirement | Target |
|---|---|---|
| NFR-01 | App launch time | <2 seconds on 4G mobile |
| NFR-02 | Time from open to first recommendation | <10 seconds (3 taps max) |
| NFR-03 | Platform | React Native (iOS / Android) |
| NFR-04 | Mobile responsiveness | Fully functional on screens 320px+ |
| NFR-05 | Accessibility | WCAG 2.1 AA compliance |
| NFR-06 | API uptime (weather) | 99.5% with graceful fallback to manual input |
| Risk / Assumption | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Weather API doesn't reflect actual room temp — Outside forecast ≠ nursery temperature | Medium | High | Always offer manual temp input as primary option. Position forecast as "context" not "truth." Encourage parents with thermometers to use manual input. |
| Parents may over-rely on the app — Following recommendations without checking baby | Medium | High | Include persistent disclaimer: "Always check your baby for signs of overheating or cold. This app provides guidance, not medical advice." Cite sources. |
| Morning log adoption is low — Parents forget to log feedback | Medium | Medium | Gentle reminders via app, optional notification (v1.5), simple 1-min flow, emphasise benefit ("patterns help recommendations"). |
| Weather API downtime — Free weather APIs can be unreliable | Low | Medium | Graceful fallback: if API fails, prompt user to enter temperature manually. Never show a broken state. |
This stage produced the core documents that define the product. Here's what I created and why each matters:
| What I Created | Why It Matters |
|---|---|
| PRD with Background | I wrote specs that an engineer could build from — clear enough that someone who's never seen the app could understand what to build |
| Goals & Non-Goals | I defined what's in scope and what's deliberately out — this shows I can say "no" to features and stay focused |
| User Stories + Acceptance Criteria | I described every feature from the user's perspective, with testable criteria so I know when it's done |
| Temperature → Clothing Logic | I defined the product logic at the data level — 3 age bands × 6 temperature ranges = specific outfit for every scenario |
| Primary Metric + Framework | I set up how I'll measure success, not just track usage — every metric connects back to "are parents actually using this?" |
| RICE Prioritisation | I ranked features using a scoring framework instead of gut feeling — this is how I decided what to build first |
| Now/Next/Later Roadmap | I communicated priority without locking myself into timelines that would break |
| Requirements (FR + NFR) | I wrote both what the app does and how well it needs to perform — bridging business needs and engineering specs |
| Risk Matrix | I thought about what could go wrong before it happened, and planned how I'd handle each scenario |