πŸŒ…

Morning Ready

Most of my recent product work is platform β€” powerful inside other products, hard to show directly. So I built one end to end: Morning Ready, an AI app that tells a parent what their kid needs each morning β€” concept to production in about three days.

RoleSole PM & builder
Built in~3 days
StatusLive in production
SurfaceMobile web
01 β€” The problem

The pain isn't the checklist. It's the buried exception.

Parents already know the basics: water bottle, backpack, snack. The scramble is the one detail buried across emails or WhatsApp messages: what does my child need today?

What to bring: Wear green, swimsuit, towel, class party items.
Lunch risk: Whether today's school lunch is likely to work for the child, based on allergies, dislikes, dietary rules, and past patterns.

This app answers this exact question.

Day view showing Bring packing list and graded Lunch risk for Anna
Day view. What to bring and a graded lunch read β€” in one screen.
Morning Ready daily email brief showing Anna's lunch risk and action
Daily brief. Delivered each morning β€” lunch risk, recommendation, one-tap action.
02 β€” The decisions a prompt can't make

Craft is in the calls, not the generation.

Decision 01 Β· Lunch risk

The real cost is downstream

When a child doesn't eat school lunch, the cascade is predictable:

  • Comes home low-energy or cranky
  • Parent gives a pickup snack to compensate
  • Snack kills dinner appetite
  • Nutrition rhythm breaks down
  • Paid school lunch becomes unreliable

The fix is knowing in advance. The core loop: parent uploads the monthly menu PDF β†’ app parses the menu by date β†’ compares each day’s lunch against this child’s allergies, dislikes, dietary rules, and past feedback β†’ parent gets a useful alert only on risky days.

The same upload pattern powers Bring: paste a camp email or upload a schedule PDF to get tomorrow’s packing list.

Anna's profile showing separate fields for allergies, dislikes, and dietary rules
Profile. Three fields, three semantics.
Lunch risk detail showing graded risk, recommendation, and correction buttons
Risk detail. Recommendation + correction loop.
Decision 02 Β· Trust

Private data about kids β€” the app can't look like a toy

Parents entering their child's allergies and dislikes need to trust the product. Two deliberate steps: the Google sign-in screen shows “Morning Ready” by name with Privacy Policy and Terms of Service linked β€” not a generic project ID. This requires going through Google's OAuth branding verification, which most demos skip. It's not hard, but it takes time and attention most builders don't spend β€” and it's exactly the kind of detail that separates something that feels real from something that feels like a side project. And the parent owns their data: one tap wipes the profile, all menus, and all scores.

Google account chooser showing Morning Ready with T&S visible
Google SSO. App name and T&S on Google's own screen.
Wipe all data confirmation β€” one tap to erase everything
Data control. One-tap full wipe.
Decision 03 Β· Activation

Value before setup

A product tour runs before sign-in so the parent sees the output before committing. Onboarding ships with a pre-loaded menu so scoring works immediately β€” no data entry required.

Product tour showing packing list before sign-in
Product tour. See the output before signing in.
Import Menu β€” pre-loaded menu ready with upload and paste options
Menu import. Pre-loaded menu, or upload your own.
03 β€” Production
Production Β· not a sandbox

Everything a demo skips.

Real auth, managed data, authenticated email, CI/CD, regression tests β€” the plumbing a prototype skips. Here as proof, not as the headline.

CI/CD β€” dozens of production deploys off main, feature-flag gated, behind a 72-test regression suite
Data β€” managed Supabase Postgres with automated backups; persistent per-child state powers the correction loop
Email β€” Resend with full SPF/DKIM/DMARC; 100% inbox deliverability on the daily brief
Always-on β€” custom domain and a cron-driven morning brief running in production, not prototyped
04 β€” How it was built

Fast and thoughtful.

~3days, idea to prod
1person, full stack
72regression tests

AI compressed the build from weeks into days. The point isn't the speed β€” it's where the saved time went: into the judgment a model can't make. A working product on day one, a deliberate design pass on day two, production hardening on day three β€” including two restructures (nav and onboarding) that were decided, not generated.

The craft

Anyone can prompt a model for a packing list. The work was building the product around it β€” the data model, the judgment calls, and the craft that keeps it from looking like something generated.

Visual identity built on the Impeccable design system β€” deliberate type, color, and spacing to avoid generic AI aesthetics
Structured data model, risk as a recommendation, feedback loop per child β€” product decisions, not prompt decisions
Real auth, CI/CD, 72 regression tests β€” not a sandbox
Day 1MVP + AI feedback loop
Build
MVP shipped β€” menu import, Claude parsing, per-child risk scoring
AI craft
SSE streaming β€” today's score first, the rest loads in the background
AI craft
Correction UI feeds parent feedback into future predictions β€” the model learns per child
Value
Pre-loaded menu β€” meaningful data on day one, zero setup; passwordless auth
Day 2Design overhaul + UX polish
Design
Rebuilt the visual identity on the Impeccable system β€” deliberate type, color, spacing, replacing generic Tailwind defaults
IA
Bring-first restructure; a Day tab answering "what do I need right now" instead of a raw calendar
Value
3-step onboarding β€” allergies and dislikes personalize every prediction
Day 3Production
Infra
Custom domain, SMTP + email auth (SPF/DKIM/DMARC), database backups, cron for the morning brief β€” running, not prototyped
Auth
Google OAuth consent + magic-link login
Quality
72 regression tests β€” behavioral contracts, not just unit tests
Legal
Privacy policy, Terms, and medical disclaimers β€” a baseline before the first real user
05 β€” What's next

Iterate based on user feedback.