Vibe-Coded App to Production: Checklist & Costs (2026)

Yes, most vibe-coded prototypes can reach production, but very few should ship as they are. As of October 2026, the fix usually takes one of three paths: harden (days: lock down data access, secrets and payments), refactor (a few weeks: add tests, structure and observability around the flows that matter), or rebuild the core (about 6–10 weeks on a clean foundation, keeping the UI and what you learned). Which path you need depends on what an audit finds, not on which tool you used to build it.

Lovable, Bolt, Replit, v0 and Cursor are very good at producing something that works in preview. Production asks harder questions. Who can read whose data? What happens when a webhook arrives twice? What does it cost when 1,000 people use the AI feature at once? Who gets paged when it breaks? This guide gives you a decision table, published 2026 prices, a 25-point checklist you can run yourself, and a plain account of what BeevR does when a prototype has to become a product.

Can a vibe-coded app go to production as-is?

Usually not without at least a security and data-access review. The code an AI app builder writes can be perfectly fine. The issue is that nobody has checked the parts a demo never touches: access rules, secrets, failure handling, cost limits and recovery. A prototype is built to show the happy path once. A product has to survive every other path, every day, with real users' data.

A useful rule: if your app stores personal data, takes payments, or lets users see each other's records, treat it as unreviewed until someone has checked access control end to end. If it is a single-user tool with no sensitive data, a lighter pass may be enough.

Why do vibe-coded apps break in production?

They break where the prototype skipped the boring parts, and the 2025–2026 data shows the same few failure points again and again:

• Database access left open. In 2025 a researcher scanned 1,645 Lovable projects and found 303 vulnerable endpoints across 170 of them (about 10.3%), caused by missing or weak Row Level Security. It was filed as CVE-2025-48757 (CVSS 9.3). Lovable disputes the CVE on the grounds that each customer is responsible for protecting their own app's data, which is exactly the point: someone has to own that check.
• Problems at scale across platforms. Escape.tech scanned more than 5,600 publicly available vibe-coded apps (published October 2025) and reported more than 2,000 vulnerabilities, 400+ exposed secrets and 175 instances of exposed personal data, including medical records and IBANs. The most common pattern was a Supabase backend reachable with the public key because access policies were missing.
• Insecure defaults in generated code. Veracode's 2025 GenAI Code Security Report tested code from more than 100 LLMs on 80 tasks and found security flaws in 45% of cases. Newer and larger models did not do meaningfully better.
• A growing trail of real CVEs. Georgia Tech SSLab's Vibe Security Radar catalogues public vulnerabilities whose root cause traces to AI-written code. As of its 26 September 2026 cutoff it lists 312 cases, rising from 15 in February 2026 to 68 in July 2026. Injection and unsafe execution (116) and authentication and access control (75) are the largest root-cause groups. The project calls this a lower bound, and it says the data is not a comparison of AI-written versus human-written code.

Two practical notes for 2026. Supabase says it is deprecating the legacy anon and service_role keys by the end of 2026 in favour of publishable and secret keys. Many prototypes still ship the old keys, so plan the migration. Supabase's own rule also still holds: the browser key only reaches what Row Level Security allows, and the secret key bypasses it, so it must never reach the client.

Should you harden, refactor or rebuild your vibe-coded MVP?

Choose by symptom. Most founders over-rebuild out of panic or under-fix out of hope. Here is the decision table we use when we review a prototype:

Two signals that you need a rebuild, not a refactor: you cannot explain your own data model on one page, or the app only runs inside the builder's hosting. Exporting the code but not the environment is not ownership.

What does it cost to take a vibe-coded prototype to production in 2026?

Published offers in October 2026 range from a few hundred dollars for a quick audit to $15,000–$50,000 for a full rebuild. We checked public pricing pages on 7 October 2026:

For comparison, BeevR publishes three fixed MVP packages on its MVP development cost page: a Pitch Demo at $4K (about 10 days, one core workflow on real infrastructure), an Investor MVP at $18K (about 6 weeks, 3–5 core workflows, auth and role-based access, tested to survive due diligence) and a Flagship Sprint at $38K (about 10 weeks, 5–8 workflows, full test suite and load testing, automated deploy with rollback, full observability). A rebuild of a vibe-coded core usually falls in the Investor MVP range of scope. A product that needs to scale after a round looks more like the Flagship Sprint. If regulated data is involved, BeevR's published rule of thumb is that building compliance in adds about 15–25%, while bolting it on later adds 40–80%.

The cheapest outcome is rarely the cheapest number. A $300 audit that tells you to rebuild can save you a $10,000 refactor of code you will throw away. Spend on the audit first.

What is on a production-readiness checklist for an AI-built app?

Run these 25 checks before real users or real money touch the app. Each one is a yes/no; any "no" in the first two groups blocks launch.

Data access and auth (launch blockers)

1. Row-level access rules are on for every table that holds user data, and you have tested them with a second, non-admin account.
2. No secret or service key appears in the browser bundle, the mobile app or the public repo (search the built JS, not just the source).
3. Every API route checks who the caller is and whether they may touch this specific record.
4. Admin functions live behind a separate role, not a hidden URL.
5. Passwords, sessions and resets come from a proven auth provider, not hand-written code.
6. File storage buckets are private by default, with signed URLs for sharing.

Secrets and payments (launch blockers)

7. All keys that ever reached a prompt, a chat log or the client have been rotated.
8. Payment webhooks verify the provider's signature and are idempotent (a replayed event does not double-charge or double-provision).
9. Prices and plan limits are enforced on the server, never trusted from the client.
10. Card data never touches your servers (hosted checkout or tokenisation keeps you out of most PCI scope).

Reliability

11. Automated backups exist, and you have restored one at least once.
12. Rate limits on login, signup and any endpoint that costs money (AI calls, SMS, email).
13. Input validation on the server for every form and API body.
14. A staging environment that is not production, with separate keys.
15. Database indexes on the queries behind your main screens.
16. Deploys are scripted and can be rolled back in one step.

Observability

17. Error tracking on frontend and backend, routed to a person.
18. Structured logs with request IDs, and no personal data or secrets in them.
19. Uptime check plus an alert on the one flow that makes money.
20. An audit trail for sensitive actions (role changes, exports, deletions).

AI features

21. Hard spend caps per user and per day on LLM calls, with alerts before the cap.
22. Prompts and tool calls cannot reach data the current user may not see.
23. Model output is treated as untrusted input: never executed, never inserted into SQL or HTML unescaped.
24. If EU users talk to the AI, it says so at the first interaction (see our EU AI Act Article 50 developer checklist).

Ownership

25. You own the repository, the cloud accounts, the domain and the database, under your company's name, and the app runs outside the builder's hosting.

How do you audit a vibe-coded app yourself in an afternoon?

You can catch most launch blockers in about four hours without being an engineer. Work through these in order:

1. Two-account test (1 hour). Create two normal user accounts. As user A, create records. As user B, try to open A's records by changing IDs in the URL, and repeat the same calls from the browser's network tab. If anything loads, stop and fix access control first.
2. Bundle search (30 min). Open the deployed site, view the loaded JavaScript, and search for secret, service_role, sk_live and your provider names. A publishable or anon key is expected. A secret key is a launch blocker.
3. Payment replay (30 min). In your payment provider's test mode, resend the same webhook event twice. Check you did not grant access or credit twice.
4. Cost check (30 min). Look at your LLM provider's usage page and set a hard monthly limit plus an alert. Then estimate the cost of one active user per day and multiply by your launch target.
5. Restore drill (1 hour). Take a backup and restore it into a scratch database. If you cannot, you do not have backups.
6. Ownership check (30 min). List every account the app depends on (hosting, database, auth, email, payments, AI keys, domain). Note who owns each. Anything in a freelancer's or a tool's name gets moved to yours.

If steps 1–3 pass cleanly, you are probably in "harden" territory. If they fail in several places, get a professional review before you spend on fixes.

What does BeevR do when a prototype needs to become a product?

We start with a senior review of what exists, keep what works, and quote the fix as a fixed price per phase, with no hourly meter. Concretely, from work published on beevr.ai:

• Prototype-to-production is work we have shipped. In our macOS security agent case study, the client's agent ran fine interactively but broke as a system daemon, and it could not be installed without signing and notarisation. We fixed the execution model at the root, rebuilt it under Apple's Hardened Runtime, and left the client a one-command signed-installer pipeline. It was an Investor MVP engagement, delivered at a fixed price with zero scope creep. It was not vibe-coded, but it is the same gap: the demo works and the product does not.
• Published, fixed prices. The $4K / $18K / $38K packages above are on our pricing page, and you own 100% of the code, IP and repository from day one.
• Regulated data handled by design. We build HIPAA-aligned, BAA-backed AI agents with PHI masking and tamper-evident audit logs, and payment systems architected to PCI DSS 4.0, such as a unified payment gateway suite over Stripe, Adyen and PayPal on serverless AWS. Our security page lists the controls and states which standards we are aligned with rather than certified for.
• Rescue for stalled AI builds. Our AI agent development service includes agent rescue: a stalled pilot, a cost blowout or a compliance block. We audit the build, keep what works and re-architect the governance.
• Open code you can inspect. Kite, our MIT-licensed agent framework, treats the LLM as untrusted, with kernel validation, a kill switch and idempotency. Nebula runs GraphRAG entirely in the browser (Apache-2.0, 430+ tests). Both are on BeevR Labs.
• Production AI plumbing we run ourselves. beevr.ai and our ESG product ecocheck.ai each run a public, read-only MCP server so AI assistants can query them directly. You can read the server cards at beevr.ai and ecocheck.ai.

More shipped work is on our case studies page. If your prototype is headed to investors, read what investors check in an MVP as well.

FAQ

Is a Lovable or Bolt app secure enough for production?

It can be, but only after someone checks access rules, secrets and payments. The platforms generate working apps fast. Securing user data is still the app owner's responsibility, as the dispute over CVE-2025-48757 made clear.

How much does it cost to fix a vibe-coded app?

Published offers in October 2026 run from about $299–$3,000 for an audit and roughly $6,000–$10,000 to start a rescue sprint, up to $15,000–$50,000 for a full rebuild. For comparison, BeevR's fixed Investor MVP package is $18K for about 6 weeks.

Should I rebuild from scratch or fix what I have?

Fix it if the data model is sound and the problems are missing controls. Rebuild the core if the data model is wrong, auth is home-made, or every change breaks something else. Keep the UI and the user insight either way.

Can I keep using AI coding tools after the rescue?

Yes. Once tests, access rules and a review step are in place, AI tools become much safer to use, because mistakes are caught before they ship instead of by your users.

How long does it take to make a vibe-coded MVP production-ready?

Hardening takes days to about two weeks, a refactor about 3–5 weeks, and a core rebuild about 6–10 weeks. Regulated data pushes you toward the longer end.

BeevR is a senior, founder-led software and AI studio in Hanoi, Vietnam: fixed price per phase, full code and IP ownership from day one, and production AI for regulated industries. If you have a prototype that works in preview, tell us what you built. We will tell you honestly whether it needs hardening, a refactor or a rebuild, and give you a fixed number.