In short
- Vibe coding is great for prototypes. The gaps show up when real users, data and payments arrive.
- Security comes first: exposed keys, missing permission checks and open database rules are the most common problems.
- You can't fix what you can't see, so add error tracking and logs early.
- Tests are what let you keep changing the app without breaking it.
- Many apps can be hardened. Some parts are quicker to rebuild than to patch.
- Keep using AI to build, with a senior engineer reviewing every change.
What vibe coding is
Vibe coding means building software by describing what you want to an AI tool, like Cursor, Lovable, Bolt, Replit or Claude Code, and letting it write the code. You can go from idea to working screens in days. That's real value: you can test an idea with users before you spend months on it.
The catch is that AI tools build what you ask for, and founders rarely ask for security rules, backups or error handling. The app works in a demo, then struggles when real people use it.
What usually breaks with real users
These are the problems we see most often when we review a vibe-coded app:
- Exposed secrets. API keys for AI models, payments or email sitting in the front-end code, where anyone can copy them.
- Missing permission checks. A user can see or change another user's data by changing a link or a request.
- Open database rules. With tools like Supabase or Firebase, the database's access rules are often left open or switched off.
- No error handling. When something fails, the app shows a blank screen and nobody finds out.
- Slow pages as data grows. Queries that were fine with 50 records slow to a crawl with 50,000.
- Payments and webhooks that miss edge cases. Failed cards, refunds and repeated events that create duplicate orders.
- AI costs nobody watches. No limits on model usage, so one busy day or one bad loop runs up the bill.
- Code nobody fully understands. The same logic copied in several places, so every fix risks breaking something else.
The production-ready checklist
| Area | What to check | Why it matters |
|---|---|---|
| Security | Secrets on the server only, a permission check on every request, database rules switched on | Stops data leaks and account takeovers |
| Data | Daily backups, a clear data model, safe changes to the database | You can recover from mistakes |
| Errors and monitoring | Error tracking, logs and alerts | You hear about problems before users do |
| Tests | Automated tests on key flows like sign-up, payment and the core task | You can change the app without breaking it |
| Performance | Indexes on busy queries, paging for long lists, caching where it helps | Pages stay fast as data grows |
| Payments | Failed payments, refunds and repeated webhooks handled | Money moves correctly every time |
| AI usage | Limits, the right model per task, cost tracking | No surprise bills |
| Code and handover | Clear structure, one place for each rule, notes on how it all fits | A team can maintain it |
Fix it or rebuild it?
Most apps don't need to start over. A good rule:
- Harden it when the core works, users like it, and the problems are in security, testing and monitoring. Those can be added.
- Rebuild a part when one area, often the data model or payments, is too tangled to fix safely.
- Rebuild the app when it was a prototype that proved the idea but can't support a secure launch, as an AI web app, an AI mobile app or an AI SaaS product.
Two real examples:
- Sentré started as a no-code prototype. It proved the idea but couldn't support a secure launch with identity checks, background screening and escrow payments. We rebuilt it as a native iOS and Android app with AI-assisted development and launched it on both stores in 8 weeks.
- Clicked kept its Bubble.io app and we strengthened it instead. It now serves 60,000+ learners, with automated partner reports that cause no slowdown on the live app.
How we take an app to production
- Audit. We read the code, the database rules and the setup, and list every risk in order of how much it matters.
- Fix security first. Secrets, permissions and database rules, before anything else.
- Add a safety net. Error tracking, logs, backups and tests on the key flows.
- Fix what slows it down. Database queries, large lists and heavy pages.
- Clean up the code. One place for each rule, so changes stay safe.
- Hand over. Your code, your accounts and clear notes, so you're never locked in.
How to keep building with AI, safely
Vibe coding doesn't have to stop once the app is live. We build with AI coding agents like Claude Code and Codex every day. What changes is the process around them:
- A senior engineer reviews every change before it ships.
- Tests run on every change, so nothing breaks quietly.
- New features go to a test version of the app first, then to real users.
- Secrets live on the server, never in the code you ship.
See AI-assisted software development for how we work.
Questions people ask
- Is code written by AI bad code?
- Not by default. It's often fine for what it was asked to do. The problems come from what nobody asked for: security, tests and handling things that go wrong.
- Can you take over an app built with Lovable, Bolt, Cursor or Replit?
- Yes. We start with an audit of the code and setup, then give you a clear plan: what to fix now, what can wait and what, if anything, is worth rebuilding.
- How long does it take to make an app production-ready?
- It depends on the size of the app and what the audit finds. The audit itself is quick, and security fixes come first, so the biggest risks are closed early.
- Should we stop using AI tools to build?
- No. AI tools make building much faster. Keep using them, with a person reviewing changes and tests running on every update.