From Prototype to Production:How to Finish a Vibe-Coded App the Right Way

A vibe-coded app that demos well is optimized for looking finished during a walkthrough — not for surviving real users, real money, and real edge cases. That gap isn't cosmetic. It's structural: authentication without real access control, a checkout button without webhook handling, a happy path without error states, zero automated tests, manual deploys, no monitoring, and no plan for backups or legal basics.

None of this is a knock on AI app builders. Getting from a blank prompt to a clickable, good-looking, functionally real app in a matter of days is a genuine achievement — our own marketing site runs on Lovable. If you want the full picture of what these tools are and aren't, our companion guide What Is Vibe Coding? The Complete 2026 Guide to AI App Builders covers that ground. This article picks up after the demo already works.

The problem is that a demo and a production app optimize for different things. A demo needs to look complete in a five-minute walkthrough with one user, on a good connection, doing the things the presenter expects. Production software needs to survive thousands of unplanned inputs, concurrent users, partial failures, and the handful of malicious or careless actions someone will eventually take. AI builders are remarkably good at the first job and structurally under-equipped for the second, because nothing in a prompt-driven workflow forces you to specify what happens when a payment webhook arrives twice, or when two admins edit the same record at once.

If you've already been through initial launch, our post-launch checklist covers the immediate items most teams hit in the first weeks. This guide goes deeper and more systematically — it's the audit you run before you actively grow the app, take payments at scale, or hand it to a team you didn't personally watch build it. If the technical debt underneath your app is severe enough that patching feels harder than starting over, our rebuild-or-cleanup framework helps you make that call honestly before committing budget. For where AI-assisted building and professional engineering practice diverge more broadly, see Vibe Coding vs. Professional Development.

Most vibe-coded apps have a working login screen but not real access control. Permission checks live in the UI — "hide this button for non-admins" — instead of the backend, which means anyone who can craft a direct API request can often reach data or actions they were never meant to touch. This is the single most common and most consequential gap we see.

Supabase, Firebase, and similar backends make authentication trivially easy to wire up through a builder prompt — email/password or OAuth login works within minutes. What doesn't come for free is authorization: which authenticated user can read or write which row, and whether that's enforced where it actually matters, on the server and the database, not just in the client.

None of these break the demo. All of them break in production, often silently. A production-grade pass covers role-based access control enforced at the API and database layer, verified tenant isolation for any multi-tenant app, secure session and token handling, a real password reset and account recovery flow, and multi-factor authentication for admin or privileged accounts. The deeper technical walkthrough lives in two companion pieces: 7 Hidden Security Risks in Vibe-Coded Apps and Supabase Row-Level Security Checklist for Lovable, Bolt, and Bubble Apps. If you want an independent check specifically on this layer, our security audit service is scoped exactly for it. Supabase's own documentation is a good reference while doing it yourself — but verifying that every policy actually blocks what it should, under adversarial testing rather than happy-path testing, is where a professional pass earns its cost.

A "connect Stripe" prompt gets you a checkout button that charges a card once. It doesn't get you webhook handling, failed-payment recovery, subscription lifecycle sync, or basic tax handling — and that's where the actual engineering work in payments lives. Checkout working is genuinely the easy 20% of a payments integration.

The harder 80% is everything that happens after the first successful charge: a card gets declined on renewal, a customer disputes a charge, someone upgrades or downgrades mid-cycle, a subscription needs to be paused instead of cancelled, or a webhook simply arrives twice because of a network retry. None of that is exotic — it's the normal operating condition of any subscription business — but it's rarely covered by a single AI-generated integration, because a builder prompt naturally optimizes for whether the checkout button works, not whether your database stays in sync with what Stripe actually billed six months from now.

• Webhook endpoints for the events that actually matter: checkout.session.completed, invoice.payment_failed, customer.subscription.updated, customer.subscription.deleted.
• Idempotency handling so duplicate webhook deliveries don't double-process anything.
• A self-service customer portal for plan changes and cancellations.
• Basic tax handling appropriate to where your customers are, plus dunning logic for failed renewals.
• A clear internal record of subscription state that doesn't depend on Stripe being the only source of truth.

Stripe's own documentation covers the webhook event catalog in detail, and it's worth a team member's time to actually read it rather than trust that a single prompt captured all of it. Pricing for this kind of hardening varies with subscription complexity; our 2026 pricing guide has the full comparison table across every engagement tier we offer. For most single-product SaaS apps, payment hardening is one component of a broader Production Readiness Sprint rather than a standalone engagement, because payment bugs and access-control bugs tend to live in the same parts of the codebase and get fixed together.

Vibe-coded demos are built and tested against the happy path, so production hardening means explicitly handling every failure, empty, and loading condition an AI builder's default prompt never asked about. Watch someone demo a freshly built app and it's always populated with clean sample data, on a fast connection, with every action performed once, in order. Real usage looks nothing like that: a network drops mid-request, a list has zero results because the account is brand new rather than because something broke, someone double-clicks submit before the first click resolves, a form gets submitted with a field the user didn't realize was required.

• Error states: A failed API call shows a real, actionable message instead of a blank screen or a raw stack trace.
• Empty states: Distinguishing "no data yet," "no results for this filter," and "something went wrong" — each needs different UI and different copy.
• Loading states: Skeleton screens or spinners wherever a request is in flight, with rapid repeat submissions disabled or debounced.

Add basic offline handling and inline form validation feedback, and you've closed most of the gap between "works when I click through it" and "works when a stranger clicks through it unsupervised." Our post-launch checklist has a practical list of exactly what to click-test for this, screen by screen, if you want to self-audit before engaging anyone.

You don't need full test coverage to ship safely. You need automated tests for the handful of flows that would genuinely hurt the business if they silently broke: signup, checkout, and whatever your core workflow is. Zero automated tests is close to the default state for a vibe-coded app, because writing tests isn't what a demo-oriented prompt session produces. The problem starts once real users depend on the app and every future change — including further AI-prompted edits — risks silently breaking something that used to work.

The pragmatic approach is to protect the paths where a regression is expensive, not to chase blanket coverage. That typically means end-to-end tests (Playwright or Cypress are the standard tools) for account signup, the checkout and subscription flow, and the one or two workflows that constitute the actual product, plus targeted unit tests for business logic that's easy to get subtly wrong — pricing calculations, permission checks, date and timezone handling. It's a deliberately incomplete strategy, and that's the point: it's the 20% of testing effort that covers 80% of the real risk. But tests only pay off if they actually run before code reaches production.

Many vibe-coded apps deploy by clicking "Publish" inside the builder with no staging environment, no automated checks, and no rollback path — meaning one bad prompt or manual edit ships straight to every production user with nothing in between. This is less visible than a payments bug but arguably more dangerous, because it's the delivery mechanism for every other bug. Without a staging environment, changes are validated, if at all, against production data by the person who made them. Without an automated test gate, your test suite only protects you if someone remembers to run it manually before every deploy — which, reliably, nobody does after the first few weeks.

• A separate staging environment that mirrors production closely enough to catch real issues.
• Environment variables and secrets managed outside the codebase.
• A CI pipeline that runs your critical-path tests automatically on every change and blocks the deploy on failure.
• Preview deployments for review before merge.
• A documented, tested rollback procedure for both application code and database migrations.

None of this needs to be elaborate — a small app can run a perfectly adequate pipeline on free-tier CI — but it needs to exist and be exercised, not just configured once and ignored. If your app has outgrown what its original no-code platform can support for this kind of workflow, our guide to migrating off no-code AI platforms covers when that trade-off becomes worth making.

Without error tracking, uptime monitoring, and structured logs, the first sign of a production incident is an angry customer email — not an alert your team sees before the customer does. A vibe-coded app in its early weeks typically has none of it: exceptions get swallowed or logged to a console nobody's watching, there's no automated check confirming the app is even reachable, and diagnosing a failure means guessing rather than reading a trace.

The minimum viable setup is small: error tracking with source-map support so stack traces point at real code rather than minified gibberish (Sentry is the common choice here), uptime monitoring that checks the app is actually responding on a schedule and alerts a human when it isn't, structured logs you can actually search when investigating an incident, and a small dashboard for the handful of business metrics that matter — signups, active subscriptions, failed payments. It's a few hours of setup that turns every future incident from a mystery into a quick diagnosis. If you'd rather this run on an ongoing basis, it's a core part of both our app maintenance and support service and the Full Takeover & Ongoing Development Retainer tier.

Performance problems in vibe-coded apps tend to cluster around a few recurring patterns: N+1 database queries where a loop fires one query per item instead of one for all of them, missing indexes on columns the app filters or joins on constantly, unoptimized images and oversized JavaScript bundles shipped to every visitor, and layout shifts from content that loads in after the initial render. Individually minor, these compound quickly once real traffic and real data volumes show up — a query that's fine against 50 test rows can be genuinely slow against 50,000 real ones.

A performance pass runs a Lighthouse or Core Web Vitals audit (Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint) and fixes what it finds, reviews database queries for the obvious N+1 and missing-index patterns, and adds basic load testing — tools like k6 or Artillery simulating concurrent users — before any launch push or marketing campaign that could send a spike of traffic at an app that's only ever been tested one user at a time. This is also a natural moment to revisit whether the current hosting and database tier can actually support where the app is headed; our MVP scaling and migration guide covers that decision in depth.

A privacy policy, terms of service, cookie consent, database backups, and — for native wrappers — app store compliance are rarely generated by a prompt, and skipping them creates real legal and business-continuity risk rather than just a polish gap. Every app that collects user data needs a privacy policy and terms of service that accurately describe what's actually collected and how it's used. Generic boilerplate copied from another site is a liability, not a shortcut, because it can describe practices you don't actually follow or fail to describe ones you do. If you serve EU or California users, GDPR and CCPA basics apply: a lawful basis for processing, a way for users to request deletion, and a cookie consent mechanism if you use tracking or analytics cookies.

Managed Postgres providers, including Supabase, offer automated backups and point-in-time recovery on paid tiers — but it's common for a vibe-coded project to still be on a plan where that isn't actually enabled, or to have never tested whether a restore genuinely works. Production readiness means confirming backups run on a schedule, defining a recovery point objective (how much data you can afford to lose) and recovery time objective (how long a restore should take), and actually executing a test restore rather than assuming one will succeed under pressure.

If the app ships as a native wrapper around a web build, both Apple and Google apply extra scrutiny: thin WebView-only apps with no native functionality are commonly rejected or flagged, and both platforms require accurate data-collection disclosures — Apple's privacy nutrition labels and Google's Data Safety section — that a web-first build usually hasn't prepared. Budget real time for review cycles and for demonstrating genuine native value, not just for filling out the submission form. For broader context on where mobile builds fit, see our custom mobile app development guide. As with every section in this guide, you can work through all of this yourself with enough AI prompting and manual research — but legal review, tested backup restores, and app store compliance are exactly the kind of unglamorous, easy-to-defer work that benefits from a scoped sprint with a checklist and a deadline, rather than staying permanently on the someday list.

Use this table as a self-audit — for each row, be honest about whether your app is at "typical demo state" or actually meets the production requirement next to it.

If most rows on your app are still in the middle column, that's not unusual for a vibe-coded MVP — it's the normal state of a tool that proved a concept quickly. The question is simply how much of the right column you need before you scale traffic, take real payments, or hand the app to users who aren't forgiving of downtime. That's precisely the scope of a Production Readiness / Finishing Sprint ($10,000-$35,000, 2-6 weeks): working through this table systematically rather than discovering each row's gap the hard way, one incident at a time.

Frenchy Digital runs Production Readiness / Finishing Sprints for apps built in Lovable, Bolt.new, Replit, Base44, and similar AI builders — closing the exact gap mapped in this guide, checklist item by checklist item, rather than working from a generic audit template. We're based in Los Angeles, with international teams in Geneva, Switzerland and Paris, France, so a Finishing Sprint can move across time zones without stalling between handoffs.

Pricing scales with scope: our 2026 pricing guide compares every tier, from a $1,500-$3,500 Vibe Code Health Check up through a full Production Readiness Sprint at $10,000-$35,000, and an ongoing Full Takeover & Development Retainer at $2,000-$6,000/month for teams that want continued support after launch. Because we start from your existing codebase rather than a blank slate, finishing an app is typically 30-50% cheaper and faster than a from-scratch professional rebuild of the same finished scope.

Ready to take your vibe-coded app the rest of the way to production? Schedule your free discovery call and walk through the checklist above against your actual app — we'll tell you honestly which rows are already fine and which ones are worth fixing before you scale.