Morning Ready, MCP edition: a product decision log

How I extended a solo-built parenting app into a Claude MCP app — and what stays durable about the product decisions behind it, even as the frontier moves on.

Claude rendering Morning Ready's score_lunch tool as inline UI — a graded lunch risk card with on-the-menu items, what-to-do guidance, and correction buttons

A nagging parent problem

I built a mobile web app Morning Ready two weekends ago to solve a problem for me as a parent every morning: what do I need to prepare for my kids today?

There can be different activities at school or summer camp that require me to pack something special: for example, swimming wear and a towel for water play. Or there is a special summer event on Friday afternoon and I need to pick up earlier than usual. I don't want to go back to the email or messages to confirm.

The other recurring question is lunch. Will my kid actually eat what is on the school menu today? My kid is not a picky eater, but several times a month she likes nothing on the lunch menu, eats very little, gets hungry in the afternoon, and begs for food at pickup. This is totally avoidable because the school publishes the menu ahead of time.

The problem is not lack of information. The problem is turning scattered information into a small, timely decision.

You can already sort of get the information by cobbling together ChatGPT for parsing and Calendar MCP for reminders. However it's a messy workaround: there's no structured profile, no feedback loop, and managing everything in a long running thread will sooner or later become impossible to track.

So I built a dedicated web app, Morning Ready, to solve this. Idea to production in three days, solo.

I built the app as much as a case study as a real product that I want other parents and myself to use, as I found that product thinking, principles and learnings apply to all the apps, business/enterprise SaaS or consumer products. I have written about them here.

Extending Morning Ready into an MCP app

Then I shared it with family and friends. One particular request came up repeatedly: people already have go-to tools and want to keep using them.

For example, use ChatGPT to parse email screenshots and update schedules, use Google Calendar to send timely notifications. These general purpose tools not only have solved these problems much better than my app (e.g. more flexible reminders), heck, they solve it for free while I'm paying for Claude API calls 😂 in the app.

So I spent a weekend afternoon extending Morning Ready to be an MCP app. Practically, this means Claude can connect with Morning Ready and, when needed, render parts of the app inline. I built it for Claude first and plan to extend it to ChatGPT.

It's tempting to ship UI everywhere. It's fun (and easy) to build. But that is not automatically good product design.

The question is: when does the user need the product experience, and when to leave to Claude?

Decision 1.  Keep in the app  vs.  Let Claude handle

  • Claude should own flexible input and orchestration: screenshot parsing, document upload, handling conversational input are things frontier models are already good at. Lean on Claude and don't reinvent.
  • The app should own the full context: authentication, onboarding, preferences & settings need a full product surface. Recreating all of that in chat would add friction without adding much value.

Decision 2.  MCP as text backend  vs.  iframe in

  • For simple reads and writes, text is enough: "update Grace's lunch preference," "show today's profile," "confirm that pickup is earlier this Friday." Claude can handle that as conversation, with Morning Ready acting as the data backend.
  • For the core experience that can't be flattened to text — e.g. daily lunch view, with graded risk score, explanation and inline feedback — I preserved the experience because the user can scan, trust, and correct.

As with the original web app, I built the MCP app for the parent's trust — now the agent is acting on their behalf: for every write action, there's a confirmation UI with an audit log to the user.

What stays durable as the frontier moves

This weekend project is small, but the product questions are not.

Most software products are now trying to figure out how they should show up inside agents. Some workflows will stay in the first-party product. Some will move into ChatGPT/Claude. As product lead for Intuit's AI Experience Platform, I have worked on both.

The implementation details will keep changing. Frontier models will launch new capabilities. UI patterns that feel new today may become table stakes in a few quarters.

But the underlying product questions keep coming back:

  • What should the product own vs. agent own?
  • When is text enough vs. full UI is needed?
  • How do we preserve trust when the agent can act?

The PM craft I find durable in this era is answering these questions and having the team aligned on them. Not chasing every model update, or turning every product to chat.

Whether it's for a handful of users (Morning Ready) or at 100M-user scale (Intuit/Google), the product judgment travels.