Why Your Vibe-Coded SaaS Will Break in Production

You built something with Claude Code, Cursor, or Copilot. It works. Users are testing it. You shipped faster than you ever thought possible. Congratulations — you just solved the easy problem.

The hard problem is everything your AI tool never told you was missing.

I know because I built a 93,000-line SaaS using Claude Code over 8 months. It worked from month one. It wasn't production-ready until month seven. The gap between those two milestones nearly broke the project.

The six things AI tools won't suggest

AI coding assistants are extraordinary at generating code that does what you ask. They are terrible at generating code that handles what you didn't ask about. Here's what they consistently miss:

1. Your authentication is a liability

Ask any AI tool to add authentication. Nine times out of ten, it'll store JWT tokens in localStorage. This is a textbook XSS vulnerability. Any JavaScript running on your page — including that analytics script you embedded — can read the token and impersonate the user.

What production requires: httpOnly cookies that JavaScript can't access. CSRF protection on every state-changing request. Rate limiting on login endpoints. Token rotation on sensitive operations.

No AI tool will spontaneously suggest any of this. You have to know to ask.

2. You have zero migration files

When you change your database schema during development, you probably just modify the model and restart. It works locally. But when you need to deploy to a second server, or roll back a bad release, or onboard another developer, there is no way to recreate your database state.

What production requires: A migration file for every schema change, from day one. A rollback path for every migration. Version-controlled database state that any server can reproduce.

3. Multi-tenancy is an afterthought

If your SaaS serves multiple customers, their data needs to be isolated. Not "mostly isolated." Completely isolated. One bad query filter and Customer A sees Customer B's data. This isn't a bug — it's a lawsuit.

What production requires: Tenant-aware middleware on every route. Database queries that always filter by tenant ID. Automated tests that verify cross-tenant data can't leak.

4. Your webhooks will lose payments

Stripe, MercadoPago, PayPal — they all send webhooks for payment events. They also retry webhooks if your server doesn't respond fast enough. Without idempotency keys, a retried webhook means you process the same payment twice. Your customer gets charged twice. Or worse — your webhook handler crashes and the payment is processed by Stripe but never recorded in your system.

What production requires: Idempotent webhook handlers using the transaction ID. Webhook signature verification. A dead-letter queue for failed events. Reconciliation scripts that catch discrepancies.

5. There's no disaster recovery plan

What happens if your server dies at 2 AM? If your database corrupts? If you push a bad deploy? For most vibe-coded projects, the answer is "I don't know." That's not an answer your paying customers will accept.

What production requires: Automated backups with tested restore procedures. A deployment rollback path. Health checks and uptime monitoring. An incident response runbook — even if the "team" is just you.

6. You're probably not compliant

If you serve users in Europe (GDPR), Mexico (LFPDPPP), or California (CCPA), you have legal obligations around data collection, storage, and deletion. If you process payments, PCI DSS applies. If you don't have a privacy policy, terms of service, and a documented data handling process, you're exposed.

What production requires: A privacy policy that matches your actual data practices. Terms of service with limitation of liability. A data deletion workflow (users have the legal right to request this). Documentation of what data you collect and where it's stored.

The checklist AI never generates

Here's the uncomfortable truth: AI tools are brilliant at answering questions. They never tell you which questions you should be asking.

No AI will spontaneously suggest that you need CSRF protection, database encryption at rest, ARCO rights compliance for Mexican users, or a disaster recovery runbook. These aren't features. They're the invisible foundation that separates "it works" from "it works and doesn't get you sued, hacked, or bankrupted."

AI tools are force multipliers, not architecture substitutes. The developer who knows what to ask for will always outbuild the one who accepts whatever the AI suggests.

What to do about it

You don't need to throw away what you've built. You need to audit it. Systematically check for the gaps listed above — and the dozens of others that surface in real production environments.

Start with these three steps:

1. Run a security audit — check authentication, authorization, input validation, and every place user data enters your system
2. Create your first migration file — document your current schema, then write every future change as a migration
3. Write one runbook — "what happens if the server crashes at 2 AM?" Document the recovery steps before you need them

These three actions alone will put you ahead of 90% of vibe-coded projects.