Taking an AI-built app to production: the twelve things we check before real users arrive

Published 25 October 2026 · AI-built apps · Production readiness · Checklist

An app built with Cursor, Copilot, Lovable, Bolt or v0 is usually better than people expect. The code is readable, the UI is decent, and it works — for the person who built it, with the data they tested with. The gaps are not in what the tool wrote. They are in what nobody asked it to think about, because a prompt describes features and never describes what happens when two users hit the same endpoint at once.

This is the checklist we run in a Production-Readiness Audit. Each item says what to look for, why it matters, and how to check it yourself in under an hour. If you clear all twelve, you do not need us.

1. Authorisation, not just authentication

Generated code reliably checks that a request has a logged-in user. It far less reliably checks that this user may touch this record. The classic form is an endpoint like /api/orders/123 that loads order 123 for anyone who is signed in.

Check it: sign in as user A, copy a URL or API call that returns one of A's records, change the ID to one belonging to user B, repeat the call. Do this for every resource type. If anything comes back, you have an IDOR, and it is the most common serious finding we see.

Fix: every query that loads a record by ID also filters by the owner (or tenant), enforced in one place — a repository layer or a database policy — not re-implemented per endpoint.

2. Secrets out of the repository

Search the git history, not just the working tree: git log -p | grep -iE "sk_live|AKIA|BEGIN PRIVATE". Anything that was ever committed is compromised, even if it was removed later.

Fix: rotate every key you find, move secrets to the host's secret store or a managed vault, and add a pre-commit secret scanner so it does not happen again.

3. One environment per purpose

A single .env that points development, staging and production at the same database is normal in AI-built apps and is how a developer's test run deletes a customer's data.

Check it: can you run the app locally without any network access to production? If not, split the environments and make the production credentials unreachable from a laptop.

4. Backups that have been restored

A backup that has never been restored is a hope. Managed databases usually have automated backups on by default; what they do not have is proof that a restore works and someone who knows how long it takes.

Check it: restore the latest backup to a fresh instance, run one query that proves the data is there, note the time it took, delete the instance. Put the number in a document. That is your recovery time objective, and the first time most founders learn it.

5. Migrations run by the deploy, not by a person

Schema changes applied by hand in a database GUI leave production and the code out of step. The symptom is "it works locally".

Check it: is there a migrations folder, and does the deploy run it? If the answer is "I run the SQL myself", introduce a migration tool now, while the schema is small enough to reconstruct.

6. Constraints in the database, not only in the UI

Uniqueness, foreign keys and not-null constraints are often missing because the form validated them and that seemed enough. Two requests arriving together bypass form validation every time.

Check it: open the schema. For every "this must be unique" rule in the product, is there a unique index? For every relationship, a foreign key? Add the missing ones with a migration, after cleaning the duplicates that already exist — there will be some.

7. The N+1 query

ORMs make it easy to load a list and then query inside a loop. At ten records nobody notices. At a thousand, the page takes eight seconds and the database CPU pins.

Check it: turn on query logging locally, load the busiest list page, count the queries. If the number scales with the number of rows, fix it with eager loading or a join. Then add an index for every column that appears in a WHERE or ORDER BY on a hot path.

8. What happens at 10× today's traffic

You do not need a load-testing platform. A single k6 or autocannon run against staging with ten times your current peak tells you whether the app, the database or the host falls over first.

Check it: run it, watch the error rate and p95 latency, and write both numbers down. The goal is not to pass; it is to know which thing breaks first so the fix is targeted.

9. Deploys from a pipeline, with a rollback

If deploys happen from one person's machine, that person is your single point of failure and the deploy cannot be reproduced.

Check it: is there a CI pipeline that runs the tests and deploys the same way every time? Can you roll back to the previous version in under five minutes without thinking? If either answer is no, this is a one-day job that removes a whole category of 2 a.m. incidents.

10. Tests for the money paths

AI-built apps often have no tests, or tests the tool generated that assert nothing useful. You do not need full coverage. You need tests for the paths where a bug costs money or trust: sign-up, payment, permissions, anything that sends an email to a customer.

Check it: list those paths; for each, is there an automated test that would fail if it broke? Write the missing ones first, before any refactor.

11. Logging, error tracking, uptime, alerting

The question is simple: would you know about an outage before a user told you?

Check it: kill the app on staging. Does anything page a human? If not: error tracking (Sentry or similar), an uptime check against the public URL, and one alert on error rate — the three cheapest hours you will ever spend.

12. Dependencies and the generated-code tells

Run npm audit / pip-audit / composer audit and look at the lockfile dates. Then look for the patterns generated code tends to leave: swallowed exceptions (catch (e) {}), TODO comments the tool wrote and nobody read, duplicated helper functions, and retries without a limit. None is a crisis on its own; together they are where the next incident hides.

Scoring yourself

Give one point per item you can answer with evidence, not confidence.

• 10–12: ship it, and go read about SOC 2 because a customer will ask soon.
• 6–9: normal for a well-built MVP. Items 1, 2 and 4 first; they are the ones that end companies.
• 0–5: also normal, and fixable in two to four weeks of focused work — usually without a rewrite.