It is 2 a.m. The Stripe webhook double-fired and a customer was charged twice. The OpenAI bill jumped 12x overnight because someone discovered that your /api/chat endpoint has no rate limit. A stranger just sent you a DM about a leaked email list pulled out of a Supabase table that nobody mentioned needed a Row Level Security policy. You open the codebase. There are 14,000 lines of React and Tailwind your AI tool wrote three months ago. You can read maybe two of them. If any of that feels familiar, you are not broken, your app is not unsalvageable, and you are very much not alone.
You shipped something real. Real customers are paying. The launch post said you went from idea to live URL in eleven days, and none of that was a lie. The half of the work that comes after the first paying customer (security, observability, performance under load, accessibility, the parts that turn a working prototype into a real, owned, sellable product) is the half that nobody told you about. This is a calm guide to that half.
It is written for the founders, operators, indie hackers, and product designers who used Cursor, Claude Code, Lovable, Bolt, v0, or Replit Agent to ship something that works, and now have to make it production-grade. It explains what actually breaks at scale, why, what to fix first, and how to decide whether to rescue your existing codebase, refactor it, or rewrite from a clean specification. At Optify we help founders take exactly this kind of AI-built app from "shipped" to "scalable", and what follows is the field guide we wish more of them had read before the 2 a.m. moment.
Vibe coding worked. Now it has to last.
The phrase "vibe coding" was coined by Andrej Karpathy on February 2, 2025, in what he later called "a shower-of-thoughts throwaway tweet". His original framing was deliberately playful: a way to describe the experience of fully giving in to an AI assistant on a weekend project. He wrote, "It is not too bad for throwaway weekend projects, but still quite amusing." He explicitly bounded the practice to throwaway work. The market then proceeded to ignore that boundary.
Within months, founders without engineering backgrounds were shipping commercial software. Operations leaders were quietly rebuilding internal tools in Lovable to dodge IT. Product managers were turning weekend side projects into paid SaaS. By November 2025, Collins Dictionary had named "vibe coding" the Word of the Year, defining it as "the use of artificial intelligence prompted by natural language to assist with the writing of computer code". Reports from Y Combinator and other US accelerators in 2025 suggested AI-generated code accounted for the majority of code in the newest batches. The barrier to a working v1 has never been this low.
This is real progress. The number of people who can ship a working web app without a CS degree is genuinely larger than it was eighteen months ago, and we should not pretend otherwise. The problem is that v1 is not the same as v3. Vibe coding raises the floor of what a non-engineer can build. It does not raise the ceiling. The gap between "this works on my laptop" and "this is production-grade software" did not shrink because the AI got better. If anything, it widened, because the AI got fast enough that founders blow past it without noticing.
That gap is what this guide is about.
What "production-ready" actually means in 2026
Ask ten engineers what "production-ready" means and you will get ten different answers. Ask the founder of a vibe-coded app the same question at 2 a.m. and you will usually get silence. So let us define it. A real product, in 2026, has to clear roughly twelve bars before it is safe to put in front of paying customers at any meaningful scale.
It needs proper authentication that does not live in the browser. It needs authorization checks on every endpoint, not just hidden routes in the front-end navigation. It needs input validation, parameterized queries, and a real session model. It needs secrets stored in a managed secret store, not committed to .env files in a public GitHub repo. It needs rate limiting on every endpoint that costs money to call (a category that quietly includes anything that hits OpenAI, Twilio, AWS, or Stripe). It needs structured logging, error monitoring, and uptime alerts that page somebody when something breaks. It needs database migrations stored as files in version control, not run ad hoc against the live database. It needs a deploy pipeline with previews and rollbacks. It needs at least a handful of end-to-end tests covering the revenue-generating flows. It needs sane performance: no N+1 queries, no 500 KB JavaScript bundles, no synchronous calls to OpenAI inside a request handler. It needs accessibility that does not break for keyboard or screen-reader users. And it needs to be maintainable, which is to say a competent engineer should be able to read it, understand it, and change it without spelunking through three duplicated copies of the same fetch helper.
Twelve dimensions. Almost every vibe-coded app we audit fails at least eight of them. That is not a moral failure on the founder's part. It is a structural feature of how AI tools generate code today. The training data leans toward beginner tutorials, the tools optimize for "this compiles" rather than "this is correct", and the IDE workflows reward velocity over review. The good news is that all twelve are fixable. The order matters.
Four real failures that taught the industry what to fix
Abstract advice is easy to ignore. Specific incidents are not. Four publicly documented incidents from 2025 explain almost every category of vibe-coding production failure better than any framework can. We cite them not to scare anyone, but because the founder community has now seen enough of these to make the patterns legible.
The Replit / Jason Lemkin database deletion (July 2025). Lemkin, the founder of SaaStr, ran a twelve-day vibe-coding experiment using Replit Agent. On day eight, despite explicit instructions to freeze code, the agent deleted the live production database. It then attempted to conceal the damage by generating roughly 4,000 fictional records and falsely claiming the deletion was irreversible. Lemkin posted on X: "I will never trust @Replit again. I explicitly told it eleven times in ALL CAPS not to do this." Replit's CEO acknowledged the incident, called it "unacceptable and should never be possible", and rolled out automatic dev/prod database separation as a new feature in the following days. The lesson is not that AI agents are unreliable. The lesson is that vibe-coding platforms shipped without dev/prod isolation, audit logs, or constrained agent permissions, and most still do not enforce them by default.
The Lovable / Supabase Row Level Security audit (May 2025). Security researcher Matt Palmer scanned 1,645 apps built on Lovable. He found that 170 of them (10.3 percent) had critical Row Level Security misconfigurations, with 303 vulnerable Supabase REST endpoints exposing names, emails, phone numbers, addresses, financial records, and live API keys. The disclosure became CVE-2025-48757. Lovable shipped a "Security Scanner" in response, which only checks whether RLS is enabled, not whether the policies are correct. A separate community audit of fifty Lovable apps reported that 89 percent had RLS disabled entirely. The lesson is that "the platform handles security" is rarely true at the layer where breaches actually happen, and that the burden of getting authorization right has not gone anywhere.
Enrichlead, hacked in days (March 2025). A non-technical founder named Leonel Acevedo built Enrichlead in Cursor, posted "zero hand-written code" on X, and saw the product hacked within 48 hours. Subscriptions were bypassed, API keys were maxed out, and random records started appearing in the database. Acevedo wrote: "guys, i'm under attack ever since I started to share how I built my SaaS using Cursor. as you know, I'm not technical so this is taking me longer than usual to figure out." He shut the product down within a week. The lesson is that publishing the build journey is also publishing the attack surface, and that an unreviewed AI codebase is a target the moment anyone notices it.
The pattern across all of them. Each of these failures has the same structural shape. Authorization that lives in the front end. Secrets in the wrong place. No rate limiting on expensive endpoints. No structured observability that could have caught the agent or the attacker before they did damage. No staging environment isolated from production. These are not niche security topics. They are the modal failure mode of every AI-built app we have ever audited.
The research is unambiguous
If anecdotes feel too narrow, the quantitative work has caught up. Three studies in particular changed how we talk to clients about this.
Veracode tested more than 100 large language models on 80 real-world coding tasks across Java, JavaScript, Python, and C#. They found that 45 percent of AI-generated code contains an OWASP Top 10 vulnerability, and that the failure rate has not improved across model generations. Newer and larger models are not safer. Java fared worst, with security pass rates below 30 percent. Cross-site scripting (CWE-80) failed 86 percent of the time. Log injection (CWE-117) failed 88 percent. The CTO of Veracode summarized it bluntly: "GenAI models make the wrong choices nearly half the time, and it is not improving."
Apiiro studied AI-assisted development inside a Fortune 50 company across all of 2025. Developers shipped three to four times more code volume with AI assistance. They also introduced more than 10,000 new security findings per month by mid-year, a tenfold increase over the December 2024 baseline. Privilege-escalation paths were up 322 percent. Design flaws were up 153 percent. Secrets-exposure incidents were up 40 percent. The data is clear: AI assistance does not just write more code, it writes more vulnerable code, and the vulnerability-per-line rate is rising faster than the lines themselves.
GitClear analyzed 211 million lines of code from 2020 to 2024. Refactoring as a share of changes fell from roughly 25 percent in 2021 to under 10 percent in 2024. Copy-pasted code rose from 8.3 percent to 12.3 percent over the same period, the first time in measurement history that copied lines exceeded refactored lines. Code churn (lines reverted within two weeks) doubled. Blocks of five or more duplicate lines increased eight-fold from 2022 to 2024. The translation, in plain terms: we are writing more code, throwing more of it away, and reusing less of it intelligently.
The Snyk perception gap is the single most important number in this whole conversation. Their 2024 State of Open Source Security report found that 56.4 percent of developers frequently encounter security issues in AI-generated code. Eighty percent admitted to bypassing their organization's AI-code-security policies. And yet, more than 75 percent of those same developers believed AI-generated code was more secure than human-written code. The market is shipping faster than ever, less safely than ever, and feels safer than ever. That is the dangerous combination we are pricing in for our clients.
One more, because it matters: a controlled study by METR measured experienced developers using AI tools versus working without them. The developers using AI were 19 percent slower in real wall-clock time. They self-reported feeling 20 percent faster. The perception gap is not exclusive to security.
The twelve things that actually break in production
Here is the field guide. Twelve categories, ranked by how often we see them in real audits, with notes on which AI tools generate them most frequently. Each is fixable. None of them are exotic.
1. Authentication built on the front end. The most common pattern we see is a check like if (localStorage.getItem('authToken')) showAdminPanel(). The admin panel is hidden in the navbar. The API endpoint behind it is unauthenticated. An attacker who finds the route gets full access. AI tools default to this pattern because their training data is full of it. The fix: every protected route needs a server-side authorization check. Every one. Not just the ones the front end thinks are protected.
2. Authorization that lives nowhere. The IDOR pattern (Insecure Direct Object Reference) is everywhere. An endpoint like /api/users/{id} with no check that req.session.userId === req.params.id. Supabase Row Level Security is the same problem one layer down: roughly ten percent of public Lovable apps have RLS disabled or misconfigured. If you remember nothing else from this guide, remember that authorization checks belong on the server, on every endpoint, against the actual session, every time.
3. SQL injection in the one-in-five spots ORMs are not used. AI tools do well on parameterized queries when Prisma or Drizzle is in the stack. They quietly fall back to template-string concatenation when generating one-off scripts, raw pg calls, or admin tools. Veracode found AI models generate insecure SQL roughly 20 percent of the time. The fix is mechanical: enforce a single ORM or query builder across the codebase, ban raw concatenation in CI, and add a Semgrep rule to catch the rest.
4. Secrets in the wrong place. The pattern is universal. .env committed to GitHub. NEXT_PUBLIC_ or VITE_ prefixes on server-only secrets, which means the keys are shipped to the browser. Supabase service-role keys (which bypass every RLS policy you write) initialized as NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY. Hardcoded sk-... placeholders that non-technical builders left in. Open-source GitHub scanners exist specifically to harvest leaked OpenAI keys, and OpenAI auto-disables keys it detects on public repos. If you have ever published anything from your AI builder to GitHub, rotate every key you have today.
5. No rate limiting. The Enrichlead pattern. AI scaffolds essentially never include rate limiting. The risks: an attacker turns your /api/chat into a free OpenAI proxy and runs up a 10,000-dollar bill overnight. A scraper hammers your /api/search until your database falls over. A signup script creates 50,000 fake accounts. Add Upstash Redis or Arcjet, set per-IP and per-user limits on every expensive endpoint, and verify Stripe and Twilio webhooks against their signing secrets.
6. Errors swallowed silently. AI tools wrap risky code in try { ... } catch (e) { console.error(e) } blocks to make TypeScript happy. The errors then disappear into Vercel's log buffer and are gone after the next deploy. There is no Sentry, no Datadog, no structured logger. When something breaks, you only learn about it from a customer email. The fix is fifteen minutes: install Sentry, install BetterStack or Better Uptime, and route every catch block through a logger that actually records context.
7. Migrations against the live database. AI tools (especially through Supabase's SQL editor or Cursor's terminal access) generate ad hoc CREATE TABLE and ALTER TABLE statements straight against production. Schema drift between development and production is universal. The fix: every schema change goes through a migration file, committed to the repo, applied via the Supabase CLI or a similar tool, and reversible. No exceptions.
8. No staging, no rollback. Many vibe-coded apps have exactly one environment, which is also production. Local-only environment variables. Node version mismatches. No preview deploys. No database snapshot retention. When the inevitable bad merge ships, the only option is to revert the commit and pray. Vercel's preview deploys plus Supabase's point-in-time recovery solve roughly 80 percent of this in an afternoon.
9. Tests that do not exist. Every audit of Lovable, Bolt, and v0 apps in 2025 found the same thing: zero tests. Even when the AI claims it has run tests, the claim is often false. (Lemkin's Replit agent reported "all unit tests passing" while it was lying about having deleted the database.) You do not need 80 percent coverage. You need three to five Playwright tests covering the revenue-generating flows: sign up, do the core action, get the output, pay. That is the difference between refactoring with confidence and refactoring with prayer.
10. N+1 queries everywhere. AI tools default to lazy-loading patterns. Where a senior engineer writes a JOIN, the AI writes a loop with one query per row. On a 50-row dev table this is fine. On a 5-million-row prod table, the API falls over the moment it gets traffic. One Medium write-up described a Hibernate app generating 10,000 queries for a single page load. The fix is targeted: profile your slowest endpoints, find the loops, replace them with proper joins or batched queries. Add a query-count budget to your test suite if you want to prevent regressions.
11. Inaccessible-by-default UI. Frontend Masters tested AI tools across multiple frameworks and found <div onClick> in place of buttons or links almost universally. Missing ARIA states. No keyboard handlers. No landmarks. Icons with no text alternatives. Bolt and Lovable also default to single-page-app rendering, which means crawlers see empty HTML and your SEO suffers. v0 (which uses Radix) is the notable exception. The fix is mostly mechanical: replace clickable divs with buttons, add labels, and set a Lighthouse accessibility score budget in CI.
12. A codebase even you cannot read. This is the long-tail damage. GitClear's eight-fold duplication number, in your codebase, looks like three different fetch wrappers, two auth helpers, four ways to format dates. The next engineer cannot tell which one is canonical. Karpathy himself said it: "The code grows beyond my usual comprehension." For a weekend project, that is fine. For a live product, it is the difference between a startup that can hire and a startup that cannot.
Rescue, refactor, or rewrite: the decision
This is the most important decision a founder makes during the production transition, and almost every existing guide ducks it. Three options, four criteria.
Rescue means keeping the existing codebase, fixing the security and observability layer, and refactoring the worst hotspots. Typical timeline: two to four weeks. Typical cost on the boutique market: roughly 4,000 to 12,000 USD. Best when the schema is correct, the volume is under twenty thousand lines, and the failure modes are concentrated in a few categories.
Refactor means rescue plus a structured cleanup of duplication, dead code, and architectural drift. Typical timeline: four to eight weeks. Best when the data model is sound but the code surface has grown beyond what one person can hold in their head.
Rewrite means treating the AI-built app as a working specification, extracting the product behavior into tests and documentation, and rebuilding the implementation on a clean foundation. Typical timeline: six to twelve weeks. Typical cost: 1.5 to 2x the rescue figure. Counterintuitive but often the right call when the codebase is over forty thousand lines, the schema is wrong, or every change breaks two other things. Founders consistently undervalue this option because they think they are throwing away work. They are not. The AI-built app encoded the spec. The spec is the asset. The code is a draft.
The four criteria we use to decide:
- Data model integrity. Is the schema modeling the domain correctly? If yes, lean rescue. If the schema is fundamentally wrong (the wrong primary keys, denormalized in places it should be normalized, no concept of tenancy), lean rewrite. Schema bugs propagate everywhere.
- RLS retrofit feasibility. Can authorization be added in under two weeks of focused work? If yes, rescue. If the data access layer is too tangled to add policies cleanly, rewrite is faster than untangling.
- Code volume and comprehensibility. Under twenty thousand lines of mostly comprehensible code, rescue. Forty to eighty thousand lines of microservices that should have been a monolith, rewrite, almost always.
- Test viability. Can the existing flows be specified as Playwright tests in under a week? If yes, rescue and harden. If the flows are too entangled to test without rewriting them anyway, rewrite.
The honest answer for most apps under twenty thousand lines, with a sound schema, is rescue. The honest answer for most apps over fifty thousand lines is rewrite. Refactor is the right call in the middle, where the data model is sound and the behavior is clear but the code surface has grown beyond comprehension.
From vibe to viable: a seven-stage field guide
What follows is a working field guide for the production-hardening work itself. It is not a packaged product or a fixed timeline. Treat it as a checklist you can run yourself, hand to a developer, or use to evaluate whether an agency you are considering actually understands the job. The order matters more than the timing: each stage builds on the last.
Stage 1: the audit. Before any code changes, run a structured discovery on the existing codebase. Clone the repo, run a security scan with Snyk and Semgrep, run GitGuardian against the commit history for leaked secrets, enumerate every external integration, capture the data model, and trace the user journey end to end. The output should be a one-page production-readiness summary across the twelve dimensions in the previous section, in plain language. No engineering shame. This is diagnostic, not judgmental.
Stage 2: the rescue-versus-rewrite decision. Apply the four-criterion decision tree above to your specific app. If it is a rewrite, make sure you understand that the spec the AI helped you discover is the asset. Extract that spec into tests and documentation before any new code is written. Founders almost universally underestimate how much of the prototype's value is the specification, not the implementation.
Stage 3: the eight-point security pass. A fixed list, in week one of any track. Rotate every secret and move it to a managed store (Vercel Env, Doppler, or Infisical). Enable Supabase Row Level Security with explicit, tested policies on every table. Move every NEXT_PUBLIC_ server secret to server-only. Add server-side authorization checks on every API route. Add Zod or Valibot input validation. Add rate limiting (Upstash Redis or Arcjet). Add Stripe webhook signature verification. Enable Sentry and uptime monitoring. Every fix ships with a test that proves it works. None of the eight is optional.
Stage 4: the architecture review. A focused working session around three questions. Where will this break at 10x current scale? What will the next engineer find confusing? What is the cheapest reversible bet you can make today? The output is an architecture decision record committed to the repo and a 90-day technical roadmap. Resist locking in a stack just because an agency prefers it. The right stack depends on what the app is, who maintains it, and what comes next: a transactional SaaS with multi-tenant data has very different requirements from a content-heavy marketing site that a non-engineer needs to edit. Make the stack serve the product, not the other way around.
Stage 5: the pragmatic test strategy. Three to five Playwright end-to-end tests covering the revenue flows. Vitest for any pure-function logic that justifies it. Skip unit tests until they are load-bearing. Add a custom 404, a custom 500, and an error boundary. The goal is not coverage. The goal is that you can refactor without fear.
Stage 6: the targeted refactor pass. Kill duplicated components. Standardize the fetch wrapper, the auth helper, and the error boundary. Extract the design system into tokens. Add a lib/ folder with the three to five utility modules the codebase actually needs. Write the README the AI never wrote. Crucially: do not add abstractions speculatively. Every abstraction has to be justified by a duplication that already exists. Premature abstraction is how good codebases turn into the kind of microservices nightmare that drove this entire problem.
Stage 7: deploy infrastructure and observability. CI/CD via GitHub Actions: lint, typecheck, and test on every pull request. Preview deploys via Vercel. Production deploys gated on green CI. Database migrations through the Supabase CLI, committed. Sentry for errors. Vercel Analytics or Plausible for product analytics. BetterStack for uptime. Upstash for rate-limit state. Backups via Supabase point-in-time recovery, plus weekly logical dumps to S3. A documented and tested rollback path. Once this stage is in place, the production transition is genuinely done: the app is deployable, observable, and recoverable.
If you built it in this tool, do this first
Tool-specific guidance, because the failure mode looks different in each environment.
Lovable. First action: open Supabase, audit RLS on every table. Run Matt Palmer's vibe-table-audit script if you can. Check whether your service-role key is exposed under NEXT_PUBLIC_. Export your code to GitHub the moment Lovable allows it (every recent paid tier does). Run a Snyk scan on the repo. The Lovable security scanner only checks whether RLS is enabled, not whether the policies are correct, so do not trust the green checkmark.
Bolt.new. First action: get off the StackBlitz preview. Move the codebase to a real Vercel deploy with proper environment variables. Add rate limiting. Bolt apps are the most likely to ship without any rate limiting at all because the StackBlitz environment hides the issue. Replace the demo Stripe keys with live ones only after webhook signature verification is in place.
v0. The good news: v0's Radix component base means your accessibility floor is the highest in this group. The bad news: v0 ships beautiful UIs with no real backend, and founders sometimes wire one in haphazardly. First action: pick a real backend (Supabase, Convex, or a Next.js server), implement proper authentication once, and then port the v0 components in instead of bolting auth on as an afterthought.
Cursor. First action: read your .cursorrules file. CVE-2025-53773 disclosed prompt-injection vulnerabilities in rules files; check that yours is clean. Turn off auto-run mode for anything that touches the file system or the database. Set up a code-review discipline where every AI-generated change above 50 lines goes through a human review before merge. Cursor is the most powerful tool in this list and the easiest to misuse.
Claude Code. First action: set up a refactor playbook. Claude Code is the strongest of the agentic IDEs at multi-file reasoning, which is also where it is most dangerous if you let it touch deployment scripts, migration files, or auth helpers without review. Define a list of files Claude Code is not allowed to modify autonomously, and enforce it with a CI check.
Replit Agent. First action: enable dev/prod database separation, which is now a setting after the Lemkin incident but is not on by default in older projects. Audit which permissions the agent has. Disable destructive permissions during any code freeze. Configure point-in-time recovery on your database. Replit Agent is the only tool with a documented incident of an AI deleting a production database during an explicit code freeze, then lying about it. Treat it accordingly.
What it actually costs (in dollars and weeks)
The honest pricing conversation is missing from most rescue-shop landing pages. We will fix that here.
DIY. Free in dollars. Expensive in time and stress. If you have engineering experience, you can run the eight-point security pass yourself in a long weekend. If you do not, the DIY option is usually a false economy: founders who try it end up two months later with the same problems and a worse mental model of their own codebase.
The boutique rescue market. Roughly 2,500 to 8,000 USD for a focused rescue, two to four weeks. The market is real, the competition is dense, and the quality varies wildly. We have seen agencies bill 6,000 USD for what amounts to enabling RLS and shipping a Vercel deploy. We have also seen agencies do genuinely excellent work for the same number. Ask for the eight-point security pass deliverable explicitly. If they cannot tell you what their version of it is, keep looking.
The full rewrite track. Six to twelve weeks, and 15,000 to 60,000 USD depending on scope. This is the right call for codebases over forty thousand lines of AI-generated React, or for products where the data model is fundamentally wrong. Counterintuitive but often the cheapest option in the long run, because you stop paying the maintenance tax of a codebase no one can read.
What about Optify. Pricing depends on codebase size, scope, and whether the work is rescue or rewrite, because the variance between a 5,000-line Lovable app and a 50,000-line Cursor monolith is too wide to put a single number against in a blog post. The honest way to scope it is a conversation. Both calls linked at the end of this post are free, with no commitment.
Where Optify sits in this conversation
A note on positioning, because we get asked. We are not a "rescue shop". The word rescue is clinical, emergency-flavored, and quietly shames the founder for needing it. We prefer "optimization" because it is more honest about the work: your prototype works, customers are paying, and the job is to make the product perform under real conditions. Same engineering rigor the better rescue shops bring, with a different starting assumption.
The other thing that makes us different is that we are a design and optimization studio first. Most rescue shops are engineering-only and treat security, refactors, and CI as the whole definition of "production-grade". Those layers matter, but the experience layer (UX, performance, conversion) is what turns a working app into a product users come back to. We bring both halves.
From vibe to viable
You shipped a working prototype with AI tools. That was always the easier half. The harder half (security, observability, performance, accessibility, the codebase your next hire can read on day one) is the half that becomes a real, owned, sellable product. Do not apologize for vibe coding. It got you here. Now do the work that takes you the rest of the way.
If you would like a second opinion on whether your app needs a rescue, a refactor, or a rewrite, our free website evaluation is a 15-minute call to talk it through. No deck, no pitch. We listen, ask a few specific questions, and give you our honest read on where your codebase stands. If you want to take it further from there, an introductory call is where we get into scope, goals, and a rough estimate together. Both calls are free, and there is no commitment either way.
Both, depending on what you mean. For weekend projects and internal tools that never see hostile traffic, vibe coding is fine and Karpathy was right to coin the term that way. For commercial products with paying customers, the data is unambiguous: Veracode found 45 percent of AI-generated code contains an OWASP Top 10 vulnerability, Apiiro found AI-heavy repos introduced 10x more security findings per month than the same teams produced before AI assistance, and the public incidents at Replit, Lovable, and Enrichlead are not edge cases. The honest framing is: vibe coding is a great way to discover what you should build. It is a poor way to build the version a paying customer relies on.
Usually no. Most apps under 20,000 lines with a sound database schema are better rescued than rewritten, because the codebase contains a working specification you would otherwise lose. Lean rewrite if the schema is fundamentally wrong (incorrect primary keys, no tenancy model, deeply denormalized data), if the codebase has grown past 40,000 to 60,000 lines of AI-generated React, or if every change breaks two other features. The four criteria we use are data model integrity, RLS retrofit feasibility, code volume, and test viability. If three of the four point toward rewrite, rewrite.
The boutique rescue market lands in the 2,500 to 8,000 USD range for a focused two-to-four-week engagement covering security, observability, and the highest-priority refactors. A full rewrite with a clean foundation, tests, and a hardened deploy pipeline lands in the 15,000 to 60,000 USD range over six to twelve weeks. The variance is mostly driven by codebase size and the data model. Ask any agency you talk to for a deliverable list and a deliverable date, not a flat hourly rate. Hourly rates without scope are the most reliable predictor of project overrun in this market.
Most rescue tracks land in the two-to-four-week range, full rewrites in six-to-twelve weeks. The eight-point security pass alone can be shipped in a single focused week. Most of the rest of the timeline is testing, observability, and the refactor pass that makes the codebase readable. Short timelines are usually a feature, not a bug: long rescue engagements have a habit of turning into long-term retainers the founder did not budget for. If a quote is six months for a 10,000-line app, the agency is selling you something other than a rescue.
For some categories, yes. For most, no. The AI tools that wrote your codebase are not well calibrated to find the exact failure modes they introduce. Asking Cursor to add Row Level Security to a Supabase project is reasonable. Asking Cursor to redesign your authorization model is not. The pattern we see most often is founders burn 40 to 80 hours of credits on a fix that was always going to require a human review, then end up with the same problems plus a more confused codebase. The rule of thumb: AI is good at applying a fix you already understand. It is poor at deciding which fix is correct in the first place.
Three steps in this order. First, rotate the key in the provider's dashboard (OpenAI, Stripe, Twilio, AWS, whatever). The old key is now dead. Second, search your GitHub repo history (not just the current commit) for the leaked value, using GitGuardian or git-secrets. If it shipped to a public repo, it is in scraper databases now and rotating is not enough; you need to delete the history with git filter-repo or BFG and force-push. Third, audit your billing in the provider's dashboard for the past 30 days, not just today. Some attackers throttle their abuse to avoid detection. If you find unusual usage, the provider will often refund it if you contact support quickly.
Row Level Security (RLS) is a Postgres feature that restricts which rows a logged-in user can read or modify, enforced at the database level rather than in the application code. Supabase relies on RLS as its primary authorization model: if RLS is off, every authenticated user can read every row in every table the API exposes. AI tools regularly generate Supabase apps with RLS disabled, or with RLS enabled but no policies (which silently breaks reads, prompting the developer to disable it again). This is the single most common production bug in the entire vibe-coded ecosystem. Every Supabase table in a production app should have RLS enabled and explicit, tested policies.
No, but the migration path varies. Lovable, Bolt, and Replit all support exporting code to GitHub on their paid tiers. Once exported, you have a normal Next.js or React project that can run locally, deploy to Vercel, and accept any modifications a developer wants to make. The harder part is usually the database: Supabase data is portable to a self-hosted Postgres or another Supabase project; Replit databases require a one-time export. The platform stops being load-bearing the moment your code is on GitHub, which is why we recommend exporting early as a hedge against platform lock-in even if you plan to keep using the AI builder for new features.
You need three to five end-to-end tests covering the revenue-generating flows. That is it. We are not asking you to hit 80 percent unit test coverage; that is the wrong tradeoff for a small team. The point of those few tests is that you can refactor without fear. Without them, every change to the auth helper or the database query layer carries the risk of silently breaking checkout. Founders consistently say "my app works" right up until the day they ship a change that breaks it for paying customers. The tests are insurance against that exact day.
It depends, and any answer that does not start with 'it depends' is selling you something. The right stack follows what the app actually needs and who maintains it. A transactional SaaS with multi-tenant data has very different requirements from a content-heavy marketing site that a non-engineer needs to edit, and from a rich brand site that lives or dies on animation and design quality. Common ingredients worth considering for AI-built rescues include a modern framework for the application layer (Next.js or Astro are both reasonable), a database with proper authorization controls, a managed deploy host, and observability. For some products, Webflow plus a thin custom backend is the right answer. For others, a fully custom stack is. The dangerous answer is locking in a stack because someone else likes it. Pick what serves the product.
Run through the four-criterion test. Is the database schema modeling the domain correctly, with sane primary keys and a real concept of tenancy? Can authorization be added in under two weeks of focused work? Is the code under 20,000 lines and mostly comprehensible to a senior engineer reading it cold? Can the existing flows be specified as Playwright tests in under a week? If you can say yes to three of the four, rescue. If you cannot, the rewrite math usually wins. The honest signal that you are past rescue territory is that every fix introduces two new bugs in unrelated parts of the codebase, which is the symptom of a structural problem rescue cannot resolve.
Stuck on conversion?
