Five weeks. One product. A mountain of tiny changes. And at the end of it, something real out in the world: actual businesses, actual bookings, actual money changing hands.
We set out to build a booking tool for small businesses. Restaurants, car rental shops, mechanics, small wellness studios, the kind of places that still take half their bookings over the phone. And from day one, we had AI helping us write it.
This is what five weeks of vibe coding a real SaaS product taught us. (Vibe coding, if the term is new to you, was coined by Andrej Karpathy for building software by describing what you want and letting AI write it.)
This is not a how-to. It is a postcard from the far side of the experience. Here is what worked, what went sideways, and what we would do differently if we started over tomorrow.
Vibe coding is not making a wish and hitting go
There is a cartoon idea of building with AI: you type what you want, it hands you the finished thing, you ship it, done. That is nothing like how it actually felt.
It felt more like working next to someone who types ten times faster than you, has somehow read every answer ever posted online, and never gets tired. The catch? That same person has zero context on your business, your setup, or why you made some odd decision six weeks ago.
So we fell into a rhythm. Say what you want. Look at what comes back. Tweak it. Repeat. Sometimes that meant pointing at the screen and saying "no, lose that." Other times we described a whole feature in one sentence and watched it appear.
But the real calls, what to build, how to put it together, whether it was even worth doing, stayed with us. AI touched nearly everything. We never once accepted something with our eyes shut.
AI does not make mistakes the way people do
This is the one that really stuck with us.
The same sneaky bug showed up twice, in two completely different corners of the app, weeks apart. Both times the code looked perfectly fine. Tidy. By the book. It would have sailed past a quick review with no trouble.
But in certain real-world moments, a message to a customer would simply not send. No error. No alarm. The customer just never heard from us.
That is the strange thing about AI bugs. They are hardly ever typos or obviously broken code. They are neat little traps: code that looks right because it copied the right shape, but quietly misunderstands how things actually play out once real people are using it.
The "look, it works" version looks flawless, which is exactly why these slip through. We are not alone here: in Stack Overflow's 2025 developer survey, most developers use AI daily but only a minority actually trust its output, and "almost right" code is the top complaint.
The takeaway: reviewing AI-generated code is not about whether it looks right. It is about knowing how it will actually behave once it is live.
Your notes turn out to be the real treasure
All through the project we kept a growing stack of notes, dozens of small files. Nothing formal. More like the stuff that usually lives in a seasoned engineer's head and walks out the door the day they quit.
A few favorites:
- "Deleting something does not always delete it." We cut a piece out of the dashboard during a cleanup and pushed the change. It kept showing up. The way we were shipping updates left the old version hanging around like a ghost. Now we double-check that deleted things are actually, properly gone.
- "Do not get too clever trying to make things fast." We tried to speed up the dashboard by saving bits of it to reuse later. Reasonable on paper. In practice it crashed the whole thing after an update. Some things are not meant to be cached; you have to build them fresh every time.
- "You do not always know which version is live." Because of how we shipped updates, there was no easy way to answer a dead-simple question: what is actually running right now? So we rigged up a small trick to find out. Boring problem. Strangely annoying.
Every note had the same shape: here is the rule, here is the painful story behind it, and here is when it actually matters. That last part, the why, is what makes a note worth keeping.
Without it, you are following instructions you do not understand, which means you will never know when it is safe to break them.
Two AI sessions at once equals pure chaos
When we were really flying, we tried having two AI sessions work on the same project at the same time. It went exactly as badly as you would guess.
One session would change something. The other, completely oblivious, would change the same thing. Then they started stepping on each other's half-finished work and occasionally mashed it all into one confusing mess.
The fix was plain discipline: look before you touch, only touch what you meant to touch, and the second you spot something off that you did not do, stop and figure out why before going further. If you genuinely need two things happening at once, give each one its own sandbox.
AI helpers have no sense that someone else might be working in the same spot. You have to be the grown-up in the room.
"It says everything is fine" does not mean everything is fine
After one update, our automatic health check came back green. Great. Ship it. Meanwhile, every single image on the platform was broken.
The check only confirmed the app had switched on. It never actually walked around and made sure the real things worked. So a broken piece strolled right past it, because nothing tested that piece until a real human bumped into it.
Now every update runs a quick smoke test that actually walks through the thing we just changed. "It passed the health check" turned out to be the modern version of "well, it worked on my machine."
The WhatsApp saga nearly broke us
This one gets its own section because, honestly, it was the most maddening part of the whole build.
The platform sends customers WhatsApp messages: booking confirmations, reminders, that kind of thing. To do that officially, your message templates have to be pre-approved by Meta. Fair enough. Here is where it gets fun.
Once a template is approved, it is locked. Forever. Spot a typo? Want to fix a link? Too bad. You can not edit it. You have to submit a brand-new version and wait a day or two for someone to review it.
You can only send a handful for review at a time, and we needed nine to cover everything. That is several rounds, with a day or two of waiting between each. And if one gets rejected, you go back to the end of the line.
One wrong setting cost us two days. A template once went out for approval pointing at our test setup instead of the real one, which meant customers tapping the button in WhatsApp landed somewhere completely wrong.
The only fix was to submit a fresh version with the right link and wait, again, for approval. Two days of broken buttons. After that we made it an ironclad rule, written in big letters: these only ever go out from the real environment. Some mistakes you only need to make once.
There was a second trap, too. Each WhatsApp message costs a little money, so we built a safeguard so the same one can not go out twice by accident. Handy, except when a message genuinely fails and you need to resend it on purpose, you have to switch off the safeguard first, or the system insists it already did its job.
The whole WhatsApp ordeal taught us something bigger: the hardest parts of building a product usually are not in your own work. They are in the gaps between your stuff and the systems you do not control, the approval queues, the things you can not undo, the rules nobody bothered to write down.
That is where experience beats raw speed.
Security settings will humble you
There is a whole layer of behind-the-scenes safety settings meant to keep a website secure, things like a Content-Security-Policy. It also broke our admin panel more times than any actual feature ever did.
The worst part was how quiet the failures were. Something would simply stop working for no obvious reason, and we would lose an afternoon hunting for the cause. We eventually built something to wrangle it, but it still needs a human keeping an eye on things. There is no "set it and forget it" here.
This matters more with AI in the mix, because vibe-coded apps carry real security risks of their own. AI will happily generate code that works and is quietly insecure, so someone who understands the security layer has to review it.
Most of the job is not even the building part
When we looked back over everything we had written down, the split was a surprise:
- Roughly 20% was actual new features.
- About 30% was fixing bugs.
- A solid 50% was the unglamorous behind-the-scenes plumbing.
In five weeks we moved where the whole thing lived, set up backups, wired up alerts for when things break, sorted out all the shipping-updates machinery, and a dozen other things nobody ever sees.
The flashy features were a thin slice. Keeping the thing alive and reliable was the actual job. If you are budgeting time to ship a minimum viable product fast with AI, budget for this part first.
You still have to truly understand your tools
This is the big one. AI made writing code far easier. It did absolutely nothing to make understanding code easier.
Every real problem we hit needed us to actually know how things worked under the hood: how the moving parts behave, how a website handles security, how time zones quietly wreck your day when you least expect it.
The AI handed us code that looked right every single time. The bugs only turned up once real people started poking at it.
The speed is real, but it costs you something
We were making something like eighteen changes a day, five weeks straight. AI took a huge amount of the boring heavy lifting off our plate, which genuinely freed us up to think about the hard stuff.
But moving that fast leaves marks. The product works, but you can see the fingerprints of how quickly it came together. Some corners are smoother than others. And for something this young, that is fine. Right now, speed matters more than polish.
What we would tell you before you start
Building with AI does not remove the need for good judgment. It just gives you a lot less time to use it.
The mistakes we made were not really "AI mistakes" or "our mistakes." They lived in the space between, the handoff moments where we assumed the AI understood something it really did not.
If we rebuilt this whole thing today, it would take about two weeks. Not because we would type faster, but because we now know exactly where the landmines are buried. And in the end, the most valuable thing we walked away with was not the code. It was knowing what breaks.
Build fast. Write down what breaks. Ship with your eyes wide open.
Want to ship your MVP without the landmines?
This is exactly how we build for clients: move at AI speed, but with people who understand every moving part before it reaches your customers. We help founders take an idea from sketch to a real, launched MVP, the booking flows, the integrations, the unglamorous plumbing, all of it.
If you are planning to build or ship a product, let us help you skip the two days of broken buttons. Book a free audit and MVP scoping call, and we will map the landmines before they cost you.