Claude Code best practices for building a SaaS

The Claude Code best practices that matter most for a SaaS come down to five habits: start from a codebase that already works, write the rules down in CLAUDE.md, plan before Claude edits, give it checks it can run after every step, and review every diff yourself, especially anything touching sign-in, billing or the database.

This guide turns those habits into a workflow. It was checked against Anthropic's own best practices for Claude Code in October 2026, and it adds the parts a multi-tenant SaaS needs on top: permissions, secrets, MCP servers and database changes.

What is a vibe-coded app?

A vibe-coded app is one built mostly by describing what you want to an AI coding agent in plain language and accepting the code it writes, often without reading every line. It is a fast way to get a working prototype.

The trouble starts when the prototype gets real users. A SaaS stores other people's data, takes their money, and has to keep one customer's records away from another's. Those are exactly the places where code that looks finished can be quietly wrong. You don't have to stop describing features in plain language to ship one. You have to add structure around it, so the agent proves its work instead of asserting it.

How do you use Claude Code to build an app?

Build in short loops, one feature at a time: describe the feature, let Claude explore and plan, approve the plan, let it implement and run your checks, then review the diff and commit. Start a fresh session for the next unrelated task.

1. Start from a base that works, with sign-in, accounts and tests already in place.
2. Write the project's rules in CLAUDE.md (or AGENTS.md with a one-line CLAUDE.md pointing to it).
3. For a larger feature, write a spec first. Have Claude interview you, then save the answers to a file.
4. Plan in plan mode. Claude reads code and proposes changes without editing anything.
5. Implement with checks. Claude runs type checks, lint and tests and fixes failures before it stops.
6. Review and commit. Read the diff, ask for a second review on risky changes, commit.
7. Clear the context with /clear and start the next feature.

Claude Code best practices, step by step

Start from a base that already works

An agent is far better at adding a feature to a working codebase than at inventing the foundation. Sign-in, team accounts, billing webhooks and row-level security are where a from-scratch build goes wrong in ways nobody sees until production. Whatever base you pick, make sure it has tests you can run, because those become Claude's checks.

Write the rules down in CLAUDE.md

CLAUDE.md loads at the start of every session. Put in the commands Claude can't guess, conventions that differ from the defaults, the boundaries it must not cross, and what "done" means. Run /init for a first draft, then edit it.

Keep it short. Anthropic's test for each line is whether removing it would cause Claude to make mistakes, and its docs warn that a bloated file makes Claude ignore the instructions that matter. Multi-step procedures belong in skills instead. If your team uses other agents too, keep the rules in AGENTS.md and make CLAUDE.md the single line @AGENTS.md. The full walk-through, with a template, is in CLAUDE.md: what to put in it, and the shared file is covered in the AGENTS.md guide. Still choosing an agent? See Codex vs Claude Code.

Plan before Claude edits

Anthropic's recommended workflow has four phases: explore, plan, implement, commit. Press Shift+Tab until the status bar shows ⏸ plan mode on, or start with claude --permission-mode plan. In plan mode Claude reads files and answers questions without changing anything. Press Ctrl+G to open its plan in your editor and change it before you approve.

Planning is worth it when the change spans several files or you are unsure of the approach. If you could describe the diff in one sentence, skip it.

For a bigger feature, let Claude interview you first. The docs suggest a prompt like this:

I want to build team invitations. Interview me in detail using the AskUserQuestion tool.
Ask about technical implementation, UI/UX, edge cases, concerns and tradeoffs.
Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.

Then start a fresh session to build from SPEC.md, so the implementation gets a clean context and you have the spec to check against.

Give Claude checks it can run

This is Anthropic's first tip, and the one that matters most. Claude stops when the work looks done. Without a check it can run, "looks done" is the only signal, and you become the person who catches every mistake. With a test suite, a type check or a build that passes or fails, Claude does the work, runs the check, reads the result and keeps going until it passes.

For a SaaS, the useful checks are:

• type check and lint
• unit tests for business logic, such as pricing and permissions
• end-to-end tests for sign-up, checkout and invitations
• database tests that sign in as one customer and try to read another's data

List them in CLAUDE.md as the definition of done, and ask for evidence rather than a claim:

Add the invoices table and its server actions. Then run pnpm typecheck, pnpm lint and the
database tests. Show me the commands you ran and their output. Don't say you're done
until they pass.

To make a check impossible to skip, a Stop hook can run it as a script and block Claude from finishing until it passes.

Keep each session to one task

Claude's context window holds every message, every file it read and every command's output, and Anthropic's docs say performance degrades as it fills.

• Run /clear between unrelated tasks.
• If you have corrected Claude twice on the same thing, /clear and write a better first prompt with what you learned.
• Ask Claude to "use subagents to investigate" a broad question. Subagents read files in their own context window and send back a summary.
• Press Esc to stop Claude mid-action. Press Esc twice, or run /rewind, to restore earlier code and conversation from a checkpoint.

Checkpoints only track edits made through Claude's file tools, not changes made by shell commands, so they don't replace git. Commit after each working step.

Set permissions you will actually read

As of October 2026, Claude Code starts terminal and VS Code sessions in auto mode (v2.1.283 and later). In auto mode a separate classifier model reviews most actions instead of you and blocks the ones that look risky. Manual mode asks you before file edits, shell commands and MCP tool calls. Anthropic's own advice is to switch to Manual when you want to approve each step yourself.

A sensible setup for a SaaS repository:

• Use plan mode or Manual mode for changes to sign-in, billing and the database schema.
• Pre-approve the commands you run all the time with /permissions, so prompts stay rare enough to read.
• Turn on the sandbox with /sandbox to limit what shell commands can reach on disk and on the network.
• Keep bypassPermissions for a container or VM you can throw away, which is where Anthropic's docs reserve it.

Rules can live in .claude/settings.json and be committed with the project:

{
  "permissions": {
    "allow": ["Bash(pnpm typecheck)", "Bash(pnpm lint)", "Bash(pnpm test *)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

Deny rules apply in every mode, including bypassPermissions.

Keep secrets out of the chat and the repository

The deny lines above stop Claude's file tools from reading your .env files. They also block recognised read commands such as cat on those paths. They don't cover every subprocess, so for a boundary enforced by the operating system, use the sandbox as well.

The rest is habit. Don't paste API keys into the chat. Keep keys that bypass your database security, like Supabase's service-role key, in server-only code. Set production values in your host's environment settings, never in a committed file. A committed .mcp.json can reference environment variables as ${VAR}, so the file itself holds no secret.

Add skills, subagents and MCP servers on purpose

Each one solves a different problem:

Set disable-model-invocation: true on a skill that has side effects, such as a deploy, so it runs only when you type its name. Agent skills explained covers the format.

For MCP servers, Anthropic's docs say to verify you trust each server first, because servers that fetch outside content can expose you to prompt injection. A database server deserves the most care. How to connect the Supabase MCP server to Claude Code walks through a read-only setup scoped to one development project. Where a service has a good CLI, such as gh for GitHub, the docs note that a CLI is the most context-efficient way for Claude to use it.

Review every diff, ideally in a fresh context

A reviewer that didn't write the code isn't biased towards it. Claude Code's bundled /code-review skill reviews the current diff for bugs in a fresh subagent. You can also run a second session as the reviewer and paste its findings back to the first.

Anthropic adds a warning: a reviewer asked to find gaps will usually find some, even in sound work. Tell it to flag only problems that affect correctness or the requirements.

Then read the diff yourself, at least for policies, payment code and anything that decides who can see what.

Change the database only through migrations and tests

In a multi-tenant SaaS, the database is where a mistake leaks one customer's data to another. Four rules keep that from happening:

1. Every schema change is a migration file in the repository, never a quick edit in the dashboard or a query run against production.
2. A migration that creates a table also turns on row-level security and adds its policies.
3. Every new table gets a test that signs in as a user from another account and fails to read or change its rows. With Supabase that is a pgTAP test run by supabase test db.
4. Claude applies the migration to a local database with supabase db reset, runs the tests, and you read the policies before anything ships.

Supabase RLS explained shows what those policies and tests look like.

How do you vibe code an app with Claude?

Keep the plain-language prompts, and add four things around them: a written spec, plan mode, one feature per session, and checks Claude must pass before it says it is done. A typical feature takes three prompts in two sessions:

Session 1: Interview me about team invitations with AskUserQuestion, then write SPEC.md.

Session 2: Read SPEC.md. In plan mode, list the migration, policies, server actions and tests.

Session 2: Implement the plan. Run the type check, lint and database tests, show me the
output, and explain each change in plain words.

You still decide what the product does and read what touches sign-in and payments. Claude writes the code and proves it works.

A starting point set up for this

shipanysaas is a SaaS starter kit that comes with most of this already in place. It has no AI features of its own: everything here is for the agent you build with.

• Rules every agent reads. A root AGENTS.md plus nested ones per app and package, and a CLAUDE.md that imports it.
• Required checks. The root AGENTS.md makes the agent run pnpm typecheck, pnpm lint:fix, pnpm format:fix and an adversarial /reviewer pass, plus /rls-review after any database change, which proves tenant isolation with pgTAP tests.
• Ready-made skills. Up to 49 agent skills (42 in Starter), in .claude/skills/ for Claude Code and .agents/skills/ for Codex. See Agent skills.
• MCP servers in .mcp.json. The kit's own server, next-devtools and ui-skills. Claude Code asks you to approve them the first time.
• Written fixes. 17 in All-in (6 in Starter), for setup errors already met while running the kit. Agents are told to check them before debugging.

Building on the kit with a coding agent walks through one feature built this way. Coding agents lists every file, and pricing shows what each plan includes.

FAQ

What is the single most important Claude Code best practice?

Give Claude a way to check its own work: a test, a type check or a build that passes or fails. Anthropic calls it the difference between a session you watch and one you can walk away from.

Should I use auto mode?

Auto mode is fine for routine work in a repository you can restore from git. For changes to sign-in, billing or the database schema, switch to plan mode or Manual mode and approve each step. Never use bypassPermissions outside a throwaway container or VM.

Can Claude Code build a whole SaaS on its own?

It can write most of the code. You still choose what to build, decide who may see and change what, sign up for the services and paste in their keys, and review the changes that touch customer data and money before real customers arrive.