How to Vibe-Code a SaaS with Claude Code (Step-by-Step Guide)

"Vibe coding" — describing what you want and letting an AI agent write the code — has gone from meme to mainstream. Claude Code is one of the best agents for it: it plans well, handles multi-file changes, and follows repository conventions when you give it some. But most vibe-coded SaaS projects still die in the same place: the agent produces a beautiful demo with broken auth, no billing, and no path to production.

This guide is the workflow we use and recommend to actually ship. The core idea: let the agent build your product, not your infrastructure.

Step 1: Start from a foundation, not a blank repo

Claude Code is exceptional at product features and unreliable at cross-cutting infrastructure — authentication flows, webhook reliability, multi-tenant data isolation. Those aren't "figure it out later" problems; mistakes there are security bugs and billing incidents.

Start from a foundation where that layer already exists and is tested. That can be a starter kit like supastarter (auth, payments, organizations, emails, and admin panel included, with an AGENTS.md already written) or your own equivalent. What matters is that the agent's job becomes "add my product on top of documented patterns" rather than "invent a SaaS architecture".

Step 2: Give Claude Code repository instructions

Claude Code reads project instruction files (AGENTS.md / CLAUDE.md) at the start of a session. This is the highest-leverage 30 minutes in the whole workflow. Your instructions should cover:

• Structure — where app code, shared packages, and content live
• Conventions — TypeScript everywhere, component patterns, naming
• Commands — install, dev, lint, test
• Guardrails — "keep changes small and scoped", "run lint before finishing", "don't touch .env files"

If you use supastarter, this file ships in the box — see what a good AGENTS.md looks like. Either way, keep it to one focused page: agents follow short, specific instructions far more reliably than long handbooks.

Step 3: Load the right context

Two practices make a big difference:

1. Docs as Markdown. If your foundation has documentation, get it into the agent's context in plain Markdown. supastarter serves every docs page as Markdown (append .md to the URL) and offers full docs downloads, precisely for this.
2. Point at examples, not descriptions. Instead of describing how your API layer works, tell Claude: "look at how the existing posts feature defines its schema, endpoints, and page, then follow that pattern". Existing code is the most reliable spec.

Step 4: Prompt in feature-sized chunks

The failure mode of vibe coding is the mega-prompt ("build me a CRM"). The success mode is feature-sized instructions with acceptance criteria:

"Read AGENTS.md. Add a 'projects' feature: a Drizzle schema (projects belong to an organization), CRUD API endpoints following the existing oRPC patterns, and a dashboard page listing the current organization's projects using the existing table components. Run pnpm lint when done."

Rules of thumb:

• One feature per session. Fresh context beats a long thread with stale assumptions.
• Name the patterns to follow. Reference specific files or features.
• State the verification step. Tell it what to run; Claude Code will actually run it.
• Review diffs, not vibes. You don't need to write the code, but read what changed — especially anything touching auth, billing, or data access.

Step 5: Use guardrails to catch what you can't review

Even careful prompting produces occasional nonsense. Three mechanical guardrails catch most of it:

1. TypeScript strictness — a typed API layer and typed database queries turn many agent mistakes into compile errors instead of runtime surprises.
2. Linting — enforces the conventions your instructions describe.
3. End-to-end tests — a small Playwright suite over signup, login, and checkout catches the regressions that matter most. Have Claude write a test alongside each feature; it's good at this.

This is also the honest answer to "can non-developers vibe-code a SaaS?" — yes, much further than skeptics think, if the guardrails are set up. They're what replaces the experienced eye.

Step 6: Ship, then keep the loop going

Deploy early (Vercel or Docker both work fine for this workflow) and keep iterating in the same pattern: feature-sized prompt → agent implements → guardrails verify → you review → merge. Treat AGENTS.md as living documentation — when the agent repeatedly gets something wrong, add a line to the instructions rather than correcting it in every prompt.

The realistic summary

Agent's job	Your job
Product features, UI, refactors, tests	Product decisions and priorities
Following documented patterns	Providing the patterns (foundation + AGENTS.md)
Running lint and tests	Reviewing diffs on auth/billing/data access
Speed	Judgment

Claude Code plus a production-ready foundation is genuinely fast — features that took days take hours, and most users of this workflow have a working deployed app in the first session. The teams that fail are the ones that ask the agent to be an infrastructure engineer. Don't. Give it a solid base and let it do what it's great at.