“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 carseat into the backseat of my truck. I took her to the hospital, which to our lack of surprise, she was right! Her water did break.

It was a long day, especially for her. After 18 hours of labor then an emergency c-section at 3am, our son William was born. The first day after he was born, we slept, visited with family who made the drive 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 did not remember. It was quite late on his birthday at this point, she was in pain and we were both exhausted. We didn’t remember at all.

The nurse said that we should try to keep track of it. Most people keep it in their phones notes app, but I figured surely there was a better solution for this.

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

After we both slept (the nurses graciously took him for a few hours so we could catch up on sleep), the next day I got to work.

Except, that I really couldn’t. I didn’t bring my laptop, and while I have coded on my phone before, its a bit of a chore and I wanted something working that we could both use.

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

The Claw

OpenClaw, for those of you who don’t know, is a self-hosted AI assistant that’s meant to be like ChatGPT or Claude but has full access to the Linux system (or you laptop) its running on, and includes a vast skill library and the ability to connect basically any tool that can run on a Linux box or via MCP server. I’ve been using it as a general assistant, replacing ChatGPT and Claude as it had access to more tools that I found useful.

So I have this AI agent that I can talk to via Telegram (and I mean literally talk - it can interpret Telegram voice messages) that has full access to a Linux server and I can give access to some of my cloud provider accounts. What can go wrong?

Surprisingly, not much

I started from nothing - no template, no repo, only a basic idea of what tooling I wanted to use.

I followed proper best agentic coding practice - by planning first. I have an iPhone, however my wife as a Samsung Galaxy, so I wanted this app to be web accessible, a PWA that acts like a native app is preferred. I had just discovered Retro UI and quite liked the brutalist aesthetic for an app that (for the time being) has just my wife and I as its only users. I’m quite fond of the Cloudflare Workers and Pages platform, and its ease of development and use should make it fast to develop and deploy for the agent. That’s the only guidance I gave it for stack - I wanted Retro UI (React implied) and I wanted the entire thing to be built on the Cloudflare Workers and Pages platform. I told it to come up with a plan.

The Plan

It thought that having a separate frontend and backend with a monorepo structure was best, tying the projects together using pnpm. The frontend uses Vite and React Router (which is one of the frameworks I quite like) and the aforementioned Retro UI. The backend uses Hono, which is quickly becoming the preferred backend framework for Typescript projects, as it has compatibility with a wide range of JS/TS runtimes (Deno, Node, Bun, Cloudflare, and more). For the database it chose to use Cloudflare D1 since its available, which is fine. Given the tools I told it to use, it makes perfect sense, but how it executed this integration is where we have some problems. I’ll get to that later.

Execution

Once OpenClaw gave me a definitive plan, I gave it an API key with the proper permissions it would need to deploy the application, and told it to execute. After some back and forth getting it to deploy, it deployed an MVP. A surprisingly functional MVP. I created an account, added a child, and decided to test out by adding his diaper we just changed. It worked first try. Feedings worked first try as well, thought I later had to ask it to allow the switching between measurement units (hospital used milliliters, most Americans use fluid oz) which I told it to store the amounts in the smaller unit integers (it stores in ml, converts on the fly based on the user’s preference and rounds the oz to the nearest tenth). There was some other back and forth for little bugs and feature requests I found here and there, but overall an incredibly good first attempt.

Try it!

I implore you to go try it out yourself, link here. Its super simple and my wife loves how easy it is to use.

The Problems

The first big issue came up when I wanted to add naptime tracking. While its not something I’m doing with my, at the time of writing, 12 day old child, but it could be super useful in the future when he’s a bit older. OpenClaw noted that a bunch of the migrations are just missing from the local files, and that we really should have a migration system. Since I didn’t have the desire to fix it, I told it to work around it (which it did a great job at) but the lack of a migration system will definitely be an issue for the future when we want to add more features and update existing tables without breaking anything. On top of that while the app is written Typescript, there really isn’t super strong typing for the database due to the lack of ORM or migration system. This isn’t an issue in all cases, but I generally prefer strong typing for any of my projects.

Getting the initial deployment was also quite annoying thanks to context poisoning. The OpenClaw kept hitting the wrong API endpoint to check if we had a valid API key and kept refusing to try and use it with the other API endpoints, until I finally gave it the API key with an example curl request then it started working. This process took me well over an hour, and was incredibly annoying since I got it consistently deploying and working in a different thread. This is what pushed me to set up proper CI/CD (technically I just told OpenClaw to do it) so that it didn’t have to deploy anything itself, just handle builds and pushing to the GitHub repo that I also had it create.

Important note: I did not use proper security practice when developing this, I went whole-hog no cares in the world just 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.

What I Learned

While this absolute zero to one development worked surprisingly well, I still think I’m going to scaffold the template first along with CI/CD pipelines before I set my AI agent lose on my project. While the code was fine, the lack of a migration system and the annoyance of getting the app properly deployed, I’d rather get that stuff working first so that development time can be even lower, spending less time on getting stuff working and more time iterating on features. Here’s a quick step-by-step on the Chandler Agentic Development flow.

Chandler’s Agentic Prototype Flow

1. Think of a good problem to solve
2. What kind of app do you want?
   1. Hint - its probably a web app
      1. You can make it a mobile app later, if you get more than yourself as a user.
   2. If its not, maybe a command line tool
      1. This can evolve later into a local GUI based app
3. What frameworks?
   1. If its a web app
      1. If cloud hosted: React Router + Backend (Convex, CF Workers + D1 with Drizzle, or Supabase)
         1. If using Convex or Workers, use Clerk for auth.
      2. If self hosted: NextJS App Router, Auth.js, SQLite via Drizzle
      3. For both: always use shadcn or a similar compatible component library.
   2. If its a command line app
      1. Python for an MVP
         1. Google’s Fire is great for a simple MVP
      2. Go for a fast, easy to maintain CLI tool
         1. Always use Cobra for CLI tools
   3. If its a desktop GUI application
      1. Tauri
         1. always use shadcn or a similar compatible component library
   4. If its a mobile app
      1. React Native
         1. Use Native-looking components with dark mode
      2. Capacitor
         1. always use shadcn or a similar compatible component library
4. Scaffold the repo
   1. Need CI/CD when deploying to main
      1. Main is your release branch. All type checks, linting, and builds should pass.
   2. Need linters and type checkers via pre-commit
      1. Type checking for all languages, Python included.
   3. README and CLAUDE.md should be well thought out and well written.
      1. Follow HumanLayer’s Claude best practices.
      2. For example, mention that you should use best practice, but you don’t need to give it examples.
   4. A proper .gitignore with as much as you may need now or later added.
      1. My hot take: I’d rather have too much in my ignore file than not enough.
   5. Add initial code
      1. Simple “hello world” page for web apps with a hello world backend
      2. Set up the ORM properly
      3. Add scaffolding needed for shadcn components
   6. Initial test deployment
      1. Do an initial test deployment to make sure that CI/CD works
5. Now let the agent do its thing
   1. Once you had the scaffolding complete, its much easier for the AI agent to quickly iterate on features
   2. This saves time and token costs, especially when using high quality LLMs like Opus 4.6.
   3. Since all the hard stuff is done, you can do parallel features via apps like Conductor, Cursor Cloud Agents, or Copilot Agents on GitHub.

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, context switching constantly, and you just need something that works.

OpenClaw got me from idea to a working baby tracker in a day, 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 it also made the tradeoffs impossible to ignore. When you skip fundamentals like migrations, typed data access, and a repeatable deploy pipeline, you can ship quickly, but you’re borrowing friction from your future self. The hour lost to context poisoned deployment and the awkward database setup were reminders that agents are powerful, but they still need guardrails.

So my current takeaway is simple: 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’s only going to drop further.