I Built a Baby Tracker App at 2AM — Here’s What AI Got Right (and Wrong)

How It All Started

I became a father recently, and my partner and I suddenly found ourselves trying to track everything about our baby. When did he last eat? How much? How long did he sleep? What was that diaper situation like?

You know the drill — except when you’re sleep-deprived, you actually don’t remember the drill. We needed to track all this stuff not because we’re data nerds, but because it’s surprisingly easy to forget everything in the chaos of new parenthood. Plus, we wanted to sound somewhat competent when the pediatrician asked questions.

We started with the classic approach: frantic texts back and forth and random notes scattered everywhere. Spoiler alert — this doesn’t work when you’re running on three hours of sleep.

Since I’m a tech person, I figured I’d build something simple. I wanted a web app that worked fast with dead-simple UX so we could log things quickly without thinking too hard.

First Success with Lovable

I went with Lovable because I’d been using it for hobby projects and some professional prototyping, though I’d never really gone all-in on it. I had this recent experience where I built most of a frontend in a couple hours that had previously taken me months. (Obviously I knew the direction better the second time, but still — pretty impressive.)

So I started prototyping. After 4 iterations, I had something that worked okay. Connected it to Supabase, and boom — it mostly did what we needed. It solved our immediate problem, tracking diaper changes and breasfeeding sessions, even though there was definitely room for improvement.

But here’s where I probably made a mistake: I got excited.

When Excitement Leads to Poor Decisions

I bought a domain. Built a landing page (also with Lovable). Started iterating more and more to turn this into a “real product” instead of just something for us.

I improved all the existing features, added new ones, threw in analytics with plenty of graphs (because who doesn’t love a good chart?), and built multiple caregiver support with email invites so both my partner and I could access the same data in real time.

That’s when I started hitting Lovable’s limits, and they became pretty obvious pretty quickly.

The code would break by itself at least once a day. And yes, it was still using credits while breaking. Then I’d have to carefully craft prompts to try fixing it, which didn’t always work. So I’d end up going manual — reading through the AI-generated codebase to understand what was happening.

Don’t get me wrong, reading AI code isn’t inherently bad. But it kind of defeats the whole “vibe coding” promise, you know?

The main issue I kept running into was unnecessary duplication. Sometimes my “manual coding” was literally just deleting stupid stuff that Lovable had added for no reason.

There’s also the framework lock-in thing. Lovable is pretty opinionated about using Vite and has these proprietary component taggers (I assume to help their system work better). As someone who’s, let’s say, not a huge JavaScript fan, being locked into their specific choices added friction I hadn’t expected.

A practical example of a 75-Credit Feature

Let me give you a concrete example that really illustrates where things break down.

I wanted to build this “Feeding Window” feature — basically a prediction system for when the next feeding should happen, based on previous feeding sessions, the baby’s age, and weight. Pretty straightforward concept, right?

This one feature ate up over 75 credits. Even when I was extremely specific in my prompts, Lovable kept messing things up. It would remove other working features. It would duplicate code unnecessarily. It would iterate on legacy code that literally wasn’t doing anything. Thus I was either rolling back or using more credits to steer the system to where I wanted.

The version that actually works? I built it mostly with GitHub Copilot and regular programming (nothing beats knowing how to write code from scratch to speed up things when vibe coding gets you stuck). Took a fraction of the time and worked properly from the start.

Where Copilot Actually Surprised Me

Here’s the thing about GitHub Copilot — it genuinely surprised me on this project. I’ve been using it for years, mostly for autocomplete and basic suggestions. I’ve used Copilot even before ChatGPT when they were using their own specific coding model — the next edit suggestions were okay, but the relatively recent agent mode is indeed game-changing, and keeps getting better.

This time around, it was creating entire features and refactoring code properly with minimal guidance from me. I had this recent experience where I rebuilt most of a frontend in a couple of days on and off that had previously taken me months. (Obviously I knew the direction better the second time, but still — the acceleration was real.)

GitHub Copilot with Claude Sonnet 4 is amazing. Until it’s not. LLMs still tend to delete and change unrelated things. They are amazing, but they’re still stochastic parrots, in the sense that they decide on something and then keep justifying that decision most of the time instead of saying “oops, not really.” In multi-step systems this tends to be mitigated, but it’s still far from perfect.

Even so, I was honestly amazed. More time to stare at my sleeping kid (new parent priorities), while the AI handled the heavy lifting under my direction.

Copilot became my main tool for both manual coding and AI-assisted development on this project with Lovable being the go to to build new versions zero of smallish features and explore. It also helped me clean up and simplify a lot of the poor architectural decisions that Lovable had made.

But — and this is important — this only worked because I understood what was happening under the hood. I had to be pretty careful about the direction I gave it.

The difference became really clear: Copilot works with you when you maintain some control. Lovable promises to work for you but ends up needing the same level of technical oversight.

The main practical difference might be that Lovable works with Supabase out of the box, while Copilot doesn’t. Though there’s a Supabase MCP server now (haven’t tried it yet), which could potentially change that dynamic.

Classic Maker Behavior

Here’s the funny part: I only thought to research existing baby tracking apps after I’d already solved our main problem. Classic maker move — build first, Google later.

Did I find existing solutions? Of course. Some probably better than what I built at 2am between feedings.

Do I regret building my own? Not even a little bit.

Look, as a maker, I’d rather spend 30 hours and pay extra for hosting to have something that fits exactly what we need — and learn stuff along the way — than pay €5–15 monthly for something that’s just “okay.” Plus, you never know what might turn into a market opportunity.

There’s something really satisfying about using something you built every day. It feels useful and natural instead of forcing you to adapt to someone else’s design decisions that don’t quite make sense for your situation.

What “Vibe Coding” Actually Gets You

This wasn’t my first experience with vibe coding — I knew the limitations going in. This project mostly reinforced what I already understood about where these tools actually stand.

“Vibe coding” only gets you so far. That said, I’ve found that if your initial prompts are careful and directional, things tend to go better.

But here’s the real issue: if we use these tools to prototype and explore, then try to take that same codebase to production, it’s like the classic story of an MVP that suddenly needs to be production-ready and built for scale the next day. There will be problems. Lots of them.

The magical feeling of describing what you want and watching AI build it has real boundaries. Those boundaries become painfully obvious when you try stretching a prototype into a production system without proper architectural planning.

I admit, sometimes I just “doom code” — that weird, stubborn cousin of vibe coding, where we just doom scroll on the LLM to do what we want, and it never works, most of the time because we don’t really know what we want or where we are heading (also known as poor software engineering decisions)

What This Means for Development Teams

Different tools serve different purposes, and understanding that upfront can save you a lot of headaches.

Here’s a simple framework I’ve started using — call it the “AI Tool Fit Matrix”:

Use Lovable-style platforms when:

You need to validate an idea quickly
You’re okay with framework lock-in for the prototype phase
The feature set is relatively standard (CRUD, forms, basic UI)
You want something working in hours, not days
Use Copilot-style assistance when:

You need custom logic or complex features
You want to maintain architectural control
You’re building for production scalability
You have specific tech stack requirements
The key insight: don’t try to stretch a tool beyond its sweet spot. Use platforms for rapid validation, then transition to assisted coding for production development.

Lovable can get you a working prototype really quickly. It’s great for validating ideas and getting something functional fast. But when you need complex production features or have specific architectural requirements, it starts showing its limits.

Copilot excels when you maintain architectural control and can provide clear direction. It’s more like having a really smart pair programming partner than having someone else build your entire application.

Framework lock-in is real and something to think about early. When an AI platform forces you into specific tech stacks, you’re making architectural decisions that might bite you later — especially if those choices don’t align with your team’s preferences or long-term strategy.

The knowledge requirement hasn’t gone away. These tools are powerful accelerators when you understand what’s happening, but they’re not magic wands that eliminate the need for technical knowledge. If anything, you need to be even more careful about architectural decisions because AI can generate a lot of code very quickly — including bad code.

The Bigger Picture

We’re at this interesting point where AI can genuinely speed up certain types of development work, but it still requires technical expertise to use effectively. I don’t think this is a temporary limitation albeit these are the worst these tools will be— it’s probably just how these tools will work. Providing context and precise directions is inherently complex.

The teams that succeed won’t necessarily be the ones using the “best” AI tools. They’ll be the ones that figure out how to combine AI capabilities with human technical judgment most effectively.

For development teams, this means thinking strategically about which tools to use when, maintaining strong technical oversight throughout the process, and building workflows that capture the speed benefits without sacrificing code quality or architectural integrity.

What I Learned

My baby tracking app works. We use it every day, and it solves our problem perfectly. It’s still 95% vibe coded — there are definitely edges to be trimmed for it to be a good, real, stable product, but it’s free to use and does what we need.

The journey taught me that current AI development tools are powerful accelerators, not replacements for understanding how to build software.

The real opportunity isn’t finding tools that eliminate technical knowledge — it’s building systems that amplify human expertise through well-chosen AI assistance while preserving the architectural control you need for sustainable, scalable solutions.

We’re still early in figuring out how to do this well, but the patterns are starting to emerge. The key is being honest about what these tools can and can’t do, and designing your development process accordingly.

The result? A small tool we now rely on daily: NappyNotes.com — built between naps, prompts, and midnight code cleanups.

What’s been your experience with AI development tools? I’m curious where others have found the biggest gaps between the marketing promises and the development reality.

Follow me for more thoughts on AI development tools, practical technology choices, and lessons learned from building things in the real world.