I built a baby tracker app from my wife’s hospital room

Published: 2 days ago (February 16, 2026 at 05:40 PM EST)

9 min read

Source: Dev.to

“I Think My Water Broke!”

“Said my wife the day before her due date.”

Hastily, I threw all the pre‑packed bags, a pillow and blanket for myself, and the baby’s car seat into the backseat of my truck. I took her to the hospital, and—unsurprisingly—she was right: her water did break.

It was a long day, especially for her. After 18 hours of labor and an emergency C‑section at 3 am, our son William was born. The first day after he arrived we slept, visited family who drove to the hospital, and asked the nurses lots and lots of questions.

One of the nurses asked,

“Do you know what time he ate last?”

We didn’t remember. It was quite late on his birthday, she was in pain, and we were both exhausted.

The nurse suggested we try to keep track of feedings. Most people use the Notes app on their phone, but I figured there had to be a better solution.

My developer brain didn’t want to search the internet or ask an LLM for options—I wanted to build it.

After we finally got some sleep (the nurses graciously took him for a few hours), I got to work… except I didn’t bring my laptop. I’ve coded on my phone before, but it’s a chore, and I wanted something that both my wife and I could use easily.

Then I remembered I had set up OpenClaw the previous weekend.

The Claw

OpenClaw, for those who don’t know, is a self‑hosted AI assistant that works like ChatGPT or Claude but has full access to the Linux system (or your laptop) it runs on. It includes a vast skill library and can connect to virtually any tool that runs on a Linux box or via an MCP server. I’ve been using it as a general assistant, replacing ChatGPT and Claude because it can tap into more tools that I find useful.

So I have an AI agent I can talk to via Telegram (it even interprets voice messages) that has full access to a Linux server and can be granted access to my cloud provider accounts. What could possibly go wrong?

Surprisingly, Not Much

I started from nothing—no template, no repo, just a basic idea of the tooling I wanted to use.

I followed proper agentic coding practice by planning first. I have an iPhone, my wife uses a Samsung Galaxy, so I wanted the app to be web‑accessible, preferably a PWA that acts like a native app. I had just discovered Retro UI and liked its brutalist aesthetic for an app that (for now) has only my wife and me as users.

I’m fond of Cloudflare Workers and Pages for their ease of development and rapid deployment, so I told OpenClaw that the stack should be:

Frontend – Retro UI (React implied), Vite, React Router
Backend – Hono (a lightweight TypeScript‑friendly framework)
Database – Cloudflare D1

I asked it to come up with a plan.

The Plan

OpenClaw suggested a monorepo structure with separate frontend and backend packages tied together using pnpm.

Frontend – Vite + React Router + Retro UI
Backend – Hono, compatible with Deno, Node, Bun, Cloudflare, etc.
Database – Cloudflare D1 (available and sufficient for now)

The plan made sense given the tools I specified, but the way it executed the integration introduced a few problems that I’ll discuss later.

Execution

After OpenClaw gave me a definitive plan, I supplied an API key with the necessary permissions and told it to execute. After some back‑and‑forth to get the deployment right, it produced an MVP—surprisingly functional.

I created an account, added a child, and logged a diaper change. It worked on the first try.
Feedings also worked on the first try. I later asked it to support switching between measurement units (hospital uses milliliters, most Americans use fluid oz). It now stores amounts in the smaller unit (ml) and converts on the fly, rounding ounces to the nearest tenth.

There were a few minor bugs and feature tweaks, but overall it was an incredibly good first attempt.

Try It!

I implore you to give it a spin: babylog.chand1012.dev. It’s super simple, and my wife loves how easy it is to use.

The Problems

1. Missing Migrations / No Migration System

When I tried to add naptime tracking, OpenClaw reported that a bunch of migrations were missing from the local files and suggested we need a migration system. I didn’t want to fix it immediately, so I asked it to work around the issue (which it did well), but the lack of a proper migration system will become a problem as we add more features and need to modify existing tables without breaking anything.

2. Weak Typing for the Database

The app is written in TypeScript, yet there isn’t strong typing for the database because we lack an ORM or migration system. This isn’t a show‑stopper, but I generally prefer strong typing for all of my projects.

3. Deployment Friction (Context Poisoning)

Getting the initial deployment was annoying due to “context poisoning.” OpenClaw kept hitting the wrong API endpoint to verify the API key and refused to try the other endpoints until I gave it the key together with an example curl request. Only then did it start working. This process took a lot of time and patience.

Bottom Line

OpenClaw proved that an AI‑driven, self‑hosted assistant can spin up a useful, production‑ready app in a single day, even with minimal initial guidance. The MVP is functional and already helping us track William’s feedings and diapers. The next steps are to:

Add a proper migration system (e.g., Drizzle, Prisma, or a custom script).
Strengthen TypeScript typings for the D1 schema.
Refine the deployment workflow to avoid context poisoning.

If you have a similar need—tracking baby feedings, diapers, naps, or any other small‑scale personal data—give the app a try and feel free to contribute improvements!

What I Learned

While this absolute zero‑to‑one development worked surprisingly well, I still think I’ll scaffold the template first—including CI/CD pipelines—before I let an AI agent loose on my project. The code was fine, but the lack of a migration system and the annoyance of getting the app properly deployed made me realize it’s better to have those pieces in place up front. That way development time can be even lower: spend less time getting stuff working and more time iterating on features.

Below is a quick step‑by‑step of the Chandler Agentic Development Flow.

Chandler’s Agentic Prototype Flow

Think of a good problem to solve
- What kind of app do you want?
- Hint: it’s probably a web app.
Decide the target platform
- You can make it a mobile app later if you get more than just yourself as a user.
- If not, maybe a command‑line tool.
- This can later evolve into a local GUI‑based app.
Choose frameworks

If it’s a web app
- Cloud‑hosted:
  - Front‑end: React Router
  - Backend: Convex or Cloudflare Workers + D1 with Drizzle
  - Or use Supabase
  - Authentication: Clerk (when using Convex or Workers)
- Self‑hosted:
  - Next.js App Router
  - Auth: Auth.js
  - Database: SQLite via Drizzle
- Both: always use shadcn (or a similar compatible component library).
If it’s a command‑line app
- Python for an MVP (Google’s Fire is great for a simple MVP)
- Go for a fast, maintainable CLI tool (always use Cobra).
If it’s a desktop GUI application
- Tauri (again, use shadcn or a compatible component library).
If it’s a mobile app
- React Native (use native‑looking components with dark mode)
- Capacitor (use shadcn or a similar library).
Scaffold the repo
- Set up a proper .gitignore (better to have too much ignored than too little).
- Add a README and a CLAUDE.md that are well‑thought‑out and well‑written.
  - Follow HumanLayer’s Claude best practices.
- Configure CI/CD for the main (release) branch: all type checks, linting, and builds must pass.
- Add pre‑commit hooks for linters and type checkers (including Python via Ty).
Add initial code
- Simple “Hello World” page for web apps with a matching “Hello World” backend.
- Set up the ORM correctly.
- Scaffold any needed shadcn components.
Initial test deployment
- Deploy once to verify that CI/CD works end‑to‑end.
Let the agent do its thing
- With scaffolding complete, the AI agent can iterate on features quickly.
- This saves time and token costs, especially when using high‑quality LLMs like Opus 4.6.
- Since the heavy lifting is done, you can run parallel feature work via tools such as:

Conclusion

If there’s a headline here, it’s that agentic coding is already good enough to be useful in the messiest, highest‑stakes moments of real life—when you’re sleep‑deprived, constantly context‑switching, and just need something that works.

OpenClaw got me from idea to a working baby‑tracker in a day, straight from a hospital room, without the usual ceremony. That’s a big deal. The MVP was solid, the iteration loop was fast, and the app is now something we actually use.

But the trade‑offs were impossible to ignore. Skipping fundamentals like migrations, typed data access, and a repeatable deploy pipeline lets you ship quickly, but you borrow friction from your future self. The hour lost to a “context‑poisoned” deployment and the awkward database setup reminded me that agents are powerful, yet they still need guardrails.

Takeaway: let the agent sprint, but give it a track to run on.

Scaffold the repo.
Lock down CI/CD.
Put migrations and typing in place.

Then hand off the “build the feature” work to the agent and spend your own time making product calls, testing, and prioritizing.

Babylog was a tiny project, but it changed how I think about prototyping. The bar for “I can just build this” has dropped dramatically, and with the right scaffolding, it will only keep dropping.

Important Note

I did not use proper security practices when developing this; I went “whole‑hog, no cares” to get it done ASAP. Under most circumstances, you should manually set up CI and deployment yourself and never, ever give an LLM your API keys.