CLAUDE.md Template: Next.js + TypeScript + Supabase + Clerk + Stripe for AI Sales Outreach SaaS

Overview

The CLAUDE.md template is a production-ready, copyable CLAUDE.md page tailored for building a complete AI Sales Outreach Agent SaaS stack using Next.js, TypeScript, Supabase, Clerk, Stripe, CRM import, email generation, and campaign analytics. It provides a precise, stack-specific CLAUDE Code block you can paste into Claude Code to bootstrap features, maintain architecture discipline, and accelerate delivery.

Direct answer summary: This page delivers a stack-specific CLAUDE.md template that defines project roles, architecture and file structure rules, authentication, database, validation, security, testing, deployment, and do-not-do guidelines for a Next.js + TS + Supabase + Clerk + Stripe SaaS with CRM import, email generation, and analytics.

When to Use This CLAUDE.md Template

• When building a production AI Sales Outreach SaaS on Next.js with TypeScript and a Postgres backend (Supabase).
• When you require Clerk for authentication, Stripe for billing, CRM data import, and inbound/outbound email generation within campaigns.
• When you need a comprehensive, copyable CLAUDE.md template to enforce architecture, testing, CI/CD, and security across the stack.
• When onboarding new engineers and want a deterministic, stack-specific CLAUDE Code baseline to follow.

Copyable CLAUDE.md Template

# CLAUDE.md

Project role:
- You are Claude, the AI Sales Outreach Agent for a production SaaS built with Next.js, TypeScript, Supabase, Clerk, Stripe. You implement features and guide architecture.

Architecture rules:
- Build as a modular monorepo with apps/web (Next.js front-end) and apps/api (server code), using Supabase for data, Clerk for auth, and Stripe for billing.
- All business logic must run in TypeScript; separate UI, domain, and data layers; API routes should be typed and validated.
- Data flows from client to server via API routes; never expose service_role keys to the client; use anon/public keys.
- Use server components where possible; fetch data on the server to avoid leaking secrets; hydrate via client components.
- Implement a CRM import module that normalizes and deduplicates data before storage; support CSV/Excel uploads and API-based integrations.
- Email generation must be driven by campaign context; templates stored in DB; support personalized placeholders; track opens/clicks.
- Campaign analytics must be event-driven, capturing impressions, emails sent, responses, and revenue impact; expose dashboards to customers via API endpoints.
- Ensure CI/CD hooks verify type-safety, tests, and security checks on every push.

File structure rules:
- apps/web/
  - src/
    - app/ (Next.js App Router)
    - components/
  - next.config.js
  - tsconfig.json
- apps/api/
  - src/
    - lib/
    - routes/
    - services/
- packages/db/
  - schema.sql
  - migrations/
- scripts/
  - seed.ts
  - migrate.ts

Authentication rules:
- Clerk handles authentication; protect routes with middleware; enforce roles (admin, owner, analyst).
- Use signed tokens for server-side validation; never trust data from the client without verification; validate sessions on every API boundary.
- Passwordless sign-in preferred for smooth UX where appropriate; require MFA for admin actions.

Database rules:
- Supabase Postgres with tables: customers, campaigns, emails, analytics, imports, payments, users.
- Enable Row-Level Security (RLS) with tenant isolation; create policies that allow only authorized users to access their tenant data.
- Store sensitive credentials as Secrets in environment variables; never place secrets in client code.
- Create proper foreign keys and indexes on join columns (customer_id, campaign_id, email_id).
- Use stored procedures or server functions for sensitive operations (CRM import, payout updates).

Validation rules:
- Use Zod for input validation on all API routes; strictly type all payloads and outputs.
- Validate CSV/Excel uploads on the server; reject bad schema or duplicates before insertion.
- Enforce data shape for campaigns, emails, and analytics events.

Security rules:
- Enforce Content Security Policy (CSP), strict TLS, and CSRF protection on mutating endpoints.
- Do not log sensitive fields (tokens, emails, personal data) in access logs.
- Ensure all external calls are performed from server-side code or via authenticated API routes.
- Rotate keys and secrets regularly and store them in a secrets manager.

Testing rules:
- Unit tests for utilities and domain logic; integration tests for API routes and DB interactions; end-to-end tests for common user journeys (create campaign, import CRM data, generate and send emails, view analytics).
- Use Jest/Vitest for unit tests, Playwright for E2E; mock external services in unit tests.

Deployment rules:
- Deploy to Vercel with Next.js; configure environment variables for Supabase, Clerk, Stripe, and CRM endpoints.
- Run migrations on deployment; verify success before announcing production readiness.
- Enable monitoring and alerting for API latency and error rates.

Things Claude must not do:
- Do not hard-code secrets or private keys; never expose service_role or private credentials to the client.
- Do not bypass authentication or authorization checks; do not operate on data outside the tenant boundary.
- Do not generate or inject billing or payment tokens on the client.
- Do not rely on client-side validation for security-sensitive operations.
- Do not import or use libraries not part of the stack without explicit adaptation notes.

Recommended Project Structure

.
├── apps/
│   ├── web/
│   │   ├── app/            # Next.js App Router
│   │   │   ├── layout.tsx
│   │   │   └── page.tsx
│   │   ├── components/
│   │   └── styles/
│   └── api/
│       └── src/
│           ├── lib/
│           ├── routes/
│           └── index.ts
├── packages/
│   ├── db/
│   │   ├── migrations/
│   │   └── schema.sql
│   └── shared/
├── scripts/
│   ├── seed.ts
│   └── migrate.ts

Core Engineering Principles

• Type-safety and explicit interfaces across all layers (TypeScript first).
• Clear separation of concerns: UI, domain logic, and data access layers.
• Tenant isolation and robust security by design (RBAC, RLS, MFA).
• Data as the single source of truth; minimal client-side state for business data.
• Observability: structured logging, metrics, and tracing for production systems.
• Deterministic CI/CD with automated tests and linting on every push.

Code Construction Rules

• All code must be TypeScript with strict mode enabled; avoid any.
• API routes must validate input with Zod and type outputs; never return untyped data.
• Supabase access on the client uses anon/public keys; server-side calls use service logic via API routes or edge functions with proper authentication.
• CRM import should normalize data, deduplicate, and store in a dedicated tenant-scoped schema.
• Email templates must be stored in the database with placeholders and campaign context to allow personalization.
• Campaign analytics must be recorded in structured events with consistent names and fields.
• Follow the project’s directory structure and naming conventions to ensure consistency.

Security and Production Rules

• Enable RLS on all tables; implement tenant-aware policies.
• Use CSP, CORS, and TLS; ensure API routes require valid sessions.
• Secret management: store keys in a secure vault; never commit secrets to source control.
• Audit logging: mask or omit sensitive data in logs.
• Regular dependency updates and security patches; run automated vulnerability scans.

Testing Checklist

• Unit tests for utilities and domain logic.
• Integration tests for API routes and DB interactions.
• End-to-end tests for core user flows (import CRM data, create campaign, generate emails, view analytics).
• CI checks for type-safety, linting, and test suite; verify migrations run in CI.
• Performance checks for API endpoints under load.

Common Mistakes to Avoid

• Hard-coding credentials or exposing service keys in the client.
• Skipping server-side validation and relying on client-side checks.
• Ignoring tenant isolation; cross-tenant data leaks.
• Overusing client state for critical business logic; prefer server-side processing.
• Neglecting observability and test coverage in early stages.

Related implementation resources: AI Use Case for Software Agencies Using Github Copilot To Accelerate Boilerplate Code Generation for New Client Mvps and Domain-Specific Skill Files for Production Dashboards: Reusable AI Workflows for Enterprise AI.

FAQ

What stack does this CLAUDE.md Template cover?

Next.js, TypeScript, Supabase, Clerk, Stripe, CRM import, email generation, and campaign analytics.

How do I copy and use the CLAUDE.md template?

Copy the entire # CLAUDE.md block from the code sample and paste it into Claude Code for your stack-specific implementation.

How is security handled in this template?

Authentication via Clerk with RBAC, data isolation via Supabase RLS, CSP/CORS, TLS, and server-side validation for all sensitive operations.

What should I do after applying the template?

Wire up your actual CRM data, configure Stripe plans, set up webhooks, and implement deployment pipelines with migrations and monitoring.

Can I reuse this CLAUDE.md Template for other stacks?

Yes, but you should adapt the architecture rules, file structure, and integration specifics to the new stack while preserving the CLAUDE Code approach.