Taking a vibe-coded app to production: a 25-point checklist

AI app builders and coding agents have made it possible to go from an idea to a working app in a weekend. That is a real change, and a good one: founders can now test ideas with real users before spending serious money.

The trouble is that "working" and "ready for customers" are not the same thing. AI tools are very good at producing code that does what you asked for in the demo. They are much less reliable at the things nobody asked for, such as stopping one customer reading another customer's invoices.

This is the checklist we use as the starting point for our vibe code reviews. Work through it before you launch, or before you start charging.

Security

These are the issues that can end a young business, so start here.

1. Every request checks who is asking. Open your app in a private window and try visiting a page you should only see when logged in. Then try the same with the API endpoints your front end calls.
2. Every record checks who owns it. Log in as one user, copy the URL of one of their records, then log in as a second user and paste it. If you can see the first user's data, you have an authorisation problem. This is the single most common serious issue we find.
3. No secrets in the browser. API keys for your database, payment provider or AI service must live on the server. Search your front-end code for strings like sk_, key and secret.
4. Database rules are switched on. If your app talks to a hosted database such as Supabase or Firebase directly from the browser, row-level security or equivalent rules must be enabled and tested.
5. Passwords and sessions are handled by a proven library. Hand-rolled login code is a red flag.
6. File uploads are restricted. Check file types and sizes on the server, and store uploads outside the public web folder.
7. Dependencies are real and current. AI tools sometimes suggest packages that do not exist, or very old versions of ones that do. Run your package manager's audit command and check anything unfamiliar.

Data

8. Backups run automatically, and you have restored one. A backup you have never restored is a hope, not a backup.
9. Personal data is mapped. Know what personal data you collect, where it is stored and who can access it. Under UK GDPR you need a lawful basis for each type and a privacy notice that explains it.
10. Deleting means deleting. When a customer closes their account, their data should go with it, or be anonymised.
11. Production data stays in production. Developers and AI tools should work with test data, not copies of real customer records.

Payments

12. Payment results are confirmed on the server. Never trust the browser to say a payment succeeded. Use your payment provider's webhooks.
13. Webhooks are verified. Check the signature on every webhook so nobody can fake a "payment succeeded" message.
14. Failed payments are handled. Decide what happens when a card is declined at renewal, and test it.
15. Prices live on the server. If the price is sent from the browser, someone will change it.

Reliability

16. Errors are tracked. Install an error tracking service so you hear about problems before your customers tell you.
17. Uptime is monitored. A simple external check that alerts you when the site goes down.
18. Slow work happens in the background. Sending emails, calling AI models and processing files should run in a queue, not while the user waits.
19. There is a staging environment. Somewhere to try changes before they reach customers.
20. Deploys are repeatable. You should be able to deploy with one command or one click, and roll back just as easily.

Maintainability

21. The code is in Git, in an account you own. Not only in the AI tool's workspace.
22. There are tests for the paths that make money. Sign-up, login, checkout and the core feature, at minimum.
23. The structure is consistent. AI tools often solve the same problem three different ways in one codebase. That makes every future change slower and riskier.
24. Someone can explain how it works. If the only explanation is "the AI wrote it", plan time to document it.
25. You know which parts are fragile. Every codebase has them. The danger is not knowing where they are.

What to do with the results

If you can tick most of these, you are in better shape than many funded startups. If you cannot, do not panic. Most of these problems are quick to fix once you know they are there, and fixing them before launch is far cheaper than after a breach or a lost customer.

There are three common routes from here:

• Fix it yourself, using this list, if you or your team are comfortable with the code.
• Get an independent review. Our vibe code review costs a fixed £395 and gives you a ranked list of what to fix, with the critical issues explained in plain English.
• Rebuild the core properly, using the prototype as a detailed specification. For some apps this is the cheaper option, and our MVP development service is designed for it.

Whichever you choose, keep using AI tools. They are not the problem. The problem is shipping code that nobody with the right experience has checked. Our guide to AI-driven development guardrails explains how to keep the speed without the risk.