Claude (Midwife)
I’ve gone through 4 different baby monitors since becoming a parent.
The first one was the standard “use a spare iPhone as a baby monitor” app that a lot of parents default to. These work, but have obvious shortcomings – the apps aren’t very good, the iPhone has no night-vision capabilities, and at least at the time, the screen had to stay on to let the camera record, making what should be a dark nursery much brighter than it should.
Second was the Arlo camera. I don’t think they make them anymore. It was good for what it was: you plug it into power, mount it to the wall, set up WiFi, and you can connect to it with their app via the cloud. It was okay, but I didn’t like the delay (there was significant lag because the video had to be uploaded to the cloud and come back), and I just generally didn’t like having my child’s room being uploaded to a server on the Internet.
The third was an app I found on the App Store that let you use a security-type IP camera. The app was awful looking, but by far the best in terms of function. It was hard to set up, confusing to use, but it worked, and it was solid. No Internet necessary, no video to some company’s server. I used a $60 PoE camera and when our second was born, got another $60 PoE camera, and it worked great for monitoring.
When I upgraded my iPhone I went to go install it again and found that it was gone. Disappeared. I had paid for it, but now could no longer access it. I was scrambling to find an alternative. I found another junky app that worked, but they wanted $60 a year(!) for it. And no Apple Family Sharing! I lucked out and got it through some sketchy promotional discount for $10. It worked, but I hated it. I resented how the developer did it. So I decided to build my own.
An early prototype
In early 2025, before the introduction of Claude Code, I set out to build The Perfect Baby Monitor App. One that did exactly what I wanted, that was easy to set up and a pleasure to use.
I’m not a Swift engineer by trade. In fact, I never wrote any Swift before this. I wrote a couple bad iOS apps about a decade ago in Objective-C, but that was the extent of my experience.
I managed to use Claude to help me get it off the ground – the Claude chat UI was its birthplace. I copy and pasted back and forth for hours with the web UI, pasting code and error messages, trying to get something workable. I signed up for the Apple Developer account to put it on my phone. It was a little janky, but overall in the right direction for what I wanted. It wasn’t, however, something I felt confident selling for money. And I didn’t have the energy to put into doing that.
I called it BabyCam at the time. I didn’t even spend the energy trying to name it. It was just a simple app that did what I wanted.
Rebirth
Similar to my resurrection of NoraSector, I came back to it armed with Claude Code and a Max subscription. I wanted to make it right, with the level of polish worthy of an app people would pay me money for.
The first thing I did once I got started was to investigate how to fix the video player. I had used ffmpeg to handle the RTSP protocol, because it was there and it worked. There’s a bunch of issues distributing an app with ffmpeg for licensing reasons. It’s GPL, and if you know anything about software licensing, that’s the kiss of death in terms of wanting to sell closed-source software.
I had Claude rip it all out and start from scratch. RTSP is an open protocol; there’s nothing magic about it. However, I’m not familiar with it, nor am I familiar with Swift. Empowered by my new tool, I had Claude generate a native Swift implementation that handled all of it. It’s able to connect to cameras and decode H.264 and H.265 video for playback. It gave me hooks to conditionally enable video and audio processing so I could keep sound playing in the background without wasting CPU cycles decoding video frames. I was able to completely eliminate third-party dependencies from the app, and it only took about an hour.
Going back to the theme of ease of use: setting up IP cameras is at best a cumbersome process. You have to find out the IP, enter the username and password, and enter the correct path for RTSP playback (these vary by manufacturer and can be hard to find, often like /cam/realmonitor?channel=1&substream=0). I had Claude go out and find a bunch of them online, assemble them into a list, and made it easy to choose one from the drop-down while adding your camera. That seemed like about as easy as it gets, but I had even grander ambitions.
There’s a protocol called ONVIF that makes devices like IP cameras discoverable on a network. It’s a multicast protocol that uses XML. Another thing I didn’t know anything about. But also, another non-issue, with a simple prompt: okay, let's now add camera discoverability via ONVIF -- implement an ONVIF discovery mechanism and wire up dicovered cameras to the "add camera" UI, so a user can click the camera and just have to enter the username and password.
It took a couple iterations, but in another hour I was able to auto-discover cameras on my network in the app, add them to it, and stream them, all using fully-native Swift code purpose-built for what I was doing.
The same thing happened for feature after feature: live activities, audio-threshold notifications, camera volume control, screenshots. The development cycle and velocity totally changed: I was telling Claude what to do, testing it out myself, and giving feedback.
The public release
I had gotten the app into a state that I thought was saleable. For anyone who’s ever dealt with iOS baby monitor apps, this was meant to be the last one you ever buy.
I needed to brand it a little better than BabyCam, so I came up with LocalNanny. It’s not great, but it’s better, and it has a cute icon. The vibe of the app is meant to be a friendly app for monitoring your baby. Now that I had a name, I needed a website (it actually isn’t optional; Apple requires you provide a privacy policy URL).
I had Claude generate a static Hugo website meant to sell the product. We went back and forth over the content, over the design, SEO strategies, all of it. It’s again an iterative process, but the cycle is so fast and so easy, you just want to polish every last detail. You can see it at localnanny.app.
One thing I will admit: the copy on the LocalNanny site is all AI-generated. I haven’t opened up any of the content files in an editor and changed them. I’ve given feedback and had Claude phrase things how I want, but this was an experiment in maximal productivity using AI. And overall, I think it did well. It did the work, and I validated it by proofreading and giving feedback.
I even had it generate educational content for what types of camera to buy, options for how to wire it (or use WiFi), differences in streaming protocols, etc. This partially serves as SEO content, but also is truly useful for someone figuring out if this is the right product for them.
The coolest thing I did was have Claude go through the app’s codebase, generate a user manual as a markdown file, and then take that markdown file and transform it into a file consumable by Hugo. The user manual is pulled directly from the source code, and I can update it whenever I add new features to the app in minimal time. This is the type of drudgery that in the past I’d just never do: the actual value is somewhat low, and the work involved is very high. The calculus on that type of thing has totally changed.
One of my favorite things to do with Claude is to have it generate custom SVG graphics for icons. At first it was using emojis, but they didn’t quite match the theme – every icon on the website is custom, and I didn’t spend a second in an image editor. Even the app’s logo is AI-generated.
Is it really vibecoding?
To a certain extent, yeah. I don’t know exactly how everything works. But I knew what I wanted, and iterated until I got that built. I know what to look for in terms of making sure it’s correct. Does the UI behave as I expect it to? Is the resource consumption in line with what I expect? How should it handle edge cases? What are the limits I want to put on the free vs. paid versions? I have it do audits to find bugs, find security issues, etc., but I am not dealing with the code directly. I don’t have to. I don’t really even want to.
The real question is: does it actually provide value? Is it just slop?
If I shipped what I had prior to bringing it back to life with Claude Code, it was absolutely slop. The userbase was myself and my wife.
When you ship a product to other people who are paying your money, your standards increase dramatically. There isn’t an excuse for little bugs or misbehavior. It should be the best product it can be.
To that end, Claude not only generated the code, but it fixed its own mistakes (with my testing and guidance, of course). My role is really product manager. I come up with the requirements, hand them off to the engineering team, then test and validate them and have any bugs I find fixed.
Here’s a good example: what happens if the user has a camera in fullscreen, with the audio alert overlay up, then swipes out of the app, gets a push notification for another camera, and wants to open up into that? i think it should dismiss the overlay, not save anything, close the current fullscreen, and then open the other camera
Claude can go trace through the code to find out what happens in that scenario, see how it behaves, and fix it to behave as I want it to. Then I just test it to make sure it works.
There’s a lot of these interactions in an “agentic development workflow.” Handling edge-cases has always been a big part of software development, and now you can focus on discovering edge cases, and let Claude focus on fixing them.
Compared to my experience with using Claude to revive NoraSector, I didn’t really find anything that Claude just couldn’t do. To be fair, this is a much simpler project, but I was always able to work through the problems I had and fix them. It was genuinely cool.
The Future
Having to wear the hats of both product manager and engineer can be painful for a developer working on a project like this. You know what you want for the product, but you also know the engineering tradeoffs. You want this thing to do that? That’s eight hours of work. So maybe you cut it, because you don’t want to invest the time.
That excuse doesn’t really exist anymore. Your value now becomes acting as the product manager and letting Claude be the engineer. I knew what I wanted, but didn’t know how to do it. Claude could do what I wanted, but didn’t have a real vision for it. But together, we built something that I think is truly a great product.
My value in this project remained the same as if I had written all the code myself: I delivered a great product. That’s all users care about. They don’t care about the code. They don’t care about custom RTSP implementations. They don’t care about anything but whether or not the product’s great. And the only way to have a great product is to have a great vision, something that you as a human are only capable of providing.