"Production-ready" is the phrase every AI code generator uses and almost nobody defines. Here is a definition you can test: the project builds, every route works with real credentials, nobody can read anybody else's data, and the things that break silently have been checked by a person. This checklist gets a generated project to that bar.
It is written against ContentForger's output because I know what the generator is instructed to include, and therefore what to look for. Most items apply to any generator's output.
Why a checklist and not trust
ContentForger's generator runs under a long list of requirements: strict TypeScript with no any types, awaited params in dynamic routes, generateMetadata on every route, a dynamic sitemap, a .env.example, Row Level Security on user-owned tables, Zod validation on every API input, Vitest and Playwright tests. Those are instructions to a model. On most runs they are followed. On a run that reached its output budget, the last items get dropped, because the model simply stopped. The checklist exists to catch the gap between "instructed" and "done".
The checklist
1. It builds
Run the production build before anything else. A dev server tolerates things a build does not. Fix the first error reported, not the last; later errors are usually consequences.
2. The last file is complete
ContentForger now saves each file only once it is complete, so the files in your download should all end properly. If you copied code from the screen while it was still streaming, open the last file and scroll to the end anyway; if it ends mid-line, ask a change request for that one file in full before doing anything else.
3. Every environment variable has a value
The .env.example lists what the app expects. Copy it to .env.local and fill every line. A missing key rarely fails at start-up; it fails on the one page that needed it, often in production.
4. The schema matches the code
If there is a supabase/schema.sql, read it next to the data-access layer. Table and column names must match what the queries use. This is the most common casualty of a tight budget.
5. Row Level Security is on, and tested
Every table holding user data should have RLS enabled with policies tied to the signed-in user. Then test it the only way that counts: sign in as two different users and try to read the other's rows through the app. The generator is told to enforce ownership twice, in the database and in server code. Confirm both.
6. Signed-out and wrong-user paths return the right status
API routes should answer 401 when signed out and 403 when signed in as the wrong owner. Hit them with a plain HTTP client, not just the browser.
7. Inputs are validated
Every mutating route should validate its body with a schema and answer 400 or 422 on bad input. Send a deliberately malformed request and read the response. If the server error leaks a stack trace, that is a fix.
8. The tests run
The generator is told to ship Vitest unit tests for the schemas and data layer, one Playwright end-to-end test, and test scripts in package.json. If they exist, run them. If they do not exist, that is information too: ask for them in a follow-up before launch, not after.
9. Metadata and crawl files are real
Check that each route has a unique title under about sixty characters, that robots.ts exists, and that the sitemap enumerates real records rather than a hard-coded list. These are instructed; verify them, because they are invisible when missing and costly later.
10. No placeholder data in production paths
The generator is told never to ship hard-coded arrays or mock data as the source of truth when the app stores data. Search the project for obvious placeholder names and lorem text. A demo array that survives into production looks like a live feature until a real user tries it.
11. The watermark situation matches your plan
Free output is asked to include a "Built with ContentForger" comment in the footer. Pro and Agency output is not. Agency output with white-label configured should contain no mention of ContentForger at all. A text search of the project takes seconds and is the only proof; see Tutorial: White-Label Your ContentForger Output for Agency Clients for the delivery side.
12. No secret is in the repository or in your prompt history
Before the first commit, confirm .env.local is ignored by Git and that no key was pasted into a source file as a quick fix. Then check the other direction: every prompt and follow-up you send is saved to your ContentForger history, so a credential pasted into a prompt now lives in two places. If that happened, rotate the key at its provider. The generator never needs a real key to write code that uses one.
Keep the list of what needed fixing
Write down which items needed a fix. It is the most honest feedback you will get on your prompts: a schema that did not match the code means the first prompt did not name the data clearly; a missing test means the ask was too large for the output budget. Next time, say it earlier or ask for less per turn.
What this checklist cannot tell you
It cannot tell you whether the app does the right thing for its users. A generated booking app can pass every item above and still let someone book a slot in the past, because nobody told the model that was wrong. Product correctness comes from the prompt and from using the app yourself. The checklist clears the floor; it does not furnish the room.
Where these checks fit in the flow
They sit between "the dev server works" and "deploy". The full path, from download to a verified live URL, is in From Generated Code to a Live Site, and the chapter on building before deploying is where this list belongs. If you are adding payments afterwards, Tutorial: Add Stripe to Your ContentForger Output in 20 Minutes has its own smaller checklist for webhooks.
Twelve items, one pass, before any client or customer sees a URL. It is an hour on the first project and twenty minutes on the fifth.
