The short answer
Vibe coding, building an app by describing it to an AI tool, is a fast way to get a working demo. What it does not give you by itself is the part users never see: access rules, protected secrets, backups, tests and a safe way to release changes. Before real users or real data arrive, review those five areas, fix what is unsafe, and rebuild only the parts that cannot be made sound.
Key points
- A working demo proves the idea. It does not prove the app is safe to run.
- Check access rules and exposed keys before anything else.
- Most AI-built apps need hardening, not a full rewrite.
- Keep the flows users already know. Replace the fragile parts underneath.
- Move the code into a repository you own before changing it.
What vibe coding is good at
Vibe coding means describing what you want in plain language and letting an AI tool write the code. The term came from Andrej Karpathy in early 2025, and tools such as Lovable, Bolt, Replit, Cursor and Claude Code have made it a normal way to start a product.
It is very good at the first version. A founder can go from an idea to screens that work in days, show it to users, and learn whether anyone cares. That is real progress, and it is often the right first step. The trouble starts later, when the demo becomes the product.
What usually breaks with real users
- Access rules. The app shows each user their own data, but nothing on the server stops one user from requesting another’s. Broken access control is the first item on the OWASP Top 10 list of web application risks.
- Secrets in the wrong place. API keys for payments, email or AI models end up in code the browser can read, or in a public repository.
- No safety net. No backups, no error alerts, no logs. The first you hear of a failure is a user telling you.
- Changes that break old features. With no tests, every new prompt can quietly undo something that worked last week.
- Costs with no ceiling. An AI feature with no spending cap or rate limit can run up a bill overnight.
- One environment. Changes go straight to the live app, so every experiment is run on your customers.
None of this means the tool was bad. These are the parts a demo does not need and a product does.
What to check first
- Sign in as one user and try to open another user’s record by changing the ID in the address bar. If it loads, stop and fix that before anything else.
- Search the code and the browser’s network tab for keys and passwords. Rotate any that were exposed.
- Confirm the database is backed up, and restore a backup once to prove it works.
- Put the code in a GitHub repository you own, so every change is recorded and can be undone.
- Set a spending cap on every paid API, especially AI models.
- Add error alerts, so a failure reaches you before it reaches a review.
Fix it or rebuild it?
| Signal | Usually means |
|---|---|
| The data model is sound and the problems are missing rules and tooling | Harden what you have. |
| One area, such as payments or sign-in, is unsafe but the rest holds | Rebuild that part, keep the rest. |
| Every change breaks something else and nobody can explain the structure | Rebuild the core, keep the screens and flows. |
| The builder cannot do something the product needs | Move to code you own. |
A full rewrite is rarely the first answer. Users already know the flows, and those flows are the most valuable thing the prototype produced. The usual path is to keep the screens, move the users and data, and replace the fragile parts underneath, most risky first.
Start with a written review. Before we touch a no-code or AI-built product in MVP development, we read what is there and say what we would keep, fix or rebuild. If the prototype can carry v1, we leave it alone.
AI is still part of the answer
The lesson is not to stop using AI to write code. It is to put an engineer between the AI and your users. AI drafts quickly. A person who understands the system reviews every change, writes the tests, and decides what is safe to ship. That is how we work, and it is why faster drafting does not have to mean a weaker product.
Sources
Checked when this guide was written.