I Built an AI Parenting Copilot with Cursor — What I Learned

Problem

Parents (myself included) drown in fragmented advice: sleep blogs, conflicting forums, and late-night searches that do not know our child’s age, routines, or what we already tried. I wanted a calm copilot that could draft age-aware suggestions, summarise a chaotic day, and help prepare questions for a paediatric visit — without pretending to be a clinician.

Why I built it

I was already using Cursor to ship AI SaaS experiments. A parenting copilot was personal enough that I would dogfood it nightly, and sharp enough to force real product decisions: safety disclaimers, memory of routines, and cost control when sessions get long.

This write-up is build-in-public learning. Metrics that are not yet measured stay as placeholders — I will not invent traction.

Initial hypothesis

If a parent can log a short daily context (age band, sleep window, what was tried) and get a structured, non-alarmist next-step plan in under two minutes, they will return a few times per week — more than they open generic chat tools for the same job.

I also hypothesized that retrieval over the family’s own notes would outperform a naked chat UI for trust and relevance.

MVP

The first shippable slice:

1. Account + private family space
2. Child profile (age band, non-clinical preferences — not a medical record)
3. Daily check-in form → model-generated “tonight’s plan” with clear non-medical framing
4. Saved history parents can revisit
5. Hard stop: no diagnosis language; escalate-to-professional copy when risk keywords appear

Out of scope for v0: multi-caregiver permissions polish, voice, marketplace content, and any claim of clinical accuracy.

Technology stack

• App: Next.js on Vercel
• Auth + DB: Supabase (RLS on family-owned rows)
• AI: Server-side calls to a foundation model API (model choice treated as config)
• Build: Cursor for schema, RLS policies, and the generation route
• Observability: basic product events + provider usage logs

Exact package versions and model IDs belong in the repo changelog, not this narrative.

AI architecture

Check-in form → validate + redact → build prompt with age band + recent notes
    → server model call (timeout + max tokens)
    → store output with model/prompt version
    → safety post-check (keyword / policy layer)
    → render plan + disclaimer

Design choices:

• No client-side keys
• Context window budget — last N check-ins, not the entire history every time
• Prompt versioning so I can diff behaviour when I change instructions
• Kill switch feature flag to disable generation without undeploying

What worked

• Cursor was fast for the vertical slice: auth → schema → RLS → AI route → UI
• Constraining the form (structured inputs) beat free-form “chat about parenting” for output quality
• Storing prompt/model version with each run made debugging less mystical
• Writing the non-medical positioning before marketing copy prevented tone drift

What didn’t

• Early prompts were too “helpful” and occasionally edged into advice that felt clinical — required tighter system instructions and refusal patterns
• Unlimited follow-up chat exploded tokens; I had to add turn caps
• I under-invested in empty states; parents did not know what “good” input looked like
• I delayed cost dashboards, which made early dogfooding feel free when it was not

Cost lessons

• Measure [PLACEHOLDER: cost per successful session] from day one, even with only myself as traffic
• Cap max output tokens per plan generation; parents prefer short plans overnight
• Cache or reuse static disclaimer/safety blocks instead of regenerating them
• See also How I Control AI Costs Before Launching to Real Users

I will publish real unit economics when I have stable instrumentation — not before.

User feedback

Private dogfood and early readers only so far.

• [PLACEHOLDER: real user count] invited or onboarded
• [PLACEHOLDER: waitlist size] if applicable
• [PLACEHOLDER: retention after week 1]
• Themes I heard qualitatively: desire for spouse sharing, anxiety when the model hedged too much, gratitude for checklists over essays
• [PLACEHOLDER: qualitative feedback quote — only if consented]

No testimonials or conversion rates until they are real and approved.

What I would change

1. Ship metering and daily caps before any public link
2. Invest in onboarding examples (sample check-ins) earlier
3. Separate “plan generation” from open chat as different products with different budgets
4. Add an explicit human escalation card when parents mark a concern as urgent

Next experiment

Run a small, invite-only cohort focused on one job (bedtime wind-down plans for a single age band). Measure completion of the check-in → plan loop and whether parents edit the plan. Success criteria will be written against [PLACEHOLDER: real user count] and [PLACEHOLDER: retention after week 1] once the cohort is live — not guessed in advance as vanity targets.