Whatever tool built your prototype — Cursor, Claude, Lovable, or Bolt — the production checklist is broadly the same. This is the list we run through during a Production Readiness Audit, organized so a non-technical founder can follow along.
Code quality and structure
Whatever tool built it — Cursor, Claude, Lovable, or Bolt — generated code tends to be locally correct and globally tangled. Logic is duplicated across files, components do too much, and there is little separation between what the app does and how it talks to the outside world. It runs, but it resists change, and a product you cannot safely change is a product that will stall.
The fix is not a rewrite; it is a pass for structure. Pull shared logic into one place, give the codebase clear boundaries between layers, and add tests around the parts you most fear breaking. The bar is simple: a new engineer should be able to find where a thing lives and change it without holding their breath.
Security and authentication
Treat every generated authentication flow as guilty until proven innocent. A login screen that sets a session is not the same as a system that checks, on the server, whether this specific user is allowed to perform this specific action. The classic failure is being able to read another user's data by changing an ID — authentication present, authorization absent.
While you are there, hunt for leaked secrets. API keys and database credentials committed to the repository or shipped to the browser are common in AI-built apps and are exactly what a curious visitor looks for first. Move them into a managed secrets store and rotate anything that was ever exposed.
Database and data integrity
Prototypes use the database as scratch space; production depends on it staying correct. Check that the schema has the indexes your real queries need, that constraints prevent invalid or duplicate records at the database level rather than hoping the app remembers to, and that schema changes go through tracked migrations instead of manual edits.
Then confirm the part everyone skips: backups that have actually been restored. Until you have rebuilt the database from a backup and seen the data come back intact, you do not have recovery — you have a hope you have never tested.
APIs and rate limiting
Generated APIs are usually built for the happy path: a well-formed request from a well-behaved client. Production traffic is not that. Validate every input on the server, return consistent and meaningful errors, and never assume the caller is your own front end behaving nicely.
Rate limiting is the protection most prototypes lack entirely. Without it, a single misbehaving client or a brute-force attempt can exhaust your resources or run up costs. Put sensible limits on public and authenticated endpoints, and be deliberate about anything expensive — a call that triggers a heavy job or an external charge deserves stricter limits than a simple read.
Cloud deployment and environments
Moving from a laptop to the cloud means more than uploading the code. Separate development, staging, and production into isolated environments, and supply their differences — credentials, connection strings, scale — as runtime configuration rather than values hard-coded into the source.
Choose a compute model that matches the workload instead of the most powerful one available, and put the basics in front of the app: a real domain, HTTPS with auto-renewing certificates, and a CDN for static assets. The aim is an environment where deploying is routine and reversible, not an event you brace for.
CI/CD, monitoring, and backups
The last layer is the operational one, and it is what separates a product you run from one that runs you. A CI/CD pipeline should build, test, and ship every change the same way, with a fast rollback to the last known-good version when something slips through. Manual deploys done from memory are how quiet products turn into outages. Confirming this layer is real and not just present on paper is the core of a production readiness audit, like the one behind ThinkByAI's Cloud Production Care.
Pair that with observability and recovery you have actually verified rather than assumed:
- A CI/CD pipeline that builds, tests, and ships every change identically, with a fast rollback.
- Centralized, searchable logs and error tracking with enough context to reproduce failures.
- Uptime checks and alerts that reach a person before customers do.
- Automated backups you have restored at least once into a separate environment.