AI app builders and coding assistants have made it possible to 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 passes the demo.

Looking finished and being ready for real users are different things. Production readiness is about what happens when someone enters unexpected input, when a third-party API times out, when two users edit the same record, or when a curious visitor opens the browser developer tools. Generated code tends to cover the happy path well and the rest 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. Work through it honestly. 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 a single gap there can end a young product, while a slow page rarely does. For each item, mark it as done, not applicable, or unknown. Treat "unknown" as "not done": if nobody on the team can say whether database access rules are enforced, assume they are not.

If your list of unknowns is long, that is normal for an app built quickly with AI tools, and it is exactly the situation a structured code audit for an AI-built app is designed for.

1. Security: authentication, secrets and access rules

This is where generated code most often falls short, because the code works perfectly for the developer who wrote the prompt and was logged in as themselves.

Authentication

  • Users authenticate through a proven provider or library, not a hand-rolled password scheme.
  • Passwords, if you store them at all, are hashed with a modern algorithm by the auth library, never stored or logged in plain text.
  • Sessions and tokens expire, and logging out actually invalidates them.
  • Password reset and email verification flows cannot be used to take over another account.
  • Admin features are protected on the server, not just hidden in the interface.

Secrets

  • No API keys, database credentials or service tokens are committed to the repository, including its history.
  • No secret keys are shipped to the browser or mobile app bundle. Only keys designed to be public (such as a publishable key with restricted scope) appear in client code.
  • 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, not just deleted from the code.

Access rules and authorization

  • Every API endpoint and database query checks that the current user is allowed to read or change that specific record.
  • If the app talks to a backend-as-a-service database directly from the client, 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 have rate limits.

A practical test: create two ordinary user accounts, then try to read and modify the first user's data while logged in as the second, using the browser's network tab. 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 for good reason.

Dependencies

  • All packages are real, maintained and actually used. AI tools occasionally suggest packages that are outdated or do not exist, and unused ones add risk for 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 evolve prompt by prompt, and the database often reflects every change of direction along the way. Data problems are expensive to fix later because they require migrating real customer records.

  • Tables and fields have clear names and a single purpose. There are no duplicate tables doing the same job.
  • Required fields are enforced by the database (not null, unique, foreign keys), not only by the form on the frontend.
  • Schema changes are made through versioned migrations stored in the repository, not by clicking around 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 appropriate 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 frequently assumes every request succeeds. Real networks and real users do not cooperate.

  • All user input is validated on the server, with clear error messages returned to the client.
  • Calls to external services (payments, email, AI models, maps) have timeouts and handle failure gracefully.
  • Errors are never swallowed silently. A failed operation is either 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. That is a symptom of missing tests, not bad luck.

  • 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 future change cannot quietly open data to the wrong user.
  • Tests run automatically on every change through continuous integration, and a failing test blocks the merge.
  • There is at least one end-to-end test that clicks through the main user journey in a real browser.
  • Every change is reviewed by a person who understands it before it reaches production, even if an AI assistant wrote it.

You do not need complete coverage on day one. You need 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, not just on a developer laptop.
  • Lists are paginated rather than loading every record at once.
  • There are no queries inside loops that multiply database calls as data grows.
  • Images are resized and compressed, and static assets are served 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 do not have observability. This area is cheap to set up and pays back the first week.

  • Error monitoring captures frontend and backend exceptions with enough context to reproduce them.
  • Logs are structured, centralised and free of passwords, tokens and full card or personal data.
  • Uptime monitoring checks the main pages and 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 it.
  • 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 enabled, stored separately from the main database, and retained for a sensible period.
  • You have actually restored a backup to a test environment and confirmed the data is usable. An untested backup is a hope, not a plan.
  • User-uploaded files are backed up as well as the database.
  • Production and development use separate databases and separate credentials.
  • Deployments are repeatable from the repository, and you can roll back to the previous version quickly.
  • More than one person has access to the hosting, domain, app store and payment accounts, and access is recorded somewhere safe.

8. Compliance and legal basics

Requirements depend on your market and your data, so treat this as a list of questions to answer rather than 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 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 specific regulations apply and have checked the app against them before launch.
  • Card data is handled by your payment provider, so raw card numbers never touch your servers.
  • Cookie consent and analytics tracking match 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 raise the bar considerably. Teams building in fintech or healthcare should plan for a formal security review rather than a self-assessment.

9. Ownership and maintainability

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

  • The code lives in a repository your company owns, 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: one way of fetching data, one way of handling forms, one styling approach.
  • There is no large amount of dead code, duplicated components or abandoned experiments.
  • A named engineer owns each part of the system and approves changes to it.

Reading your results

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

  1. Blockers. Exposed secrets, broken access control, no backups, no way to roll back. Fix these before real users or real data arrive.
  2. Launch week. Error monitoring, tests around money flows, rate limits, uptime alerts. Get these in place before or immediately after launch.
  3. Next quarter. Data model clean-up, performance tuning, structural refactoring. Schedule them alongside feature work rather than in a separate big project.

Most AI-built apps do not need a rewrite to pass this checklist. They need focused stabilisation work 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 walks 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 supply on their own is the engineering discipline around the code: review, tests, monitoring, backups and clear ownership. This checklist makes those gaps visible so you can close them deliberately instead of discovering them through an incident.

If you would like a second pair of eyes, EmphaSoft offers support and modernization for vibe-coded apps, starting with a written audit that ranks the risks by what they could cost you, followed by stabilisation while the product stays live. Since 2010 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.