Write your Terms of Service and Privacy Policy

Most SaaS needs three documents: Terms of Service (the contract between you and the user), Privacy Policy (the GDPR/CCPA notice), and a Data Processing Agreement (the back-end contract for B2B customers whose users you process data for). Some businesses also need an Acceptable Use Policy, an SLA, and an EULA for downloadable software. Pick the set you actually need before you write a word.

Most ToS / privacy template fails are because the doc doesn't match the product. Before you write, build a one-page product spec: what users do, what data flows, who pays whom, what's in scope, what's out of scope. The legal docs ride on top of this spec. Without it, you're filling in a generic template with vague guesses.

Read this codebase + the product landing page + any internal product specs and produce a 1-page legal-grade product spec.

Output:
1. What the product does (in plain English, 2-3 paragraphs)
2. Who uses it (target user, role, intended use cases)
3. Pricing model (free / freemium / subscription / usage-based / one-time / mixed)
4. Personal data collected (every field, where stored, how long retained)
5. Sub-processors (every third party that processes user data)
6. Integrations (OAuth scopes, API surface, webhooks)
7. Out of scope (what the product is NOT, to set ToS expectations)

Output to the Brief surface as a versioned product-spec section. The ToS + privacy notice will derive from this spec.

A SaaS ToS typically has 25-35 clauses across 6 sections: Definitions, Account & Use, Payment & Subscription, Intellectual Property, Liability & Disclaimers, General Provisions (governing law, dispute resolution, modification). Use a respected starting template (Stripe, Common Paper, your competitor) but rewrite every clause to match your product spec.

Draft a Terms of Service for this SaaS based on the product spec in the Brief.

Use the Common Paper Cloud Service Agreement as the structural reference. Adapt every clause to this product. Output:

1. Definitions (User, Account, Service, Subscription, Content, Confidential Information)
2. Account & Use (eligibility, security, prohibited uses, content rights, suspension)
3. Payment & Subscription (pricing, billing, refunds, cancellation, auto-renewal, taxes)
4. Intellectual Property (your platform IP, user content ownership, license to use, feedback)
5. Liability & Disclaimers (warranty disclaimer, limit of liability, indemnification — both directions)
6. General Provisions (term, termination, governing law, dispute resolution, modification, severability, notices)

Plain language. No "WHEREAS" / "HEREINAFTER". Each clause should be 1-3 paragraphs. Mark sections that need lawyer review (limit of liability cap, governing law, arbitration vs court).

Output to the Brief surface as a versioned ToS section.

Your privacy policy is the public-facing version of your GDPR / CCPA / state-law disclosures. It must list every category of personal data, every purpose, every sub-processor, every retention period. The big mistake is copying a competitor's privacy policy without auditing what YOUR app actually collects. Match the data inventory exactly.

If you have B2B customers (companies who use your product to process THEIR users' data), they'll demand a DPA. Common Paper publishes a free standard DPA used by hundreds of SaaS companies — start there. The DPA covers: scope of processing, sub-processor list, security measures, breach notification, data return / deletion on termination, audit rights.

Cookie consent is enforced under the EU ePrivacy Directive + UK PECR + (increasingly) US state laws. Non-essential cookies (analytics, advertising, social) require user consent BEFORE they fire. The cookie notice lists every cookie set, the purpose, and the retention. Most SaaS uses a generator (Cookiebot, Cookieyes, Iubenda).

Generated docs are 80% of the way there. The remaining 20% is product-specific risk that templates miss: limit of liability cap appropriate to your contract sizes, IP carve-outs that match your actual model, indemnification scope, governing law that's enforceable for your customer base. Budget 1-3 hours of a SaaS lawyer's time ($300-$800) for a final review.

Hosting a ToS is mostly straightforward, but the maintenance is where most SaaS companies fall down. Every material change needs a version bump, a 30-day user notice, and a record of what changed when. Build the rhythm now so the docs don't drift away from reality 6 months in.

Quarterly review pass: read the latest sprint's PRs + product changes and check whether the ToS, privacy notice, DPA, or cookie notice need an update.

For each change, output:
1. The change (e.g. "Added OpenAI for AI features")
2. The doc(s) that need an update (ToS for new feature scope; privacy for new sub-processor; DPA sub-processor list)
3. The specific clauses affected
4. Whether the change is material (requires 30-day user notice) or non-material (silent update with version bump)

Output as new rows on Steps for each doc that needs an update.