With AI app builders and coding assistants, you can go from idea to working product in a weekend. Tools like Lovable, Bolt, Cursor and Claude generate screens, database tables and API routes faster than any team could type them. The result often looks finished: it logs users in, saves data and gets through the demo.

Real users will test much more than the demo does. Production readiness covers what happens when someone enters unexpected input, a third-party API times out, two users edit the same record, or a curious visitor opens the browser developer tools. Generated code usually handles the happy path well and everything else unevenly.

This checklist is for founders, CTOs and product owners who have a vibe-coded app and need to decide whether it can take paying customers, sensitive data or a marketing launch. Be honest as you work through it. Every unchecked item is a risk you are choosing to carry, and some of them are cheap to fix.

How to use this checklist

Go through the sections in order. Security comes first because one gap there can end a young product, which a slow page rarely does. Mark each item as done, not applicable or unknown, and count "unknown" as not done. If nobody on the team can say whether database access rules are enforced, assume they are not.

A long list of unknowns is normal for an app built quickly with AI tools. A structured code audit for an AI-built app is designed for exactly that situation.

1. Security: authentication, secrets and access rules

Generated code falls short here more often than anywhere else, because it works perfectly for the developer who wrote the prompt while logged in as themselves.

Authentication

  • Users authenticate through a proven provider or library. Nobody hand-rolled the password scheme.
  • If you store passwords at all, the auth library hashes them with a modern algorithm, and they are never stored or logged in plain text.
  • Sessions and tokens expire, and logging out really invalidates them.
  • Password reset and email verification flows cannot be used to take over someone else's account.
  • Admin features are protected on the server. Hiding them in the interface is not protection.

Secrets

  • No API keys, database credentials or service tokens are committed to the repository, including its history.
  • No secret keys ship in the browser or mobile app bundle. The only keys in client code are ones designed to be public, such as a publishable key with restricted scope.
  • Secrets live in environment variables or a secret manager, with separate values for development and production.
  • Any key that was ever exposed has been rotated. Deleting it from the code is not enough.

Access rules and authorization

  • Every API endpoint and database query checks that the current user may read or change that specific record.
  • If the client talks directly to a backend-as-a-service database, row-level access rules are enabled on every table and tested with a second user account.
  • Changing an ID in a URL or request does not reveal another user's data.
  • File storage buckets are private by default, with access granted per user or per object.
  • Public endpoints that send email, create accounts or call paid APIs are rate limited.

Here is a practical test. Create two ordinary user accounts, log in as the second, and use the browser's network tab to try to read and modify the first user's data. If anything leaks, stop and fix it before launch. The OWASP Top 10 is a good reference for the categories of problems to look for, and broken access control sits near the top of it for good reason.

Dependencies

  • Every package is real, maintained and actually used. AI tools sometimes suggest packages that are outdated or do not exist, and unused ones add risk with no benefit.
  • A dependency vulnerability scan runs automatically, and known critical issues are resolved.
  • A lockfile is committed so builds are reproducible.

2. Data model and data integrity

Prototypes grow prompt by prompt, and the database often records every change of direction along the way. Data problems are expensive to fix later, because fixing them means migrating real customer records.

  • Tables and fields have clear names and a single purpose, and no two tables do the same job.
  • The database enforces required fields (not null, unique, foreign keys). The frontend form is not the only check.
  • Schema changes go through versioned migrations stored in the repository instead of clicks in a dashboard.
  • Money is stored in integer minor units or a decimal type, never as a floating point number.
  • Timestamps are stored consistently, ideally in UTC.
  • Queries that filter or join large tables have suitable indexes.
  • You know where personal data lives and could delete or export one user's data on request.

3. Error handling and resilience

Generated code often assumes every request succeeds, and real networks and real users regularly prove it wrong.

  • The server validates all user input and returns clear error messages to the client.
  • Calls to external services (payments, email, AI models, maps) have timeouts and handle failure gracefully.
  • No error is swallowed silently. A failed operation is retried, reported to the user or logged for the team.
  • Error messages shown to users do not expose stack traces, SQL or internal paths.
  • Operations that must not run twice, such as charging a card or creating an order, are protected against double submission and retries.
  • Background work that can take more than a few seconds runs outside the request cycle.

4. Tests and change safety

The most common complaint about vibe-coded apps is that every fix breaks something else. The usual cause is missing tests.

  • Automated tests cover the flows that make or lose money: sign-up, login, the core action of your product, and payment.
  • Authorization rules have their own tests, so a later change cannot silently open data to the wrong user.
  • Continuous integration runs the tests on every change, and a failing test blocks the merge.
  • At least one end-to-end test clicks through the main user journey in a real browser.
  • Before any change reaches production, a person who understands it reviews it, even if an AI assistant wrote it.

Complete coverage can wait. On day one, what matters is a safety net under the parts that would hurt most if they broke.

5. Performance and scalability

  • Main pages load quickly on a mid-range phone over a mobile connection, as well as on a developer laptop.
  • Lists are paginated instead of loading every record at once.
  • No queries sit inside loops, multiplying database calls as data grows.
  • Images are resized and compressed, and static assets come from a CDN.
  • You have run a simple load test at a few times your expected launch traffic.
  • Usage-based costs (AI model calls, database reads, serverless invocations) have alerts or caps, so a traffic spike or a bug cannot produce a surprise bill.

6. Observability: knowing what is happening

If users find your bugs before you do, you lack observability. It is cheap to set up and pays for itself in the first week.

  • Error monitoring captures frontend and backend exceptions with enough context to reproduce them.
  • Logs are structured and centralised, and they contain no passwords, tokens, full card numbers or personal data.
  • Uptime monitoring checks the main pages and the API from outside your infrastructure and alerts a real person.
  • Someone is clearly responsible for responding to alerts, including outside working hours if your users need that.
  • You track a few product health metrics, such as sign-ups, failed payments and error rate, and notice when they change.

7. Backups, deployment and recovery

  • Automatic database backups are on, stored separately from the main database and kept for a sensible period.
  • You have restored a backup to a test environment and confirmed the data is usable. Until you do that, you do not know whether the backup works.
  • User-uploaded files are backed up along with the database.
  • Production and development use separate databases and separate credentials.
  • You can deploy repeatably from the repository and roll back to the previous version quickly.
  • More than one person has access to the hosting, domain, app store and payment accounts, and the access details are recorded somewhere safe.

8. Compliance and legal basics

Requirements depend on your market and your data, so read this as a list of questions to answer. It is not legal advice.

  • You have a privacy policy and terms of service that match what the app actually does with data.
  • If you serve users in the EU, you have considered your GDPR obligations: lawful basis, data processing agreements with vendors, data subject requests and breach notification.
  • If you handle health, financial or children's data, you know which regulations apply and have checked the app against them before launch.
  • Your payment provider handles card data, so raw card numbers never touch your servers.
  • Cookie consent and analytics tracking follow the rules in the regions you serve.
  • If the app sends user data to an AI model provider, users are told, and the provider's data retention terms are acceptable.
  • You know the licences of the main dependencies and of any code or assets the AI tool may have pulled in.

Regulated domains set a much higher bar. Teams building in fintech or healthcare should plan for a formal security review, since a self-assessment will not be enough.

9. Ownership and maintainability

The last question is whether your team can keep changing the app safely. A codebase can pass every item above and still trap you if nobody understands it.

  • The code lives in a repository your company owns, and not only inside an AI builder's workspace.
  • A short README explains how to run the app locally, configure environment variables and deploy.
  • The structure is consistent, with one way of fetching data, one way of handling forms and one styling approach.
  • There is little dead code, and few duplicated components or abandoned experiments.
  • A named engineer owns each part of the system and approves changes to it.

Reading your results

When you have worked through the list, sort the open items into three groups:

  1. Blockers, such as exposed secrets, broken access control, no backups or no way to roll back. Fix these before real users or real data arrive.
  2. Launch-week items: error monitoring, tests around money flows, rate limits and uptime alerts. Put these in place before launch or right after it.
  3. Next-quarter work, including data model clean-up, performance tuning and structural refactoring. Schedule it alongside feature work instead of as a separate big project.

Most AI-built apps can pass this checklist without a rewrite, through focused stabilisation work done in the right order. If you are unsure whether your codebase is worth keeping, our guide on deciding between a rewrite and a refactor of a vibe-coded app goes through the signals.

Conclusion

AI coding tools are a legitimate way to build a first version, and many good products start that way. What they rarely provide by themselves is the engineering discipline around the code: review, tests, monitoring, backups and clear ownership. Working through this checklist shows you those gaps, so you can close them on your own schedule before an incident exposes them.

If you would like a second pair of eyes, Mefasoft offers support and modernization for vibe-coded apps. We start with a written audit that ranks the risks by what they could cost you, then stabilise the app while the product stays live. Since 2019 our teams have delivered more than 400 projects, and our engineers use AI tools every day. Send us a note about your app and we will tell you what we would check first.