The Legal Pages Every SaaS Actually Needs in 2026

This is the post I wish I'd had before my first SaaS launch. Not because lawyering matters (it does, but that's a separate conversation), but because skipping these pages causes specific, avoidable problems. Your Stripe account freezes. Apple rejects your app. A customer emails asking where to request a refund and there's no answer on your site.

Here is what you actually need, why each one matters, and what it has to cover. No template affiliate links. No "consult a lawyer" hand-waving. Practical guidance for solo founders who want to ship without getting blocked.

The five pages

1. Privacy Policy: what data you collect and what you do with it
2. Terms of Service: the rules of using your product
3. Refund Policy: what happens when someone wants their money back
4. Contact: how to reach a real human
5. About: who's behind the product

Some projects need more (cookie notice if you use tracking cookies, DPA if you process data for business customers under GDPR, imprint page in Germany). But these five are the minimum for a SaaS in 2026. Start here.

1. Privacy Policy

The most-requested page. Legally required under GDPR, CCPA, and most other privacy regulations if you collect any personal data (which, for a SaaS, is basically always: email, IP, usage).

What it must cover:

• Who you are and how to contact you about privacy
• What personal data you collect (email, name, usage events, IP, device info)
• Why you collect each piece of data (auth, service delivery, analytics, billing)
• Who you share it with (third parties: analytics, payment processor, email provider, AI vendor)
• How long you keep it
• How users can request deletion or export
• Whether you use cookies (and if so, a link to a cookie policy)
• A last-updated date

Write it in plain language. Nobody reads legalese. Clear, specific, honest is better than scary and vague.

2. Terms of Service

The rules. What users can and can't do with your product. What happens if they break the rules. How disputes are handled. This is what Stripe's automated risk system looks for when deciding whether your business is legitimate.

What it must cover:

• What your service does (one sentence)
• Who can use it (age, geography, business type)
• Acceptable use (no spam, abuse, illegal content, etc)
• Account termination rights (yours and the user's)
• Payment terms, if paid
• Limitation of liability ("provided as is")
• Intellectual property (who owns what)
• How users get notified of changes to the terms
• A last-updated date

A one-person SaaS doesn't need 40 pages of terms. Five hundred words is enough if it's clear.

3. Refund Policy

If you take any money (subscriptions, one-time purchases, even donations through a Buy Me a Coffee link), you need this page. Even if your policy is "no refunds," you still have to state that clearly and publicly.

Missing refund policies are the number one reason Stripe freezes indie hacker accounts. Read Stripe froze your account: what to check for the full breakdown.

What it must cover:

• Whether refunds are available
• The window (7, 14, 30 days, or "no refunds")
• How to request one (email, in-app button, contact form)
• What's eligible and what isn't
• How long processing takes

Best practice for indie SaaS: offer a 14-day money-back guarantee, process refunds manually via email. It reduces chargebacks, builds trust, and you'll rarely be taken advantage of.

4. Contact

This sounds obvious. But so many sites have no way to reach a human. A contact page with a real email address (not a form that disappears into a void) is the difference between a site that looks legitimate and a site that looks like a scam.

What it must cover:

• A real email address (monitored, responded to)
• Expected response time ("within 24 hours" is fine)
• What kinds of questions the email is for (support, billing, press, etc)

Tip: use a dedicated address like support@yourapp.com or hello@yourapp.com. It signals a real business. A personal Gmail works for the first ten customers, but at some point you'll outgrow it.

5. About

People want to know who built the thing they're about to pay for. The about page is where you answer that. It doesn't have to be long. Three paragraphs is enough. A photo helps.

What it must cover:

• Who you are (name, background, or at least "a solo builder")
• Why you built this
• What problem it solves
• How to reach you

If you're building in public, link to your X, LinkedIn, or GitHub. Transparency is a trust signal and a trust signal is a conversion signal.

Where to put the links

All five pages live in your site footer. Same footer on every page. This is not optional. If a customer has to search for your privacy policy, it doesn't count. If Stripe's automated risk system can't find your terms of service in the footer, it flags your account.

Standard footer structure:

Pricing | About | Contact | Privacy | Terms | Refund

Also: add the privacy policy and terms links to your sign-up flow. Most apps include a checkbox at registration: "By signing up you agree to our Terms and Privacy Policy." This is an extra layer of consent that helps with legal questions later.

What you don't need (yet)

• Cookie consent banner: only if you use tracking cookies. If you're using Plausible or Fathom (which don't use cookies), you don't need one.
• DPA (Data Processing Agreement): required if you process personal data on behalf of business customers (B2B SaaS). Not required day one for a B2C or indie project. Add it when you get your first enterprise-ish customer.
• Imprint page: required in Germany and some EU countries. If you have German customers, add one. For US-only indie projects, skip for now.
• Acceptable Use Policy: a separate document from terms of service for what users can't do. Most indie SaaS fold this into their terms. Only separate it if you're at enterprise scale.

Templates versus writing your own

You can use a template. You can even use a generator. Both are fine as starting points. What matters is that the final page accurately describes your business and is specific to what you actually do. Generic template language that doesn't match your app is worse than no template at all, because both Apple and Stripe reject mismatches.

Good starting points:

• Termly - privacy policy and terms generator, free tier
• iubenda - more thorough, paid
• GitHub open-source templates for privacy policy and terms (read the license)
• Looking at what similar-size indie SaaS have published and adapting

What to avoid: copying a policy verbatim from another company. At best it's inaccurate (their data practices aren't yours). At worst it's plagiarism.

The 30-minute version

If you're launching in two days and haven't written any of this yet:

1. Write a 200-word privacy policy in plain language. List the specific third parties you use.
2. Write a 300-word terms of service. Cover acceptable use, termination, limitation of liability.
3. Write a 100-word refund policy. State the window and the process.
4. Create a contact page with a real email.
5. Create an about page with your name and why you built this.
6. Link all five from the footer.

Done. It's imperfect but it's there, and that's the goal.

How CalmLaunch handles this

The Trust and Legal category in CalmLaunch checks for all five pages, verifies they exist at the URLs you'd expect, and flags any that are missing or broken. It also catches the specific issues that Stripe and Apple care about: third-party disclosure in your privacy policy, refund window clarity, and whether the links are actually visible in your footer.

See the eight launch categories for the full picture.

Common questions

Do I need a privacy policy if I don't collect email addresses?

Most likely yes. If you use analytics, show ads, or accept any user input, you probably still collect some personal data (IP address is considered personal data under GDPR). Err on the side of having one.

Can I use one page for privacy and terms combined?

No. They're different agreements with different purposes. Apple and Google specifically require separate privacy policies. Combine them and you'll fail submission.

What if I'm just running a free tool with no users?

If you don't take any data and don't take any money, you can get away with a privacy policy and a contact page. But as soon as you add signup, analytics, or any payment, you need the full set.

Do I need a lawyer to review these?

Not for an indie SaaS at launch. Self-written or template-based pages are sufficient for Stripe, Apple, Google, and the vast majority of customer interactions. If you hit meaningful revenue ($10K/month plus) or start selling to enterprises, invest in a proper legal review.