Your AI Prototype Worked. Here Is the Production Checklist Before You Scale It.

The demo worked.

That does not mean the app is ready for production.

AI coding tools are good at getting a prototype onto the screen. They are much weaker at proving the parts production depends on: source control, data shape, access control, secure writes, tests, deployment, observability, and maintainability.

Before you rewrite everything or send real users into the prototype, work through these eight checks.

1. Inventory: can a new person run it?

Start from a clean checkout. Follow the README. If the app only runs because the original builder remembers five missing steps, you do not have a production handoff yet.

Write down:

• the repo URL and production branch
• build, test, and run commands
• the deployed commit
• the frameworks and services actually in use
• the code that has been reviewed by a human
• the top three unknowns

Unknowns are not embarrassing. Hidden unknowns are the risk.

2. Data: is the shape real?

Data outlives code. If the schema is implicit, scattered, or hand-shaped in a dashboard, every future change gets harder.

Check:

• whether every table or collection has a definition
• whether migrations can recreate the structure
• whether backups exist
• whether a restore has been tested
• whether secrets or personal data leaked into the repo or client bundle

An untested backup is not a backup. It is a hope.

3. Auth: is access enforced on the server?

A login screen is not access control.

For each API endpoint that returns or changes data:

1. call it with no credentials
2. call it as a different user
3. confirm both are rejected when they should be

If admin gating only lives in the UI, anyone can bypass it by calling the endpoint directly.

4. Security: can the write paths be abused?

Browser validation helps users. It does not protect your system.

Before production, confirm that:

• inputs are validated server-side
• dependencies are pinned and scanned
• write endpoints require authentication and authorization
• database queries are parameterized
• user content is escaped when rendered
• expensive endpoints have rate limits
• HTTPS is enforced

Small apps do not need a full security department on day one. They do need to close the obvious holes.

5. Reliability: what happens when things fail?

Production has slow APIs, duplicate clicks, flaky networks, and unexpected input.

At minimum, write three tests:

1. a new user can reach the main screen
2. the core action succeeds and persists
3. the core action fails cleanly with bad input

Then test what happens when an external service is slow, rate-limited, or down.

6. Deployment: can you release and roll back without drama?

If deployment lives in one person's terminal history, the project is not ready.

You want:

• a documented script or pipeline
• separate staging and production environments
• externalized configuration
• zero secrets in client-visible build output
• a rollback path that takes minutes, not days

Rare, scary deploys become large deploys. Large deploys break more.

7. Observability: do you find out first?

If the first alert is a user complaint, the app is blind.

Set up:

• error tracking
• structured logs for key actions
• an uptime check
• a lightweight product signal for the core action

You should be able to answer two questions without guessing: what broke, and how many people used the main feature yesterday?

8. Handoff: can someone maintain it next month?

A prototype only its author can change is a liability.

Ask:

• could a new engineer make a safe change in the first week?
• does the README explain why the system is built this way?
• is there a single owner?
• what breaks if the original author disappears?
• are important decisions recorded?

Production readiness is not only uptime. It is the ability to keep changing the system safely.

Rescue or rebuild?

Rescue the prototype when the core data model is sane, the framework is mainstream, and the gaps are mostly tests, auth, deployment, and operations.

Rebuild, or partially rebuild, when the data model fights every new feature, secrets and business logic live in the client, or no two flows agree on how state works.

Most real cases are not full rewrites. They are production hardening plus one honest rebuilt slice.

For a second opinion, Omni Care keeps two free routes:

• Software rescue self-diagnostic: https://care.omniai.one/rescue.html?utm_source=devto&utm_medium=article&utm_campaign=p2p_checklist&utm_content=rescue_diagnostic
• Software Problem Clinic: https://care.omniai.one/software-problem-clinic/?utm_source=devto&utm_medium=article&utm_campaign=p2p_checklist&utm_content=problem_clinic

The useful next step is simple: make the unknowns visible, close the ones that block real users, then decide whether to rescue, rebuild, or take a hybrid path.