Building a SaaS with Claude Code: what works and what breaks in production

Claude Code lets a founder ship a first SaaS from the terminal in a matter of weeks: screens, a database, user accounts, checkout. That is a real shift, and pretending otherwise would be dishonest. What has not shifted is the gap between an app that runs and a SaaS you can sell: tenant isolation, billing that controls access, security, tests that guard every change, and hosting someone actually operates. Claude Code can write all of that. It does not decide what needs writing, and it does not get paged when things break.

This guide is about Claude Code specifically: its pricing, how it works and where it fits. For the wider picture across AI app builders and coding assistants, read building a SaaS with AI.

Claude Code in two sentences

Claude Code is Anthropic's coding agent: it reads your repository, edits files, runs commands and opens pull requests. According to its official documentation, it runs in the terminal, in VS Code and JetBrains IDEs, in a desktop app and in the browser.

Three mechanisms matter for a SaaS project:

• CLAUDE.md, a file at the root of your repository that Claude Code reads at the start of every session. It holds your rules: architecture, conventions, things that must never happen. The more precise it is, the more consistent the code stays from week to week.
• Permissions. The Claude Code security page explains that manual mode starts read-only and asks before editing files or running commands. It also states plainly that reviewing proposed code and commands is the user's responsibility.
• Git. The code lives in your repository, under your account, and every change can go through a reviewed pull request. That is the key difference from a hosted app builder: you own the workbench from day one.

What Claude Code costs, as checked on 6 November 2026

These prices come from Anthropic's pricing page, checked on 6 November 2026, in US dollars. They change often, so check them before subscribing. Local taxes may apply on top.

Two points most comparisons skip:

• The tool is the smallest line in the budget. Hosting, database, email delivery, monitoring, payments, and above all your review time are where the real cost sits. Our breakdown of the cost to build a SaaS platform covers those lines one by one.
• Different plans, different terms. The Claude Code security page points Team, Enterprise and API users to Anthropic's commercial terms, and Free, Pro, Max and Ultra users to the consumer terms. If your repository will ever hold real customer data (exports, backups, logs), read both and check your privacy settings before you pick a plan. Enterprise buyers will ask about this in their security questionnaires.

What Claude Code does well for a SaaS

• Scaffolding the product. Authentication, data model, list and form screens, an admin dashboard: the repetitive back-office code comes out in hours rather than days.
• Working on existing code. Unlike an app builder that starts from a blank page, Claude Code reads a whole repository, finds a function, explains a module and fixes a bug from a stack trace.
• Writing tests, when asked. Probably its most underrated strength. A test proving that customer A cannot read customer B's invoices takes minutes to generate and protects the product for good.
• Wiring up documented services. Payments, transactional email, file storage: the agent knows the common libraries and reads the docs you point it to.
• The chores. Dependency upgrades, merge conflicts, release notes, a review pass on a branch before it is merged.

Where a SaaS breaks in production

A SaaS serves many customer organisations from one application, on subscription, and you are the accountable publisher. Here is each requirement, what Claude Code produces, and what is still on you.

Multi-tenancy: the invisible rule

The cardinal rule of SaaS is that one customer never sees another customer's data. It does not show on screen, which is exactly why it gets missed. Claude Code will happily write a query that filters by organisation; it will not know, unless you write it down, that an invited accountant should only see two client files, or that a group admin sees three subsidiaries. If you use PostgreSQL through Supabase, its Row Level Security guide asks you to enable RLS on every table in an exposed schema. The architecture options are explained in multi-tenant SaaS architecture, explained for founders.

Billing that drives access

Taking a payment is easy. Running a subscription is not: trials, renewals, expired cards, plan changes, cancellations, sales tax or VAT depending on where the customer is. Stripe says so in its subscription webhooks guide: your app has to react to the events Stripe sends. An agent writes that code; you then test it event by event, including when an event arrives twice or out of order. Tax and invoicing are covered in SaaS subscription billing with Stripe.

Security: plausible is not verified

Generated code is almost always plausible, which makes it risky to skim. The recurring issues: a secret key shipped in client-side code, an API route that checks the user is logged in but not that they may read this record, a dependency added for no good reason. Claude Code offers an on-demand security review of the current branch. It helps; it does not replace a person who knows what to look for.

Tests: what you do not ask for does not exist

An agent tests what you ask it to test. Left alone, it will often check that a page renders, rarely that a revoked user really loses access. Write it into CLAUDE.md: anything touching permissions or billing ships with a test, and those tests run automatically on every change.

Hosting and operations

Launch day changes the nature of the work. You need backups you have already restored at least once, monitoring that alerts you before your customers do, security updates, a staging environment separate from production, and someone who answers when a customer cannot log in on a Monday morning. Claude Code can write the scripts. It does not wake up at night.

A way of working that holds up

1. Write CLAUDE.md before the first line of code. The product in five lines, the stack, the tenancy model, naming rules, the hard no's (no secrets in client code, no query without an organisation filter).
2. Ask for a plan before code. For each feature, have the approach described first, review it, then let it write.
3. Keep pull requests small. One feature, one branch, one review. A huge generated change never really gets reviewed.
4. Require tests in the same pull request. Permissions, billing, migrations: no merge without a test.
5. Keep permissions tight. Do not pre-approve commands that touch production or the network. The permissions docs show how to restrict them per project.
6. Have a competent human review what is critical. Not everything, but everything that touches customer data, money and authentication.

The most expensive mistakes

• Mistaking a demo for a product. A convincing demo is a success, not a launch.
• Letting the agent pick the architecture. It will choose something reasonable, not necessarily what your most demanding customers will need in two years.
• Never testing with two tenants. The simplest test there is, and the one most often skipped.
• Accepting changes unread because they seem to work. Anthropic's own security page is explicit about whose responsibility that is.
• Ignoring ownership. What you truly own in generated code depends on human input and on your contracts, and the rules differ between the US, the UK and the EU. Document who decided what from the start.

Claude Code, Lovable or a studio

Claude Code is not an app builder: it assumes a repository, a terminal or an editor, and the ability to judge its output. A tool like Lovable starts from a chat and hosts the app for you. Both approaches are compared without picking a winner in Lovable vs Claude Code.

When not to build at all

If an off-the-shelf product already covers most of your need, and your edge is not in the software itself, subscribing to that product will cost less than building a SaaS, with or without Claude Code. Custom software pays off when the software is your product, or when the way you work is what sets you apart.

When to bring in help

Bringing in help does not mean dropping Claude Code. At LPR Studio we publish and run our own software, such as Izi-Devis and Tubissime, and we write a large share of our code with assistants of this kind. What does not change: every change is reviewed and tested before production, and we answer for what runs.

The right moment usually comes with one of three signals: a first customer ready to pay, personal or sensitive data entering the database, or a repository nobody can change any more without breaking something else.

Where to start

Before opening a terminal, write down on one page the three journeys your first customers will make every week, and the two roles that must not see the same data. That is your first CLAUDE.md. It is also where we start from for a free prototype, shown to you in a video call within 5 business days before you pay anything; our guide to the differences between a prototype, an MVP and a proof of concept explains what to expect from that step.