A client came to us with an app an AI had built for him. It looked finished. It was even live on a server. But it could not be shipped: all the data lived in the browser, and the stack was three times heavier than the app needed. We rebuilt it in a few evenings as a lean Next.js PWA. Here is what vibe coding got right, and where it stopped.
Dags reached out with a good idea. Language schools in Vietnam constantly lose lessons because a teacher gets sick and there is no fast way to find a substitute. He wanted an app where schools post a shift and available teachers pick it up, with the local touches that matter there: integration with the chat apps people actually use, local maps, Vietnamese first. He had already built a draft with one of the popular LLMs.
Key takeaways
- An AI-built demo that runs in your browser is not a product. First question: where does the data actually live?
- Browser storage is the most common illusion in vibe-coded apps. It works perfectly until a second user shows up.
- Vibe-coded stacks run heavy. A simple app needs a simple stack, not five libraries added "in case".
- You rarely throw the AI's work away. Keep the design, replace the foundation: database schema first, then the app.
- Validating an idea with AI is smart. Shipping it still takes an engineer.
The demo that looked like a product
The draft app looked real. It had screens, flows, data that seemed to save. It was deployed on a server, which made it feel official. But it was a prototype at best, and one detail gave it away: open the app on a second device and everything was empty. The "database" was browser storage. Every user was looking at their own private copy of the world. That is the classic vibe coding illusion: the app demonstrates persistence without having any.
The stack had the opposite problem: too much of everything. To feel polished fast, the AI had pulled in a big UI component library, Redux for state, a routing library, an animation library, and a charting package that nothing used yet. For an app whose whole job is "post a shift, find a teacher, message them", that is a lot of weight to carry on cheap phones over slow connections.
The rebuild: same design, real foundation
I had a couple of free hours and the idea deserved better, so I agreed to help. We kept the design almost as it was. That part the AI did well, and it is usually the part worth keeping in a vibecode rescue.
The rebuild started where the prototype never did: a small, boring database schema. Schools, teachers, shifts, applications. A handful of tables with real relations, designed on paper before any code. Then a Next.js app on top, PWA-ready, so teachers install it from the browser like a native app, with no app stores in the way. The dependency list shrank to almost nothing.
Security got the attention prototypes never give it: real authentication, permissions checked on the server, and no write trusted from the client. In the prototype, any user could be any user, because the browser held all the truth. In production, the browser holds nothing you cannot afford to lose.
That foundation became CoverConnect, a live product. And the local integrations Dags wanted, chat apps and maps, stopped being scary. When the data model is clean, adding an integration is a normal task, not surgery.
Programming experience is still gold in the vibe era
None of this means vibe coding was a mistake. Dags validated his idea faster and cheaper than a specification document ever would, and the design survived into production. Starting with AI was the right call.
But the AI optimizes for looking done. An engineer optimizes for being done. Knowing that browser storage is a trap, that a schema comes before code, that every client request is a lie until verified: that judgment is not in the prompt. In the vibe era it is worth more, not less, because more people than ever are standing next to a demo that will not ship.
If you are standing next to one of those demos, that is exactly the work we do: we audit, stabilize, and ship AI-started projects.
Frequently asked questions
How do I know if my vibe-coded app can go to production?
Two checks: open it on a second device and see if your data is there, and ask what stops one user from editing another user's records. If the answers are "empty" and "nothing", it is a prototype.
Do I have to throw away what the AI built?
Usually no. The design, screens, and flows tend to survive. What gets replaced is the foundation: data storage, authentication, and the oversized dependency stack.
How long does a rescue like this take?
For a small app, days rather than months. CoverConnect's core rebuild took a few evenings because the schema was small and the design already existed.
Photo: Hanoi traffic by Benjamin Arnold, CC BY 3.0.