PWA Prototype Specification · April 2026

Behavioral validation with real mothers + investor demo asset — built in 2 days, not 2 months.

Objective A — Behavioral
Validate before you build
Put a real, clickable product in the hands of 5–10 real mothers before investing further in the native build. Observe actual behavior, not stated preferences.
Objective B — Investor
A URL, not a Figma file
Give LesleyAnn a shareable URL that investors can open on their phone and experience the product firsthand — during the pitch call.
01

Why a PWA, Not a Figma Prototype

Static prototypes hide friction. Real interaction reveals it.

A PWA opens in any browser — no App Store, no TestFlight, no install friction. You share a URL. Real interaction (tap, scroll, type) reveals friction that static prototypes cannot. Mothers can use it on their actual phone in actual daily contexts: car pickup line, kitchen counter, bedtime routine.

The behavioral cold start problem — whether a mother will form the daily update habit before the system proves its value — cannot be answered by a survey or a Figma prototype. Only real interaction with a real product reveals whether this loop closes.

The aha moment hypothesis is that it occurs when a caregiver logs an update (dose administered, child picked up, symptom noted) and the mother receives the notification in real time without asking. That moment cannot be simulated in a slide deck. The prototype must make it experienceable — even with mock data.

For investors: the difference between "showing" and "experiencing" is significant. A live URL on their phone during a pitch call removes the imagination gap entirely.

02

Recommended Tooling

Three options, ordered by speed-to-URL. Choose based on whether the prototype will be evolved or replaced.

Lovable
lovable.dev
  • Describe screens in plain English; generates React + Tailwind in real time
  • Built-in Supabase — basic persistence without writing backend code
  • Exports clean React code → maps to the Next.js web workspace
  • One-click deploy to Lovable hosting or Vercel/Netlify
~1-2 weeks build
v0 by Vercel
v0.dev
  • Generates shadcn/ui + Tailwind from natural language
  • Best for individual component generation; more manual assembly
  • Output drops directly into the web/ workspace
~2–3 weeks build
Cursor + Next.js
cursor.com
  • Full control; AI autocompletes inside the actual monorepo
  • Produces production-quality code from day one
  • Choose this if the prototype evolves into the live web app — zero rewrite needed
~2-3 weeks build + $$ cost
Decision guidance: Use Lovable for the fastest path to a shareable URL. Use Cursor + Next.js (Option C) if you want the prototype to evolve directly into the production web app — this is the code-efficient choice given the existing Next.js monorepo, and avoids a rewrite entirely.
03

Screen Inventory

8 screen groups, ~15–20 individual states. All data is live — no backend wiring required. Balloon colors: Teal = Calendar, Lavender = Health, Pink = Household.

01
Onboarding & Household Setup
✦ Cross-cutting

A 3-step wizard that captures the household profile: primary caregiver name, household name, number of children, and one invited caregiver. The first impression — sets the mental model for the entire app.

Mock Screens Include
  • Welcome screen with MomDom balloon logo and value proposition line
  • Household profile form (name, children, primary caregiver)
  • Invite a caregiver — enter name + role (co-parent, babysitter, grandparent)
  • Completion: Dashboard reveal animation
Validates
  • Does the 3-balloon metaphor land in under 10 seconds without explanation?
  • Does onboarding feel approachable or overwhelming?
  • Is "invite a caregiver" understood as multiplayer, not just contact-sharing?
02
Main Dashboard — The Three Balloons
✦ Cross-cutting

Home screen. Three balloon icons dominate the viewport. A "Today at a glance" strip shows the next 3 items. A notification badge on Health shows a pending dose reminder.

Mock Screens Include
  • Dashboard default state — all balloons, today summary strip
  • Dashboard: "Sick Day Mode" active — Calendar suppresses low-priority tasks, Health highlighted
  • Dashboard: caregiver sync indicator — shows last update time from invited caregiver
Validates
  • Do mothers tap a specific balloon first, or the summary strip? (navigation instinct)
  • Does "Sick Day Mode" feel magical or confusing on first encounter?
  • Is the caregiver sync indicator reassuring or noisy?
03
Calendar & Scheduling
🎈 Calendar Balloon

The teal balloon. Weekly view with color-coded events by child. A recurring task wizard allows setting "Soccer practice every Tuesday" with one interaction.

Mock Screens Include
  • Weekly calendar view with 2 mock children's events
  • Add event sheet: title, child, time, recurring toggle, caregiver visibility toggle
  • Recurring task confirmation card: "I'll remind you every Tuesday at 3:45 PM — confirm?"
  • Caregiver view: same calendar, read-only, edit permissions hidden
Validates
  • Is the recurring task setup faster than a standard calendar app?
  • Does the caregiver visibility toggle feel like safety or friction?
  • Does the confirmation card ("I'll remind you…") feel trustworthy?
04
Health & Care
🎈 Health Balloon

The lavender balloon. Per-child health profile: allergies, medications, EpiPen location, and recent health events. Logging a fever triggers Sick Day Mode.

Mock Screens Include
  • Child health profile: Emma, age 7 — peanut allergy, EpiPen in red bag in kitchen
  • Log symptom sheet: select child, type, severity, notes, timestamp
  • "Sick Day Mode activated" confirmation card after logging fever
  • Caregiver view: read-only — allergy and EpiPen info prominently shown
  • Dose log: "Caregiver logged: Ibuprofen 200mg at 2:15 PM — Mom notified"
Validates
  • Does seeing the caregiver's real-time dose log create immediate "aha" for the multiplayer model?
  • Is the EpiPen location visible enough that a babysitter would find it in an emergency?
  • Does Sick Day Mode feel like the system is helping, not just recording?
05
Household & Inventory
🎈 Household Balloon

The pink balloon. Inventory organized by category with quantity and reorder thresholds. Low-stock items auto-populate the shopping list. "+Add to Cart" deep link placeholder.

Mock Screens Include
  • Inventory list: pantry items with quantity indicators (red = low stock)
  • Add item sheet: name, category, quantity, reorder threshold
  • Shopping list view: auto-generated list of low-stock items
  • "+Add to Cart" placeholder button on each shopping list item
Validates
  • Is the reorder threshold concept intuitive without instruction?
  • Does the auto-generated shopping list save a meaningful mental step?
  • Is "+Add to Cart" enough value that mothers would maintain inventory data to get it?
06
Caregiver Sharing & Permissions
✦ Cross-cutting

The multiplayer model made tangible. Mom sets granular permissions per invited caregiver. A babysitter sees a limited view; a co-parent sees everything. This screen is the prototype's most important differentiator.

Mock Screens Include
  • Permission management: list of invited caregivers with role badges
  • Edit permission sheet: toggle visibility per balloon (Calendar / Health / Household)
  • Babysitter view simulation: "Preview as Babysitter" restricted dashboard
  • Notification: "Grandma just logged: Kids arrived safely at 3:22 PM"
Validates
  • Does the permission model feel empowering or intimidating to configure?
  • Does "Preview as Babysitter" build trust in the system?
  • Is the caregiver activity notification reassuring or overwhelming in volume?
07
Confirmation Card Pattern
✦ Cross-cutting

A dedicated demo of the "propose, never assume" design philosophy. Three examples: a routine suggestion, a reminder, and a Sick Day Mode override. The system proposes — Mom approves.

Mock Screens Include
  • Routine suggestion: "I noticed bath time happens around 7 PM on school nights — want me to remind you? [Confirm] [Dismiss]"
  • Reminder: "Soccer practice in 45 minutes — Emma's gear is in the hall closet [Got it]"
  • Sick Day override: "Emma has a fever. I've paused low-priority tasks and reminded the babysitter about the thermometer location. [OK]"
Validates
  • Does "propose, never assume" feel collaborative or patronizing?
  • Is a dismissed routine suggestion permanent enough that mothers trust it won't resurface?
  • Does the Sick Day override card feel like it does meaningful work?
08
Settings & Household Profile
✦ Cross-cutting

Account settings, notification preferences, and a data export placeholder. Minimal but present — investors and testers will look for it.

Mock Screens Include
  • Settings: household name, subscription tier (placeholder), notification toggles
  • Data export placeholder: "Export your household data" (grayed out — MVP+1)
  • About / Help screen with contact info
Validates
  • Do mothers look for a data export option? (signals data ownership concerns)
  • Are notification preferences the first thing they adjust?
04

Mock Data — The Vega Family

Parallel to the real-world scenario, this is a complete, named household that makes the prototype feel lived-in on first tap rather than empty and hypothetical.

The Alpha Cohort users (5-10 inner circle testers) will use their personal households to interact with the prototype. Their real-world experiences will inform the validation process, and each household's data will be migrated to the production database prior to the pilot (beta) release.

All data is database-type tested and consistent with the application standards. No backend to support, and no authentication required for use as a demo of the prototype. Use a single family consistently across all screens so the experience feels cohesive.

FieldValue
HouseholdThe Vega Family
Primary CaregiverSofia Vega
Child 1Emma, age 7 — peanut allergy, soccer on Tuesdays at 4 PM
Child 2Lucas, age 4 — no known allergies, preschool Monday–Friday
Caregiver 1Grandma Rosa — Calendar: read, Health: read, Household: hidden
Caregiver 2Babysitter Jess — Health: read only (allergies + EpiPen visible)
Upcoming EventsEmma: Soccer Tuesday 4 PM · Lucas: Preschool show Thursday 10 AM
Health EventsEmma logged: low-grade fever (99.1°F) this morning → Sick Day Mode active
Inventory AlertsPeanut-free granola bars (low) · Children's ibuprofen (low) · Laundry detergent (low)
Recent Caregiver LogGrandma Rosa: "Kids home safely — 3:22 PM" · Jess: "Ibuprofen 200mg given — 2:15 PM"
The mock data is the prototype's soul. A prototype with "User 1" and "Item A" reads as unfinished. Sofia, Emma, Lucas, and Grandma Rosa read as real — and real data produces real emotional responses during validation sessions.
05

Validation Protocol

This is not a usability test. It is behavioral observation. Watch what mothers do — do not ask them what they think.

Run for 2 weeks with 5–10 recruited participants before M1a begins. Recruitment via MomDom's personal network, the existing waitlist, and local mom groups. Incentive: early access + beta cohort recognition. No cash required.

The task (no script): "This is a prototype of MomDom. Explore it as you normally would. Try to do something useful with it today." Observe silently. Do not explain features. Note every moment of confusion and every moment of delight.
Day 0
First Contact
Does she understand the balloon metaphor without reading anything? Which balloon does she tap first? (tells you which pain point is sharpest)
Day 1
Behavioral Signal
Does she add a real event / real health log / real inventory item? Actual data entry with real household data is the primary behavioral signal.
Day 3
Habit Formation
Does she open the app unprompted? Does she share the caregiver link with anyone? Return visits without prompting = habit forming.
Day 7
Retention Check
Follow-up: "What would make you come back tomorrow?" Friction map: where does she pause and re-read? What does she try to do that doesn't exist yet?
Aha Moment Hypothesis: The aha moment occurs when a caregiver logs an update (dose administered, child picked up, symptom noted) and the mother receives the notification in real time without having to ask. This is the moment she realizes MomDom is not a to-do list — it is a shared operating layer for her household. The prototype must make this experienceable even with mock data.
06

Build Timeline

Multi-day prototype build, 2-week validation window.

Day 1 AM
Scaffold Next.js PWA in Lovable or v0. Set up mock data constants file. Build Screen 01 (Onboarding) and Screen 02 (Dashboard — both default and Sick Day Mode states).
Day 1 PM
Build Screen 03 (Calendar + recurring task wizard) and Screen 04 (Health + Sick Day Mode trigger + caregiver dose log). Deploy to Vercel/Netlify — get shareable URL.
Day 2 AM
Build Screen 05 (Household/Inventory + shopping list) and Screen 06 (Caregiver Sharing + "Preview as Babysitter" simulation).
Day 2 PM
Build Screen 07 (Confirmation Cards — all 3 examples) and Screen 08 (Settings). Mobile responsiveness pass. Share URL with first 2–3 testers.
Day 3
First observation sessions with real mothers. Iterate on any friction points found. Collect initial behavioral observations.
Week 2
5–10 mothers actively using prototype. Collecting behavioral observations: which balloon first, return visits, caregiver link sharing, feature requests.
End of Week 2
Validation summary written. Go / no-go recommendation for M1a. Design spec locked — each screen becomes the specification for React Native implementation.
07

Prototype → Production Handoff

The prototype is not throwaway work. Every screen is a specification. Every brick of data structure is a type contract.

Prototype ArtifactMaps To (Production)
Each screen group (01–08) 1:1 React Native screen in the mobile/ workspace
Tailwind class patterns from Lovable/v0 React Native StyleSheet or NativeWind equivalents
Mock JSON constants file TypeScript interfaces in packages/shared/src/types/
Confirmation Card UI (Screen 07) Template for all Amazon Bedrock confirmation cards in MVP+1
Caregiver permission toggles (Screen 06) Direct specification for RLS policy design delivered at M2b
Sick Day Mode state (Screen 02 + 04) Database state machine spec: health event → household_state transition
Budget 5-6 days of build time for the prototype — it replaces weeks of misaligned assumptions later in M2 and M3. The mock data structures you define in the prototype are the type contracts that packages/shared is built from. That's not extra work — it's the same work done earlier.