I don't hand off the spec. I build the product, then we argue about the real thing.
I work as a product manager with AI coding agents as my engineering team: I set the brief, the rules and the taste, they write the code, and I review, test and ship. Most recently that meant Lull, a baby-care app with a sleep prediction engine, two research-based courses, a starting-solids planner and a quiz-to-checkout funnel, taken from a one-line brief to a working beta in ten weeks. No engineering team, no hand-off, one person deciding what gets built and holding the line on what the product will and will not claim.
The problem
Baby sleep apps predict a nap time and present it as a fact. They are sleep-only, so a parent still runs feeds, nappies, solids, health and outings in three other places. The advice inside them contradicts the advice everywhere else, and the "regression" label gets attached to every rough week.
The brief was one line: a sleep tracker. I repositioned it as the whole first year with sleep as the one domain that has a real engine behind it, and set three rules the product would keep no matter what: predictions are shown as windows with a stated confidence, never as a time; everything medical or about safe sleep is said plainly, with no wink; and there is no invented social proof anywhere, not a rating, a testimonial or a percentage claim.
Cheeky about the app, plain and warm about medicine. The wink stops at safety.
The tone rule, written into the content guide and enforced by a test.What shipped
One Node.js application serving a public site, two quiz funnels, two checkout pages, the app and its API. The counts below are read from the build itself, not typed in.
Decisions I would defend
A window, not a time
Every prediction is an onset plus a ± width that tightens with data, and a named calibration stage ("Learning Mira's rhythm · day 2") that never shows an empty state. Day zero falls back to age norms and still reads as progress.
Why: a wrong time destroys trust in one afternoon. A window that narrows is a promise the product can keep.
One table of truth for age norms
The prediction engine, the marketing age guides and the course text all read the same per-month table. A marketing page cannot quote a wake window the app disagrees with.
Why: in a health-adjacent product, two numbers for the same fact is the fastest way to lose a parent.
The reaction logger never triages
When a food disagrees with a baby, the app offers the mild signs in exactly the course's words, records the parent's choice, pauses the food, and stops. Severe signs go to the emergency number, never to a form. Contact irritation is carved out explicitly so families do not drop foods they never needed to.
Why: the highest-stakes screen should do the least. A test asserts the wording still matches the course.
Twelve months is a schedule problem
The dataset marks which regression windows the evidence recognizes. A struggle at twelve months is classified as schedule, and the product says lengthen wake windows rather than drop the nap.
Why: an opinion, stated and sourced, is more useful to a tired parent than a generic "regression" banner. It is also the product's clearest difference from the category.
No invented social proof, enforced
No testimonials, ratings, review counts or "% of parents" anywhere in quiz or checkout copy. Every number on the checkout is counted from the repository at build time, and a test fails if the copy drifts.
Why: borrowed credibility converts once and costs trust for months. I wanted a funnel that converts on what the product actually contains.
How the sleep engine works
The engine is a set of pure, unit-tested modules. It starts from published age norms, learns the baby's own wake windows slot by slot as data arrives, blends the two with a weight that grows with evidence, and shows the result as a window. I specified the behaviour, the guardrails and the edge cases; the maths was chosen to be explainable to a parent in one sentence each.
- Adjusted age picks a band
Chronological age minus weeks premature selects one of 28 monthly bands: wake-window range, nap count, day and night sleep. Under three months the engine shows norms only and locks schedule settings.
- Each wake window gets a prior
A day with N naps has N+1 windows. The first is shortest, the run-in to bedtime longest. Where a published sample schedule exists it is used; otherwise the band's range is spread across the slots.
- The baby's own days are read
Logged sleeps become days in the baby's timezone, each with its observed windows. Tagged days are kept for display but excluded from learning. Anything older than three weeks is ignored.
- Personalization, slot by slot
Outliers beyond three scaled median deviations are dropped. A recency-weighted average with a six-day half-life is blended with the prior using a data weight that rises with the number of observations and is capped, so the age prior always keeps a hand on the estimate. Naps personalize more slowly than bedtime because they are noisier.
- Today is projected from the last wake
Never from "now", so opening the app at ten or at one shows the same plan. A short nap shortens the next window a little; a long one lengthens it. Bedtime is never skipped and is clamped to a sane evening range.
- Regimes change with age
Under six months sleep runs on pressure, so onsets follow wake windows. From nine months the clock dominates, so the engine holds each slot's usual clock time and corrects bedtime instead of sliding the afternoon. Between, it averages the two.
- Transitions need seven days
A nap drop is declared only after seven consecutive complete days at the lower count, corroborated by day sleep running short. Then the engine widens its windows for a week while it re-learns.
Confidence stages, in order: age norms → getting to know → learning → personalized nights → personalized → dialled in, from ± 45 minutes down to ± 15.
Funnel and monetization
Paid traffic lands on a splitter, chooses a baby-sleep or a starting-solids plan, and answers a three-minute quiz. Every quiz opens by asking whether the mom or the dad is filling it in, branches once on the baby's age into a stage-specific screen, and ends by turning the email into an account with no password, so the buyer reaches the checkout signed in and signs back in later by link. Four answers travel on as an onboarding prefill; nothing about the family's health is stored.
The checkout sells three plan lengths and shows three post-purchase offers in a fixed ladder, with a decline screen that returns the buyer to exactly the step that failed so a first purchase is never lost. Without a payment processor the whole flow runs in a simulated mode, so QA, copy review and stakeholder walkthroughs happen on the real pages, not on mock-ups. A documented test card forces the decline path.
Content operations
Two overlapping sleep courses were merged into one on an age-stage spine, because "mine is four months" is how a parent arrives, not "day six of a fortnight". The shape changed with the merge: each chapter is a ten-minute audio lesson and the on-screen text is its summary; every module cites its research and ends in a quiz; a two-page companion guide is generated from the same data so it cannot drift.
Audio is produced from written scripts on a style guide, with length controlled by measured spoken words per minute rather than guessed, and a diff that checks every number in a rewritten script against the previous recording so a figure cannot quietly change. Runtimes are measured by the build and written into a manifest, never typed.
What is next, honestly
The build is a beta, not a launch. Before it ships it needs a clinician's review of the age table and the allergen method, a full visual redesign, the remaining audio lessons, final food and recipe photography, translations beyond the app strings, and the payments, CRM, support and legal layers that a subscription business runs on. I keep that list as a checklist with a status per line, and I would rather show it than hide it.
Vibe coding, the disciplined version.
The agents are fast and confident and sometimes wrong. The job is to make wrong visible early: written rules, tests that enforce them, and a product you can click through from the first week.
Evidence before opinion
Age norms, allergen guidance and safe-sleep rules came from published sources, with the source recorded next to the number. Where the evidence is thin, the product says so instead of rounding up.
Direct AI as a team
I write the brief, the acceptance rules and the house style, review the diff, and walk every changed flow in a real browser before it counts as done. The agents build; I decide, and I own what ships, including the parts I would never have typed myself: a Bayesian personalization model, a timezone-safe day builder, an RFC-compliant calendar feed.
Counts, not adjectives
Anything the product claims about itself is computed from the build and asserted by a test. If the number cannot be derived, it does not go on the page. The same goes for this portfolio: every figure on it is read from the repository.
Ship the walkable version
Simulated payments, an in-memory database and a seeded demo baby mean anyone can walk the whole product on a laptop in a minute. Reviews happen on the real thing.
Say hello.
I am open to product roles where a PM who can build the first version is an advantage, and where the users deserve honesty. Write to esther191189@gmail.com or find me on LinkedIn.