Case Study

How I Built a Production SaaS in 8 Months with AI

Rogelio LopezMar 202612 min read

In mid-2025, I started building an AI-powered SaaS platform for Mexican restaurants. I had no computer science degree. I'd never worked at a tech company. My primary coding tool was Claude Code at $100/month.

Eight months later, the project was 93,000 lines of production code. It processes real payments through Stripe and MercadoPago. It handles WhatsApp ordering through AI. It serves multiple restaurant businesses as paying tenants.

This is the full story — what worked, what nearly killed the project, and what I'd do differently if I started over today.

The timeline

Month 1
5,000 lines. Basic prototype. Express backend, simple frontend. WhatsApp integration working. Everything in 3 files. No auth, no database migrations, no error handling. It "worked."
Month 2-3
18,000 lines. Added AI-powered menu parsing, order processing, multi-restaurant support. Files started growing past 1,000 lines. Still no migrations. Auth was storing JWT in localStorage. I didn't know this was a problem.
Month 4
35,000 lines. First paying customer. Panic. Realized I had no backup system, no monitoring, no way to recover from a crash. Spent two weeks adding the basics. Started the CLAUDE.md file that changed everything.
Month 5-6
58,000 lines. The Great Refactor. Moved auth to httpOnly cookies. Wrote 47 migration files retroactively. Split the 4,000-line God files. Added rate limiting, CSRF protection, input sanitization. Two months of fixing what should have been built right from the start.
Month 7
78,000 lines. Added payment processing (Stripe + MercadoPago), multi-tenancy, admin dashboard. This went fast because the architecture was finally clean. The CLAUDE.md file kept Claude Code generating consistent, pattern-following code.
Month 8
93,000 lines. Production deployment. Docker, Nginx, PM2, CI/CD pipeline, SSL, automated backups, monitoring, health checks. Legal pages (privacy policy, terms of service) for Mexican compliance. The system was real.

What worked

Claude Code as the primary development tool

I wrote maybe 10% of the code by hand. Claude Code wrote the rest. But — and this is critical — I directed every line of it. I described the architecture. I specified the patterns. I reviewed the output. Claude Code was the hands; I was the brain.

The most important moment was creating the CLAUDE.md file in month 4. Before that, every Claude Code session was a gamble — it might follow yesterday's patterns or invent new ones. After adding persistent project context, the consistency was immediate and dramatic.

The "build fast, audit later" approach

Controversial take: building fast with AI and auditing later is a valid strategy — as long as "later" actually happens. The first 3 months of rapid building gave me a working product and a paying customer. That momentum and validation mattered more than architectural perfection.

The key is that the audit must happen. For many vibe coders, "later" never comes. The technical debt accumulates until the project collapses under its own weight.

Copilot for the small stuff

GitHub Copilot running alongside Claude Code was the perfect combination. Copilot handled autocomplete — finishing lines, suggesting variable names, generating boilerplate. Claude Code handled the big decisions. I never had to context-switch between tools because they operated at different levels.

What didn't work

Trusting AI-generated security code

This is my biggest regret. Claude Code generated an authentication system in month 1. It worked. Users could sign up, log in, access their accounts. I didn't review the security implementation because it looked professional.

Two months later, during a self-audit, I discovered: tokens in localStorage (XSS vulnerability), no CSRF protection (cross-site request forgery), no rate limiting on login (brute force attacks), no token rotation (session hijacking). Every single one of these is a well-known security vulnerability. The AI generated none of the protections.

AI tools generate code that works. "Works" and "secure" are completely different standards. Never ship AI-generated security code without a manual review.

No migrations from day one

Every time I changed the database schema, I modified it directly. No migration file. No rollback path. By month 5, when I needed to set up a staging environment, I couldn't recreate the database. I spent two weeks reverse-engineering 47 migration files from the production schema.

If I'd written each migration as I made changes, it would have been 15 minutes per change — maybe 6 hours total spread across 5 months. Instead, I burned two consecutive weeks on it.

The God File anti-pattern

When you're vibe coding and things are flowing, you keep adding to the same file. Claude Code doesn't complain. Your app keeps running. Then the file hits 2,000 lines. Then 3,000. Then 4,000.

At 4,000 lines, Claude Code can't hold the entire file in context. It starts generating code that contradicts what's at the top of the file. Functions that duplicate existing ones. Error handling patterns that don't match. Variable naming that shifts mid-file.

My rule now: 500 lines max per file. When a file approaches 500, split it before adding anything new. This is non-negotiable.

Not reading the code carefully enough

AI-generated code has a dangerous quality: it looks right. Clean variable names. Logical structure. Proper formatting. Your eyes glaze over because everything appears professional. But there are subtle bugs hiding — off-by-one errors in pagination, race conditions in async operations, SQL patterns that look safe but aren't.

The technique that saved me: "Explain this code back to me." Before committing anything important, I ask Claude Code to explain every line, including potential failure modes. If the explanation reveals something I didn't expect — that's either a bug or code I don't understand well enough to maintain. Either way, it needs attention.

What I'd do differently

If I started over today with everything I know:

  1. CLAUDE.md file before writing a single line of code — define architecture, conventions, security rules, and file size limits from the start
  2. Migration files from the first schema change — never modify the database directly
  3. Security middleware before the first feature — auth, CSRF, rate limiting, input sanitization as the foundation layer
  4. 500-line file limit enforced from day one — split early, split often
  5. Monthly audit against a production checklist — don't wait 8 months to discover what's missing

I genuinely believe this would have cut the timeline from 8 months to 3. Not because AI tools would be faster — because I'd skip the 5 months of discovering and fixing problems that should never have existed.

The numbers

The takeaway

AI tools made it possible for a solo developer with no CS degree to build a 93K-line production SaaS in 8 months. That's remarkable. It's a genuinely new capability that didn't exist two years ago.

But AI tools also made it easy to build 93K lines of code with serious architectural, security, and operational gaps — because they generate whatever you ask for and never tell you what you didn't ask about.

The developers who learn to direct AI tools with architectural intent will outbuild everyone. Not because they write more code. Because they write the right code.

That's the gap this retrospective — and the full course — exists to close.

The complete architecture guide

Everything I learned in 8 months, structured into 14 modules with exercises, case study material, and a production-ready SaaS starter template. From vibe code to production SaaS.

View the Course →