CLAUDE.md template for SaaS: scope, roles and acceptance tests
A useful CLAUDE.md tells a coding agent what the product must do and how to prove it. A list of preferred libraries helps the agent write code. It does not tell the agent which employer may read an application, what happens when a subscription expires, or whether an invoice can change after it has been sent.
Download the SaaS CLAUDE.md template (.md) · Download the worked job-board example (.md)
These are original, free starting documents. They contain a compact product contract and an example, not a complete paid PlanSmith planner or a promise that an agent will produce a production-ready application.
Fill in the product decisions before the stack
The template has six sections: product scope, roles and ownership, record lifecycles, delivery sequence, acceptance evidence and project commands. Replace every bracketed field. If a decision is unresolved, name it as unresolved instead of allowing the agent to choose silently.
| Section | Weak instruction | A decision the agent can implement |
|---|---|---|
| Scope | Build a SaaS dashboard | A job board for one niche, with employer listings and private candidate applications |
| Ownership | Add permissions | An employer may read applications only for jobs belonging to its organisation |
| Lifecycle | Add job status | Draft → Pending review → Published → Closed; only an admin publishes |
| Payment | Add a buy button | In the paid-listing branch, a verified payment event grants one listing entitlement exactly once |
| Evidence | Make sure it works | Two employers and two candidates exercise both allowed and denied record access through the UI and API |
Choose a narrow workflow you can actually complete. For a first job board, that might be publish a listing, submit an application, review it as the owning employer and withdraw it as the applicant. Recommendations, chat, subscriptions and resume search can be explicit exclusions.
Keep instructions and evidence separate
Put the durable contract in CLAUDE.md. Put credentials in environment variables and ignored local configuration. Keep the decision log, test output and screenshots in named project files linked from the contract. Do not paste access tokens, customer records or entire terminal transcripts into an instruction file.
Ask the agent to read the contract and list unresolved decisions before editing. After you answer them, have it propose a short implementation sequence. Each step should finish a usable piece of the workflow, including its permissions and failure behavior.
The worked example starts with identity and ownership, then completes job publication and applications. A dashboard comes later, once there are real records to count. That order makes it harder to confuse a populated demo with a functioning product.
Turn acceptance statements into tests
“Employer isolation works” is too vague. Use named actors and records:
- Employer A creates Job A. Employer B creates Job B.
- Candidate One applies to Job A. Employer A can read that application.
- Employer B requests the same application URL and API record. Both are denied without returning applicant details.
- Candidate Two tries the same request and is denied.
- Candidate One withdraws the application. The system records the withdrawal and enforces the access policy chosen in the contract.
The allowed access in step two is a control. If every user sees an empty page, that is not proof of correct isolation.
Use the same approach for failed payments, repeated webhooks, expired sessions and duplicate form submissions. State the expected result first, then record what happened. “Not tested” is a valid result. It is more useful than a broad pass based only on a successful build command.
Adapt the example to your vertical
Keep the structure and change the business objects. A school needs students, enrolments and attendance. Inventory needs items, locations and stock movements. A membership product needs dated entitlements and a clear relationship between payment and access. Renaming “job” to “student” without changing the lifecycle is not enough.
The job-board requirements guide develops the example into a PRD. How to build a job board with AI shows the implementation sequence. If you need guided discovery for a different business, choose a vertical-specific planner and inspect its research and demo evidence before buying.
What this template cannot settle for you
It cannot choose your market, prove demand, determine local compliance obligations or make untested code safe. It can make the decisions visible and give the builder a concrete completion standard. Keep that standard tied to saved data, user permissions and repeatable evidence rather than the amount of code generated.