How to Take an AI-Built Prototype Into Production

Taking an AI-built prototype to production means proving more than the interface works. Confirm that you own the code and accounts, that each user can reach only their own data, that payments and outside services behave when something fails, and that someone can deploy, roll back, and support the app after launch. Keep the parts that already pass.

Key takeaways

• A prototype shows that an idea can work. Production means it keeps working for strangers, with real data and real money, when you are not watching.
• Start with ownership. If the code, database, or domain sits under an account you don't control, everything else waits.
• Test with at least two accounts at different roles. Most serious problems in generated apps are permission problems that a single test user never sees.
• Payment state should come from verified events sent by the payment provider, never from the page a customer lands on after checkout.
• Write down what "done" means for each area before hiring anyone. The readiness matrix below is a template for that.

First decide: site, SaaS, or workflow

The production checklist depends on what the prototype is for. Three shapes cover most AI-built projects:

• A marketing website: pages, forms, and maybe a booking link. The launch risks are the domain, search visibility, forms that silently fail, and analytics.
• A SaaS product or customer portal: accounts, stored data, and often subscriptions. The launch risks are permissions, payments, data loss, and support.
• An internal workflow tool: a small number of known users, often connected to spreadsheets or a CRM. The launch risks are access control, integrations, and what happens when the person who built it is away.

Write one sentence that names the shape and the first thing a real user must be able to do. "A client can sign in, upload a document, and see its status" is a better starting point than "launch the app."

Review ownership and access

Before anyone changes code, list every account the prototype depends on and who controls it:

• The code itself. Is it in a Git repository under your account or organization, or only inside the builder?
• The database and file storage, including where backups live.
• Hosting, the domain registrar, and DNS.
• Email sending, payments, analytics, and any AI model provider keys.
• The builder workspace, including who has owner or admin rights.

Some builders keep parts of the stack under their own account until you export or connect them. Lovable, for example, can sync a project to a new private GitHub repository, and its documentation notes that deleting that repository or transferring the workspace breaks the sync. Check the current documentation for your tool, and get each critical account into your name before launch. The Lovable handoff checklist walks through this for one builder in detail.

Test what works end to end

A demo usually exercises the happy path once. Production needs every main journey to work from a clean start, on a phone, with a new account. Pick the three to five journeys that matter most and run each one as a stranger would:

1. Open the site in a private window on your phone.
2. Sign up with an email address you have never used on the app.
3. Complete the main task, including any upload, payment, or confirmation email.
4. Sign out, sign back in, and confirm the result is still there.
5. Try the same journey with a second account and confirm neither account can see the other's data.

Write down what happened at each step. Those notes become acceptance criteria later, and they tell a developer exactly where the prototype stops working.

Security and data

Most AI builders can produce a sign-in screen in minutes. The harder question is what each signed-in person is allowed to do. OWASP ranks broken access control first in its 2025 Top 10 of web application risks, and generated apps are prone to it because the browser often talks straight to the database.

At a minimum, confirm:

• Every table or collection that holds customer data has access rules enforced on the server or in the database.
• Admin screens check the user's role on the server, not just by hiding a menu item.
• Private keys live in server-side secrets, never in frontend code or a public environment variable.
• File uploads are limited by type and size, and stored files aren't readable by anyone with the link unless that's intended.

The vibe coding security checklist covers each of these with safe tests you can run yourself.

Payments and external APIs

If the prototype charges money, the most important rule is that payment status comes from the payment provider's server, not the browser. Stripe's documentation recommends webhook events for this, because a customer can close the tab before the success page loads, and a success page can be opened without paying.

Check these before you take a real payment:

• Test and live keys are separate, and the preview environment can't charge real cards.
• Webhooks are verified with the signing secret and handle renewals, failed payments, refunds, and cancellations.
• The same event arriving twice doesn't create two orders or two subscriptions.
• Customers can see and manage their subscription somewhere you control.

Other outside services need the same treatment. Email providers, AI model APIs, and CRMs all fail occasionally. Decide what the user sees when they do, and make sure a failed call doesn't leave half-written records behind.

SEO, accessibility and performance

For a public website, check what search engines receive. Some builders produce apps that send an almost empty HTML page and fill it in with JavaScript. Google can render JavaScript, but its JavaScript SEO guidance still recommends making sure important content and links are available to crawlers. Confirm each page has its own title, description, and canonical URL, and that a sitemap lists the pages you want found.

Accessibility and speed matter for the same visitors. Check that forms have labels, buttons can be reached with a keyboard, images have useful alt text, and the main pages load quickly on a phone connection.

Deployments and rollback

A prototype is often published with one button. Production needs a release process someone can repeat and undo:

• Code changes go through version control, with a short note describing each release.
• There is a staging or preview environment that uses test data and test keys.
• Database changes are written as migrations, so they can be reviewed and applied in order.
• You know how to return to the previous version of the code, and you know whether that also returns the database to its previous state. On many builders it doesn't.

Write the rollback steps down before launch. When something breaks with customers watching, nobody wants to work them out for the first time.

Monitoring and support

After launch, someone has to notice problems before customers report them. Set up error reporting that alerts a person, uptime checks for the main pages, and a way to see failed payments and failed emails. Decide who answers support requests, how fast, and where those requests go. If the answer is "the founder, whenever they see it," write that down too, so the expectation is honest.

Project handoff checklist

Use this matrix to record the state of each area before you hire help or launch. Fill in the evidence column with something a second person could check, such as a screenshot, a link, or a test result. Leave the pass or fail column blank until that evidence exists.

A matrix like this keeps a review focused. It also makes proposals easier to compare, because every developer is responding to the same list.

When to hire help

You can complete much of this yourself, especially ownership, journey testing, and the handoff matrix. Bring in a developer when:

• A second account can see the first account's data, and you're not sure why.
• You're about to take real payments or store sensitive information.
• Each new prompt breaks a different part of the app.
• You need to move hosting or the database off the builder.
• You need someone accountable for the app after launch.

The guide to hiring a developer to finish an AI-built website explains what to send in the first message and how to compare proposals. If you want Routeless to look at it, our page on finishing AI-built projects explains how the review works.

Frequently asked questions

What does production ready mean?

Production ready means real users can complete the main journeys on their own, their data stays private to them, payments and outside services are handled when they fail, and someone can release, roll back, and support the app. It doesn't mean finished forever. It means safe to put in front of customers.

Can I keep my prototype?

Usually, yes. Most AI-built prototypes have screens, flows, and content worth keeping. A review sorts the work into what can be finished as is, what needs repairs, and what would cost more to fix than to replace. A full rebuild is rare and should be justified by specific problems.

What evidence does a developer need?

A developer needs access to the code or at least a working preview, a list of the accounts involved, notes on which journeys work and which fail, and a description of what must work at launch. The handoff matrix in this guide covers all of it. Never send passwords or API keys by email or form.