Prototype to Production Checklist Publishing Kit

---
title: "Your AI Prototype Worked. Here Is the Production Checklist Before You Scale It."
published: false
description: "Eight practical checks before taking an AI-generated or vibe-coded app from demo to production."
tags: ai, webdev, startups, softwareengineering
canonical_url: https://care.omniai.one/distribution/prototype-to-production-checklist/
---

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.

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

Subtitle:
Eight practical checks before taking an AI-generated or vibe-coded app from demo to production.

Canonical URL:
https://care.omniai.one/distribution/prototype-to-production-checklist/

Body:

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 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.

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. Confirm definitions, migrations, backups, restore, and zero leaked secrets.

3. Auth: is access enforced on the server?

A login screen is not access control. Call each data endpoint with no credentials and with another user's credentials. Confirm both are rejected when they should be.

4. Security: can the write paths be abused?

Browser validation is user experience, not security. Validate inputs server-side, pin and scan dependencies, protect write endpoints, parameterize queries, escape user content, rate-limit sensitive paths, and enforce HTTPS.

5. Reliability: what happens when things fail?

Write three tests first: signup or entry path, the core action succeeds and persists, and the core action fails cleanly with bad input. Then test slow, rate-limited, or unavailable external APIs.

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

Deployment should be a documented script or pipeline. Staging and production should be separate. Configuration should be externalized. Rollback should take minutes.

7. Observability: do you find out first?

Set up error tracking, structured logs, an uptime check, and one lightweight product signal for the core action. You should be able to answer 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. Make sure a new engineer can make a safe change, the README explains why the system works this way, and one person owns decisions.

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=medium&utm_medium=article&utm_campaign=p2p_checklist&utm_content=rescue_diagnostic

Software Problem Clinic:
https://care.omniai.one/software-problem-clinic/?utm_source=medium&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.

Your AI prototype worked in the demo.

Before you scale it, check eight production gaps:

1. Can a new person run it from a clean checkout?
2. Is the data model real and reproducible?
3. Is authorization enforced on the server?
4. Are write paths protected against direct abuse?
5. Do critical flows have tests?
6. Can you deploy and roll back repeatably?
7. Do logs and monitoring tell you what broke?
8. Can someone maintain it next month?

The question is not "did the demo work?"

The question is whether the app is safe to run, safe to change, and owned by someone after launch.

Full checklist and article:
https://care.omniai.one/distribution/prototype-to-production-checklist/?utm_source=linkedin&utm_medium=post&utm_campaign=p2p_checklist&utm_content=short_post