--- slug: legal-pages-for-indie-apps title: "Legal Pages for Indie Apps: What's Boilerplate-Fine and What's Not" excerpt: "Legal pages for indie SaaS don't have to be a panic project. Here's what to boilerplate, what to customize, and the EU realities solo founders miss." primaryKeyword: "legal pages indie SaaS" publishedAt: 2026-06-26 readingTimeMin: 9 author: "Robert Boylan" tags: - legal - gdpr - indie-dev - launch - compliance --- You've been meaning to "sort out the legal stuff" for three weeks. You have a Notion doc titled "TODO: privacy policy" that you haven't opened. Your app is technically live. There's a link in the footer that goes nowhere. Sound familiar? Most indie founders treat legal pages like flossing: they know they should, they keep putting it off, and then something bad happens and they wish they'd started sooner. The good news: for a typical solo-built SaaS, the legal pages indie founders actually need are fewer than you'd think, and most of the work can be done in an afternoon. You don't need to panic-buy a lawyer. You also don't need to paste a generic generator's output and pretend the work is done. There's a middle path, and this post maps it out. (Quick note before we dive in: this is not legal advice. It's an overview of what the landscape usually looks like for indie founders. For anything jurisdiction-specific or high-stakes, talk to an actual lawyer.) ## The four pages you actually need Most indie apps need four pages. Not ten. Not one. Four. **Privacy policy.** Required almost everywhere if you collect personal data. And you almost certainly collect personal data, even if it's just an email address. This page tells users what data you collect, why you collect it, who you share it with, and how they can ask you to delete it. **Terms of service.** This is the contract between you and your users. It covers what the service does, what it doesn't do, what users are allowed to do with it, and what happens if things go wrong. Think of it as the set of rules for the relationship. **Cookie policy / cookie banner.** Required if you have EU or UK users and you're using non-essential cookies. More on this in the cookie section below, because it's more nuanced than most people think. **Refund policy.** Required if you're selling anything. Credit card processors and app stores both expect one, and users will ask about it. A short, honest refund policy is also just good customer service. That's it. The legal pages indie SaaS founders actually ship with are usually just those four. You might add an "Acceptable Use Policy" later if you're worried about how people use your tool, but for most solo apps at launch, four is the right number. ## What boilerplate generators get right and what they miss Generator sites like Termly, iubenda, and GetTerms.io have gotten genuinely good at handling the structure. A generator will reliably give you: - The right section headers for each document type - Legally common phrasing around liability limits and warranty disclaimers - GDPR-compatible wording for data subject rights - A reasonable base for cookie consent language Where they fall short is in the specifics that actually describe your app. A generator doesn't know: **Your data retention period.** If a user deletes their account, how long do you keep their data? "30 days" and "indefinitely" are both answers, but they're very different answers, and your policy needs to say one. Don't leave it blank or vague. **Your sub-processors.** These are the third-party services you send user data to. Supabase, Brevo, Resend, Stripe, Polar.sh, your error tracking tool. Your privacy policy needs to name them (or at least describe the categories). A generator lists placeholders; you need real names. Check every service you use and list the ones that touch personal data. **Your jurisdiction.** A generator might give you GDPR language, CCPA language, and a few others by default. If you're a sole trader based in Ireland (like Draftlytic), some of that language doesn't fit your situation. Delete the parts that don't apply and add accurate details about where you operate. **Your actual payment processor.** "We use a third-party payment processor" is fine as general language, but users asking "where does my card data go?" deserve to know it's Stripe or Lemon Squeezy, not some unnamed entity. Name it. The practical approach: use a generator to get the structure and default phrasing, then edit every section for accuracy. It takes two hours, not two days. If you can read a plain-English document and spot the placeholders that don't match your app, you're done. Getting your legal pages for indie SaaS right is mostly just a matter of replacing "Company Name Inc." with the actual truth about how your app runs. ## GDPR and the indie founder: the bits that genuinely apply at small scale GDPR (the EU's General Data Protection Regulation) applies to any business that processes personal data of EU residents, regardless of where the business is based. If someone in Germany signs up for your app, GDPR applies to that signup. That sounds alarming, but the practical requirements at indie scale are fewer than the regulation's 99 articles imply. **What genuinely applies to you at launch:** - You need a privacy policy that accurately describes what you collect and why. - You need a legal basis for processing data (usually "legitimate interest" for operational data, "consent" for marketing emails, "contract performance" for account data). - Users have the right to request their data and ask you to delete it. You need to be able to honour these requests. "Email me and I'll delete your account" is a valid process for a small app. - If you share data with processors in countries outside the EU/EEA, there are transfer mechanisms to think about (standard contractual clauses are the common tool here; major providers like Stripe and Supabase handle this for you). **What matters more when you grow:** formal data processing agreements with every sub-processor, a Data Protection Officer (required above certain volume or sensitive data thresholds), Article 30 records of processing activities, and 72-hour breach notification timelines. The size threshold matters. A solo app with a few hundred users isn't the same risk profile as a company processing health data for millions. The basics are the basics: an accurate privacy policy, a way to handle deletion requests, and real data sent only to processors you've named. Do those and you're in much better shape than most indie apps at launch. ## Cookie banners: when you actually need one This is probably the most misunderstood piece of the puzzle. Let's be direct about it. You need a cookie consent mechanism if you are setting non-essential cookies on devices of EU or UK visitors. The key word is "non-essential." **Essential cookies don't require consent.** Session tokens, authentication state, CSRF tokens, load balancer cookies. These are technically necessary for the site to function. You can note them in a privacy/cookie policy, but you don't need a banner asking for consent. **Non-essential cookies do require consent.** Analytics (Google Analytics, Plausible in cookie mode, Mixpanel), advertising, third-party embeds, any cookie that tracks a user across sessions or sites beyond what's needed for the basic service. So if your app uses only: - An auth session cookie - A preferences cookie (dark mode, locale) - Privacy-respecting analytics that don't set cross-site tracking cookies (Plausible in cookieless mode, for instance) ...then you may not need a full consent banner at all. A paragraph in your cookie policy noting what cookies you set and why is sufficient. If you're running Google Analytics with tracking enabled, you need a banner. If you have a Facebook Pixel, you need a banner. If you're doing retargeting, you need a banner. Check what your stack actually sets. Many indie apps are much closer to the "no banner needed" line than they think, because they're not running heavy ad tech. [The vibe-coded app launch checklist](/blog/vibe-coded-app-launch-checklist) has a good pre-launch review pass that covers this alongside the other things worth checking before you go live. ## The trader name reality for sole proprietors If you're operating as a sole trader (sole proprietor in US terms), you are the legal entity. Your business name might be "AwesomeApp," but legally you're trading under your own name. In the EU, for online services, you typically need to display: your legal name, a business address, a contact email, and your VAT number if you're registered. "Robert Boylan, trading as Draftlytic, based in Ireland" is the kind of line that belongs on your legal pages, and ideally in your site footer too. It doesn't need to be prominent, but it does need to be findable. If you've registered a limited company (Ltd, LLC, etc.), use the registered name and company number instead. Generator-produced terms often say "Company Name Inc., a Delaware corporation" because the template was built for US startups. If you're a sole trader in Ireland, the UK, Germany, or anywhere else, that placeholder needs to be replaced with your actual legal identity. Not the variable name. Your actual name, your actual address. You can look at [Draftlytic's own privacy page](/privacy) as a real working example of how a solo-operated Irish SaaS handles this. It's not a template, but the structure and legal-identity disclosure are worth comparing to whatever a generator handed you. ## Getting the legal pages done without losing a week to it Here's a reasonable order of operations: 1. Run your app through a generator (Termly is reasonable; GetTerms.io is faster). Get drafts of your privacy policy and terms. 2. Grep every draft for placeholders: [Company Name], [YOUR COMPANY], [INSERT EMAIL]. Replace every one with real information. 3. List your actual sub-processors. Every service that touches user data gets a name. 4. Set a concrete data retention period and write it in. 5. Add your legal trading identity to the Terms page. 6. Check what cookies you actually set. Decide if you need a consent banner (you might not). 7. Write a short, honest refund policy. "Monthly plans aren't prorated on cancellation. Charged in the last 48 hours and changed your mind? Email us." Adjust to what you'd actually honour. 8. Link all four pages in your footer. Two hours of focused work covers most of this. What takes longer is sitting with uncertainty: "does this apply to me?" For those moments, a 30-minute consultation with a lawyer who works with indie SaaS founders costs less than six months of mental load. The legal pages for indie SaaS aren't about being airtight against every conceivable lawsuit. They're about being honest with your users: here's what we collect, here's what the deal is when you pay us. Most indie founders can do that clearly and accurately without inventing anything. The generator gets you 70% there. An honest afternoon of editing gets you the rest. When you're writing your spec before building, Draftlytic captures the business model, data handling needs, and audience details that feed directly into what your legal pages need to say. Getting those decisions down early means you're not reverse-engineering them when it's time to actually write the documents.