A Better CLAUDE.md Template for SaaS Founders

Eli A — Thu, 21 May 2026 06:05:55 +0000

Your AI coding agent needs product reality, not only repo commands. Here is a practical CLAUDE.md template for SaaS founders using Claude Code.

Most CLAUDE.md files start with the repo.

They explain:

- Use pnpm.
- Run tests before committing.
- Components live in /components.
- API routes live in /app/api.
- Follow TypeScript strict mode.

That is useful.

It is also incomplete.

For a SaaS founder, the biggest risk is not that Claude Code forgets the test command. The bigger risk is that the agent builds the wrong product surface because the product context is missing.

A coding agent can follow repo rules and still create:

dashboards before activation works
team roles before the solo workflow is validated
integrations before retention is proven
pricing pages before willingness to pay is understood
admin panels before the first customer exists
generic SaaS bloat around a weak wedge

The issue is not coding quality.
The issue is missing product memory.

Claude Code’s memory system is designed to keep project context available across sessions through files such as CLAUDE.md. Anthropic’s docs describe this as project memory, and Claude Code also supports hooks, skills, subagents, and other extension points for more advanced workflows. (Claude Code)

The founder mistake is treating memory as only engineering instructions.

A better CLAUDE.md starts with product reality.

The mental model

Think of CLAUDE.md as two files in one:

Product Memory
  +
Engineering Memory

Engineering memory tells Claude how the repo works.

Product memory tells Claude what the product is trying to prove.

Both matter.

Without engineering memory, the agent may break conventions.
Without product memory, the agent may build the wrong thing correctly.

The structure I recommend

Use this order:

1. Product Reality
2. Current Bet
3. Must Build / Must Not Build
4. Evidence Goal
5. Engineering Rules
6. Safety Boundaries
7. Required Workflow

A founder-friendly CLAUDE.md should be short enough to be read often and specific enough to shape behavior.

Template: product-aware CLAUDE.md

# CLAUDE.md

## 1. Product Reality

We are building [PRODUCT] for [SPECIFIC CUSTOMER] because [PAIN / JOB] is frequent, costly, or urgent enough to justify switching or paying.

Current stage:
- [idea / prototype / MVP / post-MVP / growth]

Reality envelope:
- [bootstrap SaaS / VC-scale startup / internal tool / side project / agency spinout]

Primary user:
- [who uses it]

Economic buyer:
- [who pays or approves]

Current alternative:
- [spreadsheet / manual work / agency / incumbent tool / internal process]

Geography or market scope:
- [local / national / global / regulated market / specific region]

This first block prevents the agent from assuming every SaaS is the same.

A bootstrap B2B SaaS for consultants should not be built like a VC-backed enterprise platform. A local regulated workflow should not be built like a global self-serve productivity app.

2. Current Bet

## 2. Current Bet

The current wedge is:
- [one narrow workflow or use case]

The next release must prove:
- [one critical assumption]

The product should optimize for:
- [activation / willingness to pay / retention / workflow completion / demo conversion / first-value moment]

The product should not optimize for yet:
- [scale / enterprise features / deep integrations / automation depth / multi-segment support]

This turns the build into a learning system.

Without this section, Claude may optimize for “complete SaaS app.” That usually means more screens, more settings, more generic features.

The right early product is not the most complete version.

It is the smallest version that can test the current bet.

3. Must Build / Must Not Build

## 3. Must Build Now

- [Core onboarding step]
- [First-value workflow]
- [Critical data model]
- [Activation event tracking]
- [Basic error states]
- [One testable user journey]

## 4. Must Not Build Yet

- Do not add team management unless explicitly requested.
- Do not add role-based permissions beyond the current release scope.
- Do not add integrations before the core workflow is validated.
- Do not add advanced analytics before activation is proven.
- Do not create admin dashboards unless required by the approved task.
- Do not expand to additional ICPs.
- Do not add new pricing tiers without approval.

The Must Not Build Yet section is often more valuable than the Must Build section.

AI agents are good at completing patterns. “SaaS app” is a pattern. The agent may infer billing pages, settings, teams, notifications, analytics, dashboards, and exports.

That can be useful later.

Early, it can bury the wedge.

4. Evidence Goal

## 5. Evidence Goal

This release should help us learn whether:

- [specific user] can reach [specific value] without founder help.
- [buyer] understands why this product is worth paying for.
- [workflow] is frequent enough to support retention.
- [pricing hypothesis] is plausible.
- [technical approach] can deliver value at acceptable cost.

Primary success signal:
- [one measurable signal]

Secondary signal:
- [one backup signal]

Kill or pivot trigger:
- [what would make us change direction]

This is the part most technical instructions omit.

But it is essential for SaaS founders.

The product is not only a code artifact. It is a test of a market assumption.

A tool like Gaplyze’s product validation and roadmap workspace is useful before writing this section because the founder needs to clarify the ICP, wedge, monetization hypothesis, must-not-build boundaries, and first evidence loop before those constraints are handed to Claude Code.

5. Engineering Rules

Now add the repo details.

## 6. Engineering Rules

Stack:
- Framework:
- Language:
- Database:
- Auth:
- Payments:
- Hosting:
- Styling:
- Testing:

Important directories:
- /app:
- /components:
- /lib:
- /db:
- /tests:

Commands:
- Install:
- Typecheck:
- Lint:
- Unit tests:
- E2E tests:
- Build:

Keep this concrete.

Do not write vague rules like:

Write clean code.
Follow best practices.
Make it scalable.

Those are too broad.

Write rules that affect actual decisions:

Prefer server actions for simple mutations.
Use existing UI primitives before adding new components.
Do not introduce new dependencies without explaining the tradeoff.
All customer-visible flows need loading, empty, success, and error states.

6. Safety Boundaries

Claude Code hooks can provide deterministic control by running shell commands at specific lifecycle points, which is different from simply hoping the model remembers a rule. Anthropic’s docs describe hooks as a way to enforce project rules, automate repetitive tasks, and integrate with existing tools. (Claude Code)

So do not rely on CLAUDE.md for everything.

Use memory for context.

Use hooks, permissions, CI, and reviews for enforcement.

Still, the safety section should be explicit:

## 7. Safety Boundaries

Never do the following without explicit approval:

- Modify production database migrations.
- Run destructive database commands.
- Change billing or Stripe logic.
- Alter authentication or authorization behavior.
- Add new environment variables.
- Add new third-party services.
- Change pricing, plan limits, or quota logic.
- Store sensitive data in logs.
- Remove tests to make a build pass.

This section is especially important for SaaS products because early mistakes in auth, billing, tenant isolation, and data handling can become expensive quickly.

7. Required Workflow

## 8. Required Workflow

For any non-trivial change:

1. Read the Product Reality and Current Bet sections.
2. Restate the relevant product constraint.
3. Inspect the relevant files before planning.
4. Propose a short plan.
5. Identify risks and tests.
6. Wait for approval before broad changes.
7. Implement the smallest approved slice.
8. Run required checks.
9. Summarize what changed, what was not changed, and what should be tested manually.

This workflow makes the agent slower at the start and faster overall.

It prevents the common failure mode where the agent begins editing before it understands the product boundary.

A compact full version

Here is the shorter version you can actually paste into a repo and adapt.

# CLAUDE.md

## Product Reality

We are building [PRODUCT] for [SPECIFIC CUSTOMER] because [PAIN] is frequent, costly, or urgent.

Stage:
[idea / prototype / MVP / post-MVP / growth]

Reality envelope:
[bootstrap SaaS / VC-scale startup / internal product / side project]

Primary user:
[...]

Economic buyer:
[...]

Current alternative:
[...]

## Current Bet

Current wedge:
[...]

This release must prove:
[...]

Optimize for:
[...]

Do not optimize for yet:
[...]

## Must Build Now

- [...]
- [...]
- [...]

## Must Not Build Yet

- Do not add team management unless explicitly requested.
- Do not add integrations before the core workflow is validated.
- Do not add advanced analytics before activation is proven.
- Do not expand to additional ICPs.
- Do not change pricing or plan logic without approval.

## Evidence Goal

Primary success signal:
[...]

Secondary signal:
[...]

Kill or pivot trigger:
[...]

## Engineering Rules

Stack:
- Framework:
- Language:
- Database:
- Auth:
- Payments:
- Styling:

Commands:
- Typecheck:
- Lint:
- Test:
- E2E:
- Build:

Architecture rules:
- [...]
- [...]
- [...]

## Safety Boundaries

Never do without approval:
- Modify migrations.
- Run destructive DB commands.
- Change billing logic.
- Change auth/authorization behavior.
- Add dependencies.
- Add environment variables.
- Remove tests to make checks pass.

## Required Workflow

For non-trivial work:
1. Restate the product constraint.
2. Inspect before planning.
3. Propose a plan.
4. Identify risks and tests.
5. Implement only the approved slice.
6. Run checks.
7. Summarize changes and verification.

What should not go into CLAUDE.md

Do not turn this file into a dumping ground.

Avoid:

full PRDs
long market research reports
giant competitor tables
every customer quote
every roadmap item
every design-system token
every security policy
every possible architecture decision

Large, noisy memory files can make the agent less focused.

Put repeatable workflows into skills. Claude Code supports skills as reusable capabilities, and its broader extension system includes subagents, hooks, and MCP servers for more specialized work. (Claude Code)

Use separate docs when needed:

CLAUDE.md                  core product + engineering memory
docs/product/strategy.md   deeper product context
docs/roadmap/current.md    active roadmap slice
docs/security/rules.md     deeper security rules
docs/testing/e2e.md        Playwright journey guidance

The CLAUDE.md file should point to the right context, not contain everything.

A better first prompt after adding CLAUDE.md

After creating the file, do not immediately ask Claude to build.

Start with calibration:

Read CLAUDE.md.

Do not edit code yet.

Summarize:
1. the target customer,
2. the current wedge,
3. the must-not-build constraints,
4. the evidence goal,
5. the engineering safety boundaries.

Then identify any contradictions or missing details that would affect the next implementation task.

This turns memory into an active contract.

The core idea

A good CLAUDE.md is not just a codebase instruction file.

For SaaS founders, it is an alignment file.

It aligns:

customer
  → wedge
  → evidence goal
  → product scope
  → engineering rules
  → safety boundaries

When that alignment is missing, AI coding agents make it easier to build a product that looks complete but teaches the founder very little.

When the alignment is present, Claude Code becomes much more useful because it is executing inside a real product frame.

Build memory before building features.

DEV Community: Eli A