From AI Prototype to Production App: The Real Checklist

You built something with Lovable, Bolt, v0, Replit or Cursor. It demos beautifully, your friends are impressed, and one of them asked if they could pay for it.

That's the moment this article is for — because "it works when I show it to you" and "I can charge money for this" are separated by a specific, finite, surprisingly unglamorous body of work. Most of it has nothing to do with features.

The good news: it's a checklist, not a mystery. And going through it is almost always cheaper than starting over.

First, define what you're aiming at

"Production" isn't a vibe. It's a set of promises you're making to a paying customer:

• It's available — and when it isn't, you find out before they do.
• Their data is safe — from other customers, from attackers, and from you accidentally deleting it.
• It can change — you can ship a fix on Tuesday without breaking Wednesday.
• It survives you — someone other than the original author can work on it.

A prototype makes none of those promises. That's not a defect; it's the whole point of a prototype. The work below is just making them one at a time.

Step 1: Take ownership of the code

Before anything else, answer one question: can you get the code out?

Some AI builders give you a real repository you own. Others keep you inside their platform, where "your app" is a project in someone else's product. That's fine for a prototype and dangerous for a business — pricing changes, feature limits, and shutdowns are all outside your control.

Practical minimum:

• The code lives in a Git repository you own.
• The database is yours, with credentials you hold and can rotate.
• You can run the app locally, from a clean clone, with documented setup steps.

If you can't do all three, do this before writing another feature. Everything else on this list assumes it.

Step 2: Get more than one environment

Most AI-built projects have exactly one environment, and it's production. Every change is tested on live users.

You need at least two — a preview/staging environment that mirrors production, and production itself — plus a deploy that runs from your main branch rather than from someone clicking a button. This single change is what converts "I'm scared to touch it" into "I ship on Fridays."

Step 3: Close the security gaps

Two issues account for most of the serious findings in AI-generated codebases:

1. Missing ownership checks. The app verifies you're logged in but not that the record you asked for is yours. Change an ID in a URL and you may see another customer's data.
2. Exposed secrets. API keys and service credentials sitting in client-side code, where anyone can read them from their browser.

Both are fast to fix and expensive to leave. We go deeper on this — and the three other things that break under real load — in what breaks at 1,000 users.

Then the baseline: rate limiting on login and expensive endpoints, HTTPS everywhere, dependencies updated, and any admin surface behind real access control.

Step 4: Make the database changeable

Prototypes evolve their schema by hand — someone clicks around a database UI and adds a column. That works exactly until you have data you can't lose and a second environment to keep in sync.

You need migrations: schema changes as code, versioned in Git, applied identically to staging and production. Without them, every future change carries a risk of silent drift between environments, which is one of the nastiest categories of bug to chase.

While you're there: automated backups, and — this is the part everyone skips — one restore you have actually performed. An untested backup is a hope, not a plan.

Step 5: Decide what to keep

Now the strategic question: harden what you have, or rewrite it?

Be honest, and use structure rather than mood. Rewrite when:

• The data model is fundamentally wrong for what the product turned out to be.
• Core flows are duplicated in several places with different logic in each.
• No one can add a small feature without breaking two others.

Harden when the app is broadly coherent and the problems are the ones on this list. That's the majority of cases, and it's usually one to four weeks of work versus three-plus months for a rewrite.

The most expensive decision founders make at this stage is throwing away a working product because it isn't beautiful inside. Ugly and earning beats elegant and unlaunched.

Step 6: Know when it's broken

Ship none of this without a way to hear about failures that isn't a customer's email:

• Error tracking that captures exceptions with enough context to debug.
• Uptime monitoring on your critical paths, alerting somewhere you'll see it.
• Structured logs you can search when something odd happened at 3am.

This is what "who monitors it?" actually means in practice. It's not a person staring at a dashboard — it's instrumentation that tells you, plus someone who's agreed to answer when it does.

Step 7: The unglamorous launch list

Genuinely easy to forget, genuinely bad to miss:

• A real domain, with email deliverability configured (SPF, DKIM, DMARC) so your password resets don't land in spam.
• Privacy policy and terms, especially if you're taking payments or serving the EU.
• Analytics, so you learn something from the traffic you worked for.
• A tested billing flow, including the failure cases — declined cards, cancellations, refunds.
• An accessible, fast front end. Speed is a conversion and ranking factor, not a nicety — see why website speed is a growth lever.

What this actually costs

For a typical AI-built MVP in decent shape, production-hardening runs one to four weeks of focused engineering. Security and data integrity first, reliability second, polish last.

That's dramatically less than rebuilding, and it's the highest-return money you'll spend on the product — because everything after it (marketing, sales, fundraising) assumes the thing works.

The tools got you most of the way. This is the rest of the way. If you'd rather hand it to someone who does this weekly, that's exactly our work: see how we approach SaaS and product development, or send us your repo and we'll come back with a prioritised list of what to fix first.