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

April Aide — Wed, 09 Sep 2026 11:40:53 +0000

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:

call it with no credentials
call it as a different user
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:

a new user can reach the main screen
the core action succeeds and persists
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.

DEV Community: April Aide