Vibe Code Rescue Case Study: Rebuilding an AI-Generated SaaS MVP in Rails 8

TL;DR

A YC-backed B2B SaaS shipped its MVP using AI tools that generated a Vercel + Firebase codebase. The UI looked done. The product wasn't. There was no real authentication. No payment processing. No onboarding flow. No data integrity. The "Stripe integration" was a button. The "user accounts" were unguarded Firebase reads. Customers couldn't actually pay them, and the early ones who tried hit dead ends fast.

We rebuilt the product on Rails 8 + Hotwire + SQLite in 6 weeks for a fixed price of $40K, replacing an agency quote of $150K and 4 to 6 months. Real Stripe billing shipped in week 2. Auth, onboarding, and data integrity shipped by week 4. The founder closed their first paying customers in week 5. Production has been stable since launch — zero customer-facing incidents in the 90+ days since.

This is a case study about one engagement, but the pattern is true of every vibe-coded MVP I've seen at month four. If you've shipped on AI-generated code and you're hitting walls, the diagnosis below probably matches what's on your screen right now.

The State We Inherited

The founder is technical-adjacent — knows enough to ship, not enough to know what's missing. They built the MVP using AI tools that generated a Vercel + Firebase project. The dashboard rendered. The marketing site looked sharp. The login button worked, in the sense that clicking it changed what was on the screen.

Underneath, here's what we found on day one:

• No real authentication. The "logged in" state was a client-side flag. Firebase rules were either wide-open or had been copy-pasted from a tutorial without anyone understanding what they did. Any user could read or write any other user's data by changing a parameter in a request. This wasn't an obscure security flaw — it was the architecture.
• No payment processing. The pricing page had three tiers, three "Start Free Trial" buttons, and a fully designed checkout UI. None of it talked to Stripe. The buttons logged events and routed users to a "Thanks!" page. Customers who tried to pay couldn't.
• No onboarding flow. Successful new accounts had no path from signup to first value. The empty-state screens existed in Figma. They didn't exist in the app.
• No data integrity. The Firebase schema had no validation, no required fields, and no relationships. Records existed in inconsistent states because the AI-generated frontend was the only thing enforcing structure — and it didn't, consistently.
• No deploy story. "Production" was a Vercel preview that the team had agreed to call production. There was no rollback path, no staging environment, and no way to test changes before they hit users.
• No observability. When something broke, the team found out from customer emails. There were no error logs, no monitoring, and no analytics that actually fired correctly.

On the kickoff call I asked the founder to walk me through their Stripe integration. They opened the pricing page and clicked "Start Free Trial." A modal popped up — three input fields, a submit button, the words "Stripe Powered" in light gray at the bottom of the modal. They submitted the form. A green check animated. The page redirected to a "Welcome!" screen. I asked, "And then Stripe charges them?" The founder paused. "Well, no. We follow up by email. Eventually." That was the integration.

None of this is unusual. This is what every vibe-coded MVP looks like at month four. AI tools ship the parts of a product that are easy to demo. They skip or stub the parts that actually keep a business running. Founders don't realize what's missing until the first real customer tries to give them money.

Why the AI Codebase Couldn't Be Patched

The first thing every founder asks is some version of: "Can we just fix what's there?" Sometimes the answer is yes. In this case it was no. Three reasons:

1. The architecture wasn't designed — it was assembled. The AI generated each feature in isolation, optimizing for whatever was on the screen at that moment. The result was a codebase with no shared abstractions, no consistent error handling, and no cohesive data model. Every feature was its own little island, often with its own little Firebase calls duplicating logic that should have lived in one place. Patching means rewriting the patches, then rewriting them again next month when the next thing breaks.

2. The missing pieces aren't optional. Authentication isn't a feature you add later — it's the substrate everything else sits on. Same for payments, onboarding, and data integrity. Bolting these onto a codebase that wasn't designed with them in mind is more work than rebuilding around them from the start. The seams show forever.

3. The stack was wrong for the team. Vercel + Firebase scales in some ways and absolutely doesn't in others. For a small team without dedicated DevOps, it generates ongoing operational complexity that the team can't actually pay down. Every change risks breaking something. The team starts shipping less, not more.

I lay out this same pattern in my breakdown of vibe coding — AI-generated code optimizes for the appearance of progress. Real progress requires the boring parts.

What We Rebuilt and Why Rails 8

The rescue stack was Ruby on Rails 8 with Hotwire (Turbo + Stimulus) on the frontend, SQLite in production, Solid Queue for background jobs, and Litestream for continuous backups to S3. Total monthly hosting cost after the rebuild: under $25.

Why this stack for a YC-backed SaaS? Three reasons that show up in every rescue:

Rails is designed for the team that exists. The team is one technical founder and one part-time contractor. Rails 8 ships authentication, background jobs, caching, and websockets out of the box — no Redis, no separate workers, no microservices to operate. This isn't 2015 best practices. SQLite in production with Rails 8 is genuinely production-ready for any product without specific multi-region requirements, and the operational simplicity is the whole point.

Hotwire eliminates frontend ceremony. The original codebase had React components calling Firebase calling cloud functions calling Stripe webhooks. Each layer was a place to break. Hotwire collapses most of this into server-rendered HTML with Turbo Streams for the interactive bits — the frontend gets simpler without losing any of the UX polish.

The stack matches the product's actual constraints. A B2B SaaS for hundreds of business customers doesn't need the architecture of a consumer app for millions. Right-sizing the stack to the actual problem freed the team to ship features instead of operate infrastructure.

If you're earlier in the process and trying to figure out what to ship in the first place, my MVP development guide covers how to scope this from scratch — same principles, applied earlier.

The Rebuild Sequence (What Got Done in What Order)

Six weeks. Fixed scope. Here's how it sequenced:

• Week 1: Migrated the data model from Firebase to a real relational schema. Stood up Rails 8 with authentication using the built-in generator. Got the team's existing customer list (around 80 records) into the new database with all the cleanup that required.
• Week 2: Real Stripe integration with subscription management, webhooks, and a working customer billing portal. Onboarding flow from signup to first value (the screens that previously only existed in Figma). At this point a customer could sign up and pay, which is something the previous codebase had never been able to do.
• Week 3: Core product features rebuilt as Hotwire-driven flows. UX kept faithful to the original design system, just running on a stack that actually works. Email transactional flows on Amazon SES.
• Week 4: Admin tooling for the founder to manage customers, see usage, handle support. Observability: error tracking, logs, dashboards. Production deploy on Railway with Litestream backups to S3. The team got a real staging environment for the first time.
• Week 5: Polish, edge cases, and migration of the remaining customers from the old system. Founder ran their first paid customer onboarding through the new system end-to-end.
• Week 6: Knowledge transfer, documentation, and handoff. The founder and their part-time contractor took over day-to-day. We stayed available for a 30-day support window for anything that came up.

Outcomes

What it cost the founder, in time and dollars and stability and revenue:

Time saved: 6 weeks of focused rebuild vs. the 4 to 6 months the agency had quoted. The faster timeline mattered because the runway clock doesn't pause for a rebuild.

Cost avoided: Fixed price of $40K vs. the $150K agency quote — and vs. the indeterminate cost of trying to keep patching the existing codebase, which would have eaten contractor hours indefinitely. Net savings around $110K for the founder, plus the ongoing operational cost reduction from a simpler stack.

Production stability: Zero customer-facing incidents in the 90+ days since launch. The previous codebase had been generating customer support requests at a rate the founder was personally trying to keep up with. That stopped.

Revenue unblocked: First paying customers closed in week 5. The previous setup had quite literally been incapable of taking money — every "purchase" had been a manual workaround. Once Stripe shipped in week 2, the team's pipeline started converting, and the founder went from operating a demo to running an actual business.

The Pattern (Why This Story Repeats)

Here's the thing every founder I talk to needs to hear: the codebase you're describing is not unusual. The exact same pattern shows up across Lovable, Cursor, Replit Agent, v0, Bolt, and the AI assistants that target Vercel + Firebase or Next.js + Supabase. The tools differ; the failure modes are the same.

What every vibe-coded MVP shares at month four:

1. UI that's 80% complete and 20% theater. The screens look ready. Some of them aren't actually wired to anything.
2. Auth that isn't. Either fully missing, fully open, or implemented in a way that doesn't survive a real attacker (which is to say, any attacker).
3. Payments that don't. Stripe integration that's UI-only, or wired up in a way that breaks on the second customer who tries to use it.
4. Data with no contract. No schema validation, inconsistent records, no foreign key relationships, garbage piling up faster than the team can clean it.
5. Operational debt. No observability, no rollback path, no staging, no backup story. Every deploy is a coin flip.

This isn't a critique of AI tools — they're remarkable for what they do. The mistake is assuming the tool produced a product when what it produced was a working-looking shell. The shell is real progress. It's just not the whole job.

If you want a deeper read on which AI tools handle which parts of this gracefully, my Claude Code vs Cursor breakdown walks through the differences in how they generate (or don't generate) the foundational systems.

How to Tell If Your Codebase Needs a Rescue

Some quick diagnostic questions. If three or more of these are "no" or "I don't know," your codebase probably needs a rescue:

• Can a real attacker steal another user's data? (You should know the answer cold.)
• Can a customer pay you without a manual intervention from someone on your team?
• Does your data model enforce its own consistency, or are you relying on the frontend to keep it clean?
• If today's deploy breaks something, can you roll back in under five minutes?
• When customers report bugs, do you find out from your own monitoring before they tell you?
• Can a new engineer onboard to your codebase in a week, or does the system rely on tribal knowledge?
• Is your stack one that one or two people can operate indefinitely, or does it implicitly assume a DevOps team you don't have?

"Don't know" counts as no. The questions you can't answer cold are the ones already costing you something.

The Vibe Code Rescue Offer

If this case study sounds like your codebase: I do this work as a fixed-price engagement. $25K to $50K, 4 to 8 weeks, audit-first, fully scoped before you sign anything.

The audit is free. I take 20 minutes with your repo, send back a Loom walkthrough flagging the three biggest production risks, and we decide together whether the rescue is the right move. If it isn't, you keep the audit and the next steps anyway.

Compared to the alternatives: a typical agency rebuild quote runs $120K to $200K and 4 to 6 months. Hiring a full-time senior engineer runs $200K+ all-in for the first year and assumes you can find one in this market. A rescue is faster and cheaper than either, and it's scoped against a fixed deliverable instead of an open-ended retainer.

Book a free 30-minute call and we'll decide on the call whether your codebase is a fit for the rescue, the rebuild, or something else entirely. No deck, no pitch, just an honest read on what you've shipped and what it'll take to get to a real product.

Further Reading

• What Is Vibe Coding? — the broader category and why this pattern keeps repeating
• Is Vibe Coding Bad? — the honest case for and against
• Claude Code vs Cursor — how the tools generating these MVPs actually differ
• MVP Development Guide — how to scope this correctly from scratch
• Fractional CTO Cost — pricing comparison for outside engineering help