From vibe-coded app to production: a checklist

An app built quickly with AI coding tools is ready for production when strangers cannot read each other's data, failures are noticed and recoverable, and someone other than the original prompt history can deploy and change it. This checklist covers the checks we run first, grouped by risk, so you can work through them in order.

It is written for founders and small teams who built something that works in demos and now want real users on it. You do not need to be an engineer to use it, but you will need someone technical to fix what it finds.

Why do AI-built apps break in production?

AI coding tools optimise for the request in front of them. Ask for a sign-up page and you get one that works when everything goes right. What you usually do not get, unless you ask for it explicitly and check the result, is the invisible work: authorisation on every request, validation of every input, handling of failures, and a way to rebuild the app from scratch. Demos never exercise those paths. Real users do, on the first day.

1. Security and access

Start here, because these problems can hurt your customers, not just your app.

• Every page and API endpoint checks who is asking and whether they may see or change that record, not only whether they are signed in.
• No secrets, such as API keys, database passwords or tokens, are stored in the code, in the browser or in the repository history.
• All user input is validated on the server, including file uploads.
• Passwords, if you store them at all, are handled by a proven authentication service or library.
• Dependencies are up to date and free of known critical vulnerabilities.

A quick test: sign in as one user, copy the address of something that belongs to you, sign in as another user and open it. If it loads, stop and fix access control before anything else.

2. Data and backups

• The database has a clear structure, with constraints that stop obviously wrong data from being saved.
• Changes to the database structure happen through migrations that can be repeated, not by hand.
• Automatic backups exist, and you have restored one at least once.
• You know what personal data you store, why, and how you would delete a user's data on request.

3. Reliability and errors

• Every external call, whether to payments, email, AI models or other APIs, has a timeout and a sensible behaviour when it fails.
• Users see a helpful message when something goes wrong, not a blank page or a stack trace.
• Long-running work, such as imports or AI processing, runs in the background and can be retried safely.
• Payments and other money-related actions cannot happen twice when a user double-clicks or a request is retried.

4. Performance

• The main pages load quickly on a mid-range phone over mobile data.
• Lists are paginated, and database queries on growing tables use indexes.
• Images are resized and served in modern formats.
• Calls to AI models are cached or rate-limited where the same answer is requested repeatedly.

5. Deployment and configuration

• The app can be deployed from the repository with one repeatable command or pipeline.
• Configuration for development, staging and production is separate, and production secrets live only in the hosting provider's settings.
• A new developer can set the app up locally from written instructions.
• There is a way to roll back a bad release.

6. Monitoring

• Errors in production are reported to a tool that alerts someone.
• You can see whether the app is up without opening it yourself.
• Logs help you understand a problem without containing passwords, tokens or unnecessary personal data.

7. Code you can hand over

• The code is in a repository you own, with a readable history.
• The flows that matter most, such as sign-up, payment and the core feature, have automated tests.
• A short document explains how the app is structured and why key decisions were made.
• Dead code and abandoned experiments from earlier prompts have been removed.

What should you fix first?

Fix in this order: anything that exposes one user's data to another, then anything that can lose data, then anything that can take money twice or not at all, then anything that stops you from deploying safely. Performance and tidy code matter, but they can wait a week. Data leaks cannot.

If the list above feels long, that is normal. Most AI-built apps pass some sections and fail others. The point is to know which ones before your users find out.

When should you ask for help?

Ask for help when you find an access-control or data problem you do not know how to fix, when you are about to take payments, or when nobody on the team can confidently deploy the app. That is exactly what our From Prototype to Production service is for: an audit against a checklist like this one, a ranked report, and fixes for the issues that matter, so your app holds up with real users and real data. If you are still at the idea stage, our guide to what drives the cost of an MVP may help you plan.