From Prototype to Launch: What Still Has to Be Built

A demo just has to run once, for you, in a browser tab you control. A production app has to run correctly for strangers clicking things you never tested, while you are asleep. Veracode's 2026 GenAI Code Security Report measures that gap: AI code hits 95%+ syntax correctness, but only around 55% passes basic security checks.

The gap between syntax correctness and security is a punch list, not a verdict on AI app builders. Syntax correctness means the app compiles and clicks through the way you designed it. Security pass rate means nobody can walk in the back door while it's doing that. Nothing in "the demo worked" tells you whether the second number holds - and for most vibe-coded apps, it doesn't, until someone checks.

This article is that checklist: the specific things that have to get added, reviewed, or configured between a working demo and a launch you'd actually put in front of real users. Joylo's AI Confidence Score runs a version of this exact checklist against every build, flagging the gaps before you ship rather than after. Not a case against building with AI. A map of what's still missing when the AI stops.

Most AI app builders generate a conventional web stack: a React-style frontend, a Node-style backend, and a Postgres-family database. There's rarely anything exotic under the hood - the code that runs your app looks like code a human engineer would have written five years ago, just generated faster.

The variable that actually matters is portability, not novelty. Some builders couple the generated code tightly to their own hosting or database layer, so the app only really works inside that vendor's walls. Others generate plain, standard components that run anywhere you point them.

Lovable, for example, builds on Supabase for both the database and the API layer - the app talks to Supabase's client SDK, its auth, and its row-level security policies, so moving off Lovable means either running Supabase yourself or rewriting that whole layer against a new backend. Joylo generates a conventional React frontend, Node API layer, and Postgres via Neon - standard components, standard pg_dump/pg_restore to move the database, no proprietary SDK holding the app in place. If you don't know which kind of stack you have, that's the first thing to check before you build anything else on top of it.

A database connection is not the same as a production-ready backend. "Connected" just means the app can read and write rows right now. Production-ready means those rows survive a bad deploy, a full disk, or a fat-fingered migration at 2am.

AWS's own PostgreSQL operations guidance treats backups and point-in-time recovery as a defined, configured strategy - not something that comes free with a live connection. That means: automated backup schedules, a retention window, and a tested way to restore to a specific moment before things went wrong. None of that shows up in a screenshot of a working app.

The failure mode here is specific and common: a builder wipes a table testing a feature, or a bad migration overwrites production data, and there's no recovery path because nobody configured one. The database was "connected." It was never backed up. Joylo generates apps on PostgreSQL with automatic backups configured by default, which closes the most common version of this gap before anyone has to remember to set it up. Before real users touch the app, confirm the backup schedule exists, confirm the retention window, and confirm someone has actually run a restore, not just assumed it would work.

Typing a password and getting in is the easy part to build. OWASP's 2025 Top 10 names credential stuffing, missing multi-factor authentication, and weak session management as a top-tier production risk category - and a plain sign-in form defends against none of it by default.

Credential stuffing is attackers replaying stolen username-password pairs from other breaches against your login form, at volume, until one works. Weak session management is a login that stays valid longer than it should, or a session token that leaks somewhere it shouldn't. Missing MFA means one password is the entire wall between an attacker and a user's account.

An AI builder generating "add login" will usually produce a working form fast. Whether that form rate-limits failed attempts, expires sessions correctly, and supports a second factor is a different, narrower question - and it's the one that decides whether "users can sign in" quietly becomes "users' accounts got taken over." Joylo's security audit checks for exactly this class of gap on every build, and a full authentication review is part of what an Expert Assist engineer does when brought into a codebase. Ask that second question before launch, not after the first incident.

When an AI-built app throws an error in front of a real user, re-prompting the AI to "fix it" is not the same discipline as reviewing the fix. OWASP's Secure Coding with AI guidance is direct on this: AI-generated code needs the same review, testing, and explicit sign-off as human-written code before it goes anywhere near production.

The OWASP guidance reframes debugging entirely: fixing an AI-built app in production is a code-review problem, not a chat problem where the right prompt makes the error disappear. Something in the generated code did not anticipate this input, this timing, or this edge case, and the fix needs the same scrutiny a human engineer's pull request would get - does it actually address the root cause, or does it just stop this one error message from appearing.

The pattern that causes real damage is re-prompting the same error seventeen times until something sticks, without ever understanding what changed. Each patch gets layered on the last without anyone checking whether it introduced a new gap. A production-ready error-handling layer means someone - AI-assisted or human - is actually reviewing what a fix changed, not just confirming the red text went away. This is the review a Joylo Expert Assist engineer runs on a messy, re-prompted codebase: an actual audit of what each patch changed, not another round of re-prompting.

A builder's version-history button is one click. A real rollback discipline is a formal, auditable engineering control - which is what NIST SP 800-53's configuration-change-control family actually requires: every change tracked, tested, and reversible, with recovery planning built in as standard practice, not emergency improvisation.

Clicking undo and safely reverting a live app with real user data mid-session are different questions, and the gap between them is what breaks apps in practice. A code rollback might not roll back a database migration that ran alongside it. A revert that looks clean in the builder's history might leave orphaned records or broken foreign keys behind, because the rollback only reverted the code, not the data changes that shipped with it.

Before launch, know the actual answer to: if this deploy breaks something at 9am with users active, what specifically reverts, how long does it take, and does the data stay consistent afterward. If nobody has tested that sequence, the rollback plan is theoretical, not real. Because Joylo generates a conventional React, Node, and Postgres-via-Neon stack, a revert is a real, auditable git operation plus a standard pg_restore - portable to run anywhere, not tied to a builder's proprietary undo history the way a tightly-coupled stack would be.

Scaling infrastructure is a distinct engineering layer from the app-generation layer AI builders focus on. Multi-AZ database replicas, backup retention policies, and disaster recovery configuration are operator decisions an engineer has to make deliberately, not something bundled in by default just because the app generated successfully and looks finished.

AWS's operational guidance treats these as configuration choices someone actively makes: how many replicas across how many availability zones, how long backups are retained, what the recovery point objective is if a whole region goes down. An AI app builder that gets you from prompt to working app has typically not made any of these decisions on your behalf, because they aren't app-generation decisions - they're infrastructure decisions that come after.

The practical trigger is traffic, not time. An app with ten test users doesn't need multi-AZ replication. An app about to be featured somewhere, or onboarding its first real cohort, does - and the infrastructure has to be in place before the traffic spike, not configured reactively while the app is falling over. Joylo's scalability audit flags this exact gap on every build, and the underlying Postgres-via-Neon database is built to support the replica and backup configuration a growing app needs.

Ongoing dependency and patch management has to be added deliberately after launch, since nobody does it automatically once the app ships. OWASP flags a specific supply-chain risk: AI coding agents can reference library names that do not exist, and attackers have started registering those exact names as malicious packages, waiting for an app to import them.

That supply-chain risk compounds fast after launch. Every dependency in the generated app is a piece of code someone else maintains, and every one of them eventually needs a security patch. An app that launched clean six months ago can be running a dependency with a newly disclosed vulnerability today, and nothing about "the AI built it correctly" catches that on its own - patching is an ongoing maintenance task, not a one-time build step.

Before launch, know who is responsible for checking for new vulnerabilities in the app's dependencies on an ongoing basis, and how often. If the honest answer is "nobody, yet," that's a gap to close before real user data is at stake, not after. Joylo's code quality audit checks for exactly this kind of dependency drift on an ongoing basis, and Expert Assist can take over the patching itself once a build has real dependencies to maintain.

Teams that successfully ship an AI-generated prototype follow a repeatable path: harden the generated code against a security and dependency review, add the operational layers the builder didn't generate - auth, backups, monitoring, rollback - then hand the parts an AI builder doesn't cover to engineers, rather than shipping the builder's first output straight to real users.

Arxiv research on vibe coding names the mechanism directly: AI-assisted "flow" coding trades short-term speed for accumulated technical debt whenever it happens without structured review and governance. The speed is real. So is the debt, if nothing catches it along the way.

This is that process, in practice. In our Expert Assist work, the first thing an engineer checks is rarely the feature that broke - it's whatever depends on that feature, because that's where an AI-generated fix usually missed a side effect. A named in-house engineer is already in the codebase - not a marketplace handoff to a stranger who has to read the whole thing cold. One click connects that engineer through Joylo's Expert Assist, a fixed-price architect engagement with a 24-hour first-response SLA. The engineer reviews what's actually there, closes the specific gaps this article covers, and hands back something deployable. That's the difference between "someone eventually reviews this" and "someone who already knows the codebase reviews this by name, on a clock."

No mainstream AI app builder publishes a written production-readiness guarantee. Coverage of Lovable, Replit, Bolt, Emergent, ChatGPT Sites, and Google centers on how fast each one generates a working demo, not on what happens to that demo after - none of them commits, in writing, to what ships being safe for real users.

Joylo is built around closing that specific gap, as a capability it controls rather than a promise about your business outcome. Every build gets a real-time AI Confidence Score across five domains - scalability, security, reliability, integrations, and code quality - that flags uncertain code before it ships, on every plan, every build, by default. That's the automated half of the checklist this article just walked through, running continuously instead of waiting for someone to remember to check.

Expert Assist is a strong fit for a team whose AI-built app already hit one of the gaps this article covers - it's a named in-house engineer already in your codebase, on the same fixed-price architect offer described above, with a 24-hour first-response SLA. Start free to see the Confidence Score on your own build, and if it flags gaps you can't close yourself, Expert Assist is the next step - not a guarantee your app succeeds, but a guarantee that a real engineer stands behind what ships.