Claude Code for SaaS Development
How to use Claude Code for SaaS development — from scaffolding multi-tenant data models to writing subscription logic and keeping test coverage honest.
SaaS products have a reputation for being straightforward to build until you're actually building one. The initial CRUD layer goes fast. Then you hit multi-tenancy, subscription state management, per-seat billing, role-based access control, and the edge cases that live at every intersection of those concerns. That's where most SaaS projects slow down.
Claude Code for SaaS development changes the economics of some of those slower phases. Not because it writes perfect code, but because it removes the tedium from work that's well-understood but time-consuming. Writing the fifteenth route handler that follows the same pattern as the fourteenth shouldn't take an engineer 45 minutes. It shouldn't.
At Laxaar we've used Claude Code across SaaS projects in different stacks. The honest assessment: it accelerates repetitive-but-critical work significantly, and it's mediocre at anything requiring deep context about your specific business rules. Both of those facts are useful for planning how to use it.
What you'll learn
- Where Claude Code fits in a SaaS project
- Scaffolding multi-tenant data models
- Subscription and billing integration patterns
- Authentication and authorization with Claude Code
- Test coverage for SaaS-specific edge cases
- What Claude Code doesn't do well in SaaS projects
- Frequently Asked Questions
Where Claude Code fits in a SaaS project
Claude Code is Anthropic's terminal-based agentic coding tool that works with Claude Opus, Sonnet, and Haiku to read files, run commands, and edit code across a project. It's not a code autocomplete tool; it reasons about multi-file changes and can execute tasks that span a dozen files when prompted correctly.
For SaaS development specifically, the highest-value uses fall into three categories:
Pattern replication. Once you've built one API route, webhook handler, or database migration with your chosen patterns, Claude Code can replicate that pattern across new features accurately. The model reads your existing implementation, matches the style, and produces something reviewable.
Boilerplate elimination. SaaS projects accumulate a lot of necessary boilerplate: input validators, error response formatters, middleware compositions, test fixtures. This work is critical but not intellectually interesting. Claude Code handles it faster than any developer would.
Documentation and specification. Claude Code can read your codebase and produce accurate API documentation, data model descriptions, or onboarding guides. This is underused and genuinely useful.
The work it doesn't accelerate: product decisions, complex business logic, performance optimization with real load data, anything that requires understanding your specific customer contracts.
Scaffolding multi-tenant data models
Multi-tenancy is where the opinionated choices in your data model matter most, and where getting them wrong is expensive. There are three common patterns:
| Pattern | Isolation level | Complexity | Best for |
|---|---|---|---|
Shared table with tenant_id | Row-level | Low | Most SaaS products |
| Schema-per-tenant | Schema-level | Medium | Compliance-sensitive products |
| Database-per-tenant | DB-level | High | Enterprise with strict data residency |
Claude Code can scaffold the shared-table pattern effectively once you've made the architecture decision. Here's a useful approach:
Write your first model manually (say, a Project table with a tenantId foreign key, the relevant indexes, and a Prisma schema entry). Then ask Claude Code to add the next model following the same pattern:
Read src/db/schema.prisma and understand the multi-tenancy pattern in the
Project model. Now add an Issue model that belongs to a Project, following
exactly the same tenantId approach. Include the same index patterns.
This works reliably. What doesn't work: asking Claude Code to design your multi-tenancy approach from scratch. It'll produce a reasonable-looking schema that may not match your isolation requirements, your query patterns, or your future compliance needs. Make the architecture call yourself, then let Claude Code implement it.
Row-level security for the shared-table pattern is another place where Claude Code accelerates implementation. Once you've written one Postgres RLS policy, Claude can generate equivalent policies for additional tables:
-- Example RLS policy Claude Code can replicate accurately
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON projects
USING (tenant_id = current_setting('app.current_tenant_id')::uuid);
The caveat: always test RLS policies in a staging environment with real cross-tenant test data. Claude Code generates correct-looking SQL that occasionally has subtle gaps in edge cases.
Subscription and billing integration patterns
Subscription billing is where most SaaS complexity lives. Stripe is the dominant integration target, and Claude Code handles Stripe integrations reasonably well because Stripe's API is well-documented and the integration patterns are widely repeated in training data.
Tasks Claude Code handles well:
- Creating webhook handler boilerplate for Stripe events (
customer.subscription.updated,invoice.payment_failed, etc.) - Writing the idempotency logic for webhook processing
- Generating the subscription state machine transitions
- Adding the billing portal redirect flows
Here's a webhook handler scaffold that Claude Code can produce and extend:
// src/app/api/webhooks/stripe/route.ts
import Stripe from 'stripe';
import { headers } from 'next/headers';
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
export async function POST(req: Request) {
const body = await req.text();
const signature = headers().get('stripe-signature')!;
let event: Stripe.Event;
try {
event = stripe.webhooks.constructEvent(
body,
signature,
process.env.STRIPE_WEBHOOK_SECRET!
);
} catch (err) {
return new Response('Webhook signature verification failed', { status: 400 });
}
switch (event.type) {
case 'customer.subscription.updated':
await handleSubscriptionUpdated(event.data.object as Stripe.Subscription);
break;
case 'invoice.payment_failed':
await handlePaymentFailed(event.data.object as Stripe.Invoice);
break;
default:
// Unknown event type — log and ignore
}
return new Response(null, { status: 200 });
}
Ask Claude Code to implement each handler function following your existing database patterns. The model will correctly add idempotency checks if you ask, but it won't add them by default. Be explicit.
One thing to be careful about: metered billing and usage-based pricing are harder for Claude Code to get right because they involve product-specific business rules. The code structure is straightforward, but the logic of what counts as a billable event, when to report usage, and how to handle edge cases around plan changes are decisions that need to come from you.
Authentication and authorization with Claude Code
Auth is the part of SaaS development where mistakes are most costly. The Laxaar team's rule: use Claude Code to implement auth integrations, not to design them.
If you're using an auth provider (Auth0, Clerk, NextAuth, Supabase Auth), Claude Code is useful for:
- Writing the session middleware that attaches the current user to request context
- Implementing the role check middleware for protected routes
- Generating the permission matrices for RBAC systems once you've defined the roles
Here's an example of a scoped Claude Code prompt for RBAC:
Read src/lib/auth/session.ts to understand how we get the current user.
Now add a requireRole() middleware function that accepts an array of allowed roles
and returns a 403 if the current user's role isn't in that list.
Follow the same error response format as src/lib/errors.ts.
Don't touch any other files.
The scope constraint ("don't touch any other files") is important. Auth code that reaches further than expected is a source of subtle bugs.
What Claude Code shouldn't design from scratch: your permission model. Whether you use flat roles, hierarchical roles, attribute-based access control, or resource-level permissions is a product decision that needs to reflect your customer contracts and your billing tiers. Make that decision on a whiteboard, document it, then ask Claude Code to implement it.
Test coverage for SaaS-specific edge cases
SaaS applications have a set of edge cases that generic test generation misses. Claude Code will write tests if you ask, but it defaults to happy-path coverage unless you push for edge cases explicitly.
The edge cases worth being explicit about:
- Tenant boundary violations. Can user A in tenant A access user B's resources? Test this explicitly.
- Subscription state transitions. Expired trial, past-due payment, plan downgrade mid-billing-cycle: these need tests.
- Concurrent modification. Two users modifying the same resource simultaneously. Often untested and occasionally catastrophic.
- Quota enforcement. What happens when a tenant exceeds their plan's limits?
Prompt pattern that produces better edge case tests:
Look at src/app/api/projects/route.ts and the existing tests in
src/app/api/projects/__tests__/route.test.ts.
Write additional tests for these edge cases:
1. A request where the tenantId in the auth token doesn't match the project's tenantId
2. A request from a user whose subscription is in past_due state
3. A request that would put the tenant over their project quota limit
Use the same test patterns and fixtures as the existing tests.
The explicit list of edge cases is the key. Without it, Claude Code writes additional happy-path tests and calls it coverage.
What Claude Code doesn't do well in SaaS projects
Honest assessment of where Claude Code falls short, because the productivity gains are real, but so are the blind spots.
Complex business logic. Proration calculations, usage aggregation across billing periods, credit application logic: these involve business rules that require reading your terms of service and your customer contracts, not just your code. Claude Code will produce plausible implementations that are often subtly wrong.
Performance optimization. Claude Code can suggest indexes and query rewrites, but it can't run EXPLAIN ANALYZE on your actual data distribution. Database performance work requires real load testing against real data shapes.
Data migrations on live databases. Asking Claude Code to write a migration that runs against a 10M-row table in production is asking for a bad day. The model doesn't know your row counts, your lock contention patterns, or your maintenance window constraints.
Security review. Claude Code can help implement security patterns, but it shouldn't be your security review. A separate, explicit security review pass is required for auth changes, data access patterns, and anything touching billing.
The productivity ceiling is also real: Claude Code accelerates individual developer output, but it doesn't replace architectural thinking, product decisions, or the engineering judgment that comes from having shipped similar systems before.
Frequently Asked Questions
Is Claude Code safe to use on a production SaaS codebase?
Yes, with guardrails. Keep it in a feature branch, require human review on every diff, and never let it run destructive commands without confirmation. We treat its output exactly like a junior engineer's pull request: useful, fast, and reviewed before it merges.
Can Claude Code handle multi-tenant architecture decisions?
It can implement a tenancy model you've already chosen, but it shouldn't choose one for you. Whether you use schema-per-tenant, row-level security, or separate databases is an architecture decision that depends on your scale, compliance needs, and team. Decide first, then let Claude Code scaffold it.
How does Claude Code handle Stripe and billing logic?
It's good at wiring up webhook handlers and typed event processing, and weak at proration math and usage aggregation. Treat billing code as high-risk: generate it with Claude Code, then review every line against your actual pricing rules and add edge-case tests for subscription state transitions.
Does using Claude Code mean we need fewer engineers?
No. It shifts where engineering time goes, away from boilerplate and toward review, architecture, and product judgment. The teams Laxaar works with ship faster with the same headcount, not the same speed with fewer people.
What's the best first project to try Claude Code on?
Pick something with clear patterns and low blast radius, like adding CRUD endpoints that mirror existing ones, or generating a test suite for an untested module. Save the auth and billing work until you trust its output on lower-stakes code.
SaaS development with Claude Code works best as a pattern-replication and boilerplate-elimination tool, not an autonomous builder. The engineering decisions (your tenancy model, your permission design, your billing rules) are still yours. Claude Code handles the implementation distance between "we've decided" and "it works."
Laxaar builds SaaS products end-to-end, including the architecture decisions that Claude Code can't make. If you're starting a new product or scaling an existing one, talk to our team about what an AI-assisted engineering practice actually looks like in production.
