I "vibe coded" (and shipped) my first app. Here’s what I learned, and why you should try it.

A few months ago I decided to see if I could build an actual iPhone app using AI.

Why I built it

The idea came from a pretty specific problem.

My friends and family are hobbyist winemakers. Every year we get together and make our own wine, usually by the barrel. One barrel can eventually turn into upwards of 240 bottles that get divided among everyone involved.

It’s a fun hobby, but there’s a surprising amount of logistics behind it.

You have to decide what you’re making and who is participating in each barrel. There are costs to split and bottle allocations to remember. Then there are dates for crushing, pressing and bottling, months of aging in between, and eventually years of vintages you want to keep a record of.

Most of this was living in spreadsheets, text messages, notes and people’s heads.

We needed a better way to manage it.

That became Vino Tracker.

(You can download & rate it on the App Store today 😎.)

I wanted one place where our little winemaking community could track what we were making, manage the logistics, split costs and bottles, plan the important dates and eventually have a history of everything we’d made together.

It also gave me an excuse to test something I’d been curious about.

Could I actually build and ship this myself with AI?

Why I started with Vibecode App

I ended up using Vibecode App mostly because it was easy to get started.

There wasn’t some big evaluation process behind the decision. I found it, downloaded the app and started building.

Being able to do a lot of the work from my phone was a bigger plus than I expected. I already spend enough of my day sitting in front of a computer for work. I wasn’t looking for a side project that required me to spend another four hours at my desk every night.

With Vibecode, I could describe what I wanted, let the agent work, test the result on my phone and keep going. I’d work on Vino Tracker from the couch, sitting outside by the pool, laying in bed, or whenever I had some time.

That made it much easier to keep momentum.

And for someone who didn’t want to start by setting up a development environment and learning a bunch of tools, it was a very low-friction way into building an actual app.

Not a mockup. Not something that only worked on my phone. I wanted a real product in the App Store that my friends and family could download, create accounts for and actually use.

Turns out, you can get surprisingly far.

I don’t know React Native. I couldn’t have built the backend myself. But I understand technology and products well enough to describe what I wanted, test what came back and keep iterating.

Getting to a working app is incredibly fast

Within a relatively short period of time, I had a working app.

Then I started adding accounts, Google sign-in, shared cellars, different permissions, sorting and filtering, wine tracking, bottle and cost allocations, and eventually the ability to import existing wine records from photos and documents.

A feature could go from an idea in my head to something running on my phone surprisingly quickly.

Then other people started using it.

That’s when the project got more interesting.

Someone already has years of wines sitting in a spreadsheet? We should be able to import them.

We wanted the option to give people read-only access to the cellar so they could see everything without editing anything. (Looking at you, Dad 👀)

The import gets someone’s name wrong? Now we need a way to correct the data afterward.

You start discovering all the little things that weren’t part of your original idea because you were the only user when you designed it.

I think that’s one of the best parts of doing a project like this. You’re learning to build with AI, but you’re also learning how to think through an actual product.

Then you have to debug the thing

The speed can also get you into trouble.

At one point authentication stopped working in Apple's TestFlight version of the app.

I spent a ridiculous amount of time and credits trying to debug it with Vibecode.

We’d diagnose something, make a change, rebuild the app and test it again.

Still broken.

We added diagnostics. Changed authentication code. Tested different scenarios.

Burned more credits.

Eventually we figured out what was actually happening.

The production server was down.

The coding environment could successfully test against its preview server, but the production server that the actual TestFlight app was talking to was returning 502 errors.

Even better, neither I nor the coding agent had access to restart it.

Vibecode hides a lot of the infrastructure from you. That’s part of what makes the product so easy to use in the first place. You can start building without knowing how to configure servers, databases or deployment pipelines.

But I didn’t really understand the downside of that abstraction until something underneath it broke.

I was asking AI to debug a production environment it couldn’t actually control.

Eventually I had to contact the Vibecode team and have them restart the production server.

Problem solved.

(After burning a bunch of credits trying to diagnose it, I got about $10 back 😂.)

Annoying experience, but probably one of the more useful things that happened during the project.

I understood all of these concepts at a high level before. Frontend, backend, database, authentication, preview environments, production environments.

It’s different when your own app doesn’t work and you have to figure out which one is broken.

I got better at using the AI

The experience also changed the way I started using the AI.

Vibecode uses Claude Code (Opus 4.5) underneath to do much of the actual coding. Early on, I treated the coding agent almost like I would a normal LLM. I’d explain what I wanted and let it go.

That isn’t always a great way to build software.

As the app became more complicated, I started doing more of the planning outside Vibecode.

I’d work through a feature or bug with ChatGPT first. We’d think through what the user should experience, what might break, what the underlying data needs to do and how we’d actually verify the feature worked.

Then I’d give Vibecode a much more specific prompt.

Sometimes I’d take Vibecode’s response back to ChatGPT and have it challenge the solution before I made another change.

AI managing AI sounds a little ridiculous, but it made me much more effective.

Funny enough, vibe coding has made me want to go deeper on some of the software development concepts I’ve only had light exposure to.

I know enough to follow what’s happening, but building and debugging a real app made me want a better understanding of what sits underneath the AI so I can use these tools more effectively.

The more I understand, the better questions I ask. I can recognize when something doesn’t sound right. I know what to check before spending another hour and another pile of credits trying fixes.

Design still needs a human

I learned something similar with design.

AI can get you to a good-looking interface very quickly. Vino Tracker looked surprisingly polished early on.

But it also had that strange feeling where you could somehow tell AI had designed it.

Nothing was obviously bad. It just felt...generic.

Getting from “this looks like a nice app” to something with its own identity requires more deliberate design work. That’s something I want to spend more time on next.

Shipping was more tedious than building

Then there was actually getting the thing into the App Store.

That may have been the most tedious part of the entire project.

TestFlight builds, screenshots, privacy information, authentication configuration, certificates, signing and all the other iOS requirements took more effort than I expected.

There is a big difference between having an app working on your phone and having something another person can search for in the App Store and download.

Next time I’ll use agents much earlier in the process to help create, check and manage more of those requirements.

The cost adds up

The other lesson was cost.

I started on Vibecode’s $20/month plan.

As I got more serious and wanted to keep momentum, I moved to $50.

During one particularly heavy stretch of coding and debugging, I went all the way up to the $200 plan.

That’s when you start paying attention to how efficiently you’re using the agent.

When something is genuinely complicated, spending credits while the AI works through it is fine. When you’re spending credits because the agent is debugging the wrong server, it feels very different.

That’s also part of why my next experiment will probably be moving the code into something like Cursor and taking more direct control of the development, deployment and production environment myself.

I’m sure that will come with its own set of problems.

Why I think this is worth doing, even if you don’t want to build apps

Despite all the things that went wrong, I’d recommend doing a project like this to almost anyone who is curious about AI and technology.

And I don’t think you need to have any intention of becoming a developer.

Pick something you actually want to exist and try to build it.

Then don’t stop when you get a cool prototype working.

Try to ship it. Get another person to create an account. Watch them use it without explaining what every button does. Have them find something you never thought about. Fix it and give it back to them.

That’s where I’ve learned the most.

You start understanding the technology better because you have a reason to. You start thinking about product decisions because actual people are using what you made. You see how much work exists between having an idea and giving someone something they can actually rely on.

I think that experience is useful in almost any career now.

You’re practicing how to take a vague idea and make it concrete. You have to think about the user, break down problems, give AI good direction, judge the output, troubleshoot when it goes wrong and keep improving the thing based on actual feedback.

Those are useful skills whether you work in technology, operations, finance, marketing, healthcare or just about anything else.

You understand AI differently once you’ve used it to build something real.

Somewhere along the way, Vino Tracker also stopped being just my experiment with vibe coding.

We’re actually using it to manage our wine. Other people are joining cellars, importing their vintages and tracking what they’re making.

Seeing someone else use something that started as an idea in your head is pretty cool.

Next up: vibe marketing your product 🙂

That’s another post.

P.S. For anyone curious, this year at Cirillo Vineyards we’re making a Cabernet Sauvignon from Beckstoffer Vineyards in Napa Valley. If you’ve never read about Andy Beckstoffer and the influence he’s had on Napa, it’s worth a look. Pretty cool story.