GDPR for Indie SaaS: The Realistic Minimum for Solo Founders

Photo by FlyD on Unsplash

If you run an indie SaaS and a single person in the EU or UK can sign up, GDPR applies to you — even if you're a solo founder in Ohio who has never set foot in Europe. The good news: the realistic minimum for a small SaaS is a short list. Document a lawful basis for the data you collect, publish an honest privacy notice, be able to export and delete a user's data on request, sign data processing agreements with your vendors, and know how to report a breach within 72 hours. You don't need a Data Protection Officer, a compliance consultant, or a five-figure budget to hit that bar.

TL;DR

• GDPR follows the user, not your company's location — if EU/UK residents can use your product, you're in scope (per Article 3), even if the product is free.
• For a typical SaaS, "contract" covers account and billing data; you only need explicit consent for things like marketing email and non-essential cookies.
• You must honor data subject rights — access, deletion, portability, rectification — and building an export/delete button now is cheaper than doing it by hand later.
• Sign a DPA with every vendor that touches user data (Supabase, Stripe, Vercel, Resend). Most have one you can accept in a few clicks.
• The realistic solo-founder minimum is roughly eight tasks, not a compliance program. Skip the fear-marketing.

I'll say this once up front: I'm a founder, not a lawyer, and this is not legal advice. It's the working understanding I use to run Coding Capybaras, sourced from the primary regulators rather than from compliance vendors trying to sell you a $5,000 audit. When your data processing gets complex — health data, kids under 16, large-scale profiling — talk to an actual privacy lawyer. For a normal indie SaaS collecting emails and card details, read on.

Does GDPR even apply to your SaaS?

Almost certainly yes. The instinct for a US-based solo founder is "I'm not in Europe, so European law can't reach me." That instinct is wrong, and it's the single most expensive misunderstanding in indie SaaS compliance.

Article 3 of the GDPR sets the territorial scope, and it's deliberately broad. The regulation applies to you if you offer goods or services to people who are in the EU — and, in the exact words of the text, this holds "irrespective of whether a payment of the data subject is required." A free tier counts. It also applies if you monitor the behavior of people in the EU, which is what most analytics and session-recording tools do by default.

The European Data Protection Board's guidelines on territorial scope make the trigger concrete: it's about targeting. Pricing shown in euros, a language selector with EU languages, shipping or serving EU customers, running ads that reach them — any of those signal you're offering services into the Union. Simply being accessible from Europe is a grayer area, but the moment you take money from or actively market to EU users, you're squarely in scope. The UK runs its own near-identical "UK GDPR" after Brexit, enforced by the Information Commissioner's Office, so the same logic covers British users too.

Here's the decision most founders can make in thirty seconds:

flowchart TD
  A[Can someone in the EU or UK sign up<br/>or use your product?] -->|No| B[GDPR does not apply.<br/>Revisit if you ever expand.]
  A -->|Yes| C[Do you collect any personal data?<br/>email, name, IP, card, usage]
  C -->|No, truly none| B
  C -->|Yes| D[GDPR applies.<br/>Work the realistic minimum below.]
  D --> E[Free tier?<br/>Still applies — payment is irrelevant.]

Most SaaS products collect an email at minimum, so the honest answer for nearly everyone reading this is: it applies. That's not cause for panic. It's cause for a checklist.

The six lawful bases (and the one you'll actually use)

Under GDPR, every piece of personal data you process needs a documented "lawful basis" — a legal reason you're allowed to have it. There are six, and the ICO's getting-started guide walks a small business through choosing one. You do not need a different lawyer-drafted justification for each field. You need to think about it once, write it down, and be consistent.

The six bases are: consent, contract, legal obligation, vital interests, public task, and legitimate interests. For a typical indie SaaS, you'll lean almost entirely on two of them — contract and consent — with an occasional appearance from legitimate interests and legal obligation.

The mistake I see most often is founders assuming they need consent for everything. They don't, and over-relying on consent actually creates problems, because consent must be freely given and revocable. If you make someone "consent" to you storing the email they signed up with, they could withdraw it and you'd be obligated to delete the account they're paying for. That data is better justified under contract: you need the email to provide the service they asked for.

Here's how the common data a SaaS collects maps to a lawful basis:

| Data you collect | Typical lawful basis | Do you need explicit consent? | | --- | --- | --- | | Account email, name, password hash | Contract | No — needed to deliver the service | | Billing details, invoices, tax records | Contract + legal obligation | No — required to bill and to keep tax records | | Product usage / feature analytics (first-party) | Legitimate interests | No, if privacy-friendly and documented | | Marketing emails / newsletters | Consent | Yes — opt-in, with easy unsubscribe | | Non-essential cookies & tracking pixels | Consent | Yes — via a cookie banner, before they fire | | Support tickets and correspondence | Contract / legitimate interests | No |

The practical takeaway: your core product data rides on contract, your growth machinery rides on consent. Get that split right and 90% of the "what's my lawful basis" question is answered. Keep a one-page internal note recording which basis covers what — that note is your accountability documentation, and it takes an hour to write.

If you're wiring up billing and wondering where tax records fit, the "legal obligation" basis is why you're allowed to keep invoice data even after someone asks to be forgotten. I go deeper on the billing side in the Stripe Tax guide for indie SaaS and on the money mechanics in subscription billing math.

The data subject rights you have to honor

GDPR gives every person a set of rights over their data, and your job as a controller is to be able to act on them without a fire drill. The rights that matter for a normal SaaS are access, rectification, erasure, portability, restriction, and objection. In plain terms: people can ask to see their data, correct it, delete it, get a copy in a portable format, pause your processing of it, or object to specific uses like marketing.

The two you'll actually receive are access (a "subject access request," or SAR) and erasure (the "right to be forgotten"). The ICO's guidance is blunt that you should build a process for these before the first request lands, because handling them ad hoc eats your week. A compliant deletion generally has to purge or anonymize the person's data across all your systems, and the expected turnaround is one month.

This is where a little engineering up front saves you enormous pain. If you build a self-service "export my data" and "delete my account" flow, you turn a manual, deadline-driven legal obligation into a button the user clicks themselves. It's the rare compliance task that's also a genuinely good product feature — and it ties directly into how you design your cancel and offboarding flow. Do the deletion honestly there and you've satisfied erasure as a side effect.

There's an architecture angle too. Deleting a user cleanly is only easy if your data model makes it easy — if every table that references a user is keyed consistently and you're not scattering personal data into logs and third-party tools you've forgotten about. Row-level isolation helps you scope "everything belonging to this user," which is one more reason I lean on Supabase Row Level Security from day one. The founders who dread deletion requests are usually the ones who copied personal data into six places and can't remember where.

A caution on the SAR specifically: you're allowed to verify identity before handing over someone's data, and you should. "Send me all your data on user X" is also how a bad actor tries to harvest someone else's account. Confirm the requester controls the account first.

DPAs, sub-processors, and the paperwork nobody enjoys

Here's the part that sounds scary and is actually mostly clicking "accept." When you use a vendor that processes your users' personal data on your behalf — your database host, your payment processor, your email sender — GDPR treats you as the "data controller" and them as a "data processor." Article 28 requires a contract between you called a Data Processing Agreement (DPA) that spells out what they can do with the data, their security obligations, and their breach-notification duties.

You are not drafting these from scratch. Every serious infrastructure vendor publishes a standard DPA, and for most you accept it in your account settings or it's baked into their terms. The stack this site runs on is a good reference point:

| Vendor | Role in your SaaS | DPA availability | | --- | --- | --- | | Supabase | Database, auth, storage | Standard DPA, available to accept | | Stripe | Payments, billing | DPA included in their services agreement | | Vercel | Hosting, edge network | Standard DPA available | | Resend | Transactional & lifecycle email | DPA available on request/settings |

Your real work is threefold, and none of it requires a lawyer. First, keep a list of every vendor that touches user data — these are your sub-processors. Second, actually accept each vendor's DPA rather than assuming it's automatic. Third, disclose the list. A short "sub-processors" section in your privacy policy or a linked page saying "we use Supabase, Stripe, Vercel, and Resend to operate the service" is what transparency looks like in practice.

Two things trip founders up here. One is analytics and support tools you added casually — a session recorder, a chat widget, an email marketing platform. Each of those is a sub-processor too, and each needs a DPA. The other is international transfers: because these vendors may store data in the US, your DPA should reference the appropriate transfer mechanism (Standard Contractual Clauses or the EU-US Data Privacy Framework). The major providers handle this in their DPA language, which is exactly why using boring, well-lawyered infrastructure beats rolling your own. If you're evaluating which tools to bolt on, that's part of why I keep integration choices centralized in the Coding Capybaras marketplace — fewer surprise sub-processors, more vendors that already ship a real DPA.

Breaches, records, and the realistic solo-founder minimum

Two obligations round out the picture, and both are lighter for a small operation than the headlines suggest.

The first is breach notification. If personal data you're responsible for is lost, exposed, or stolen and it poses a risk to people, you may have to report it to your supervisory authority within 72 hours of becoming aware. Seventy-two hours is not much time to figure out a process from cold, so the move is to decide now what you'd do: how you'd detect it, who you'd tell, and what you'd say to affected users. Pair this with a broader incident habit and your support process — the same muscles you use for founder-led customer support are the ones you'll need when you have to email users bad news calmly and quickly.

The second is records of processing. Article 30 technically exempts organizations with fewer than 250 employees — but the exemption evaporates if your processing isn't "occasional," and running a SaaS is the definition of non-occasional. So assume you should keep a basic record: what data you hold, why, on what lawful basis, who you share it with, and how long you keep it. That's the one-page note I mentioned earlier, expanded slightly. It is a document, not a project.

Put together, here's the realistic minimum for a normal indie SaaS. Not the maximal enterprise program — the actual floor:

1. Confirm scope (if EU/UK users can sign up, you're in).
2. Write down your lawful basis for each category of data.
3. Publish an honest, specific privacy notice — the ICO even has a free generator that produces one in under 15 minutes.
4. Add a cookie banner only if you use non-essential cookies, and make it fire tracking after consent.
5. Build (or plan) self-service data export and account deletion.
6. Accept a DPA with every vendor that touches user data, and list them.
7. Write a short breach-response plan and a records-of-processing note.
8. In the UK, check whether you owe the ICO the annual data protection fee — for most businesses it's £52 a year.

The fines everyone quotes — up to €20 million or 4% of global turnover under Article 83 — are real, but they're aimed at large-scale, willful violations, not a solo founder who published a privacy policy and honored a deletion request. Regulators have signaled that their 2026 focus is transparency and clear privacy information, which is precisely the cheap, honest stuff on this list. Do the eight things. Skip the panic.

Frequently asked questions

Do I need GDPR compliance if my SaaS is free?

Yes. Article 3 is explicit that the regulation applies to offering services to people in the EU "irrespective of whether a payment is required." Free products that collect emails, run analytics, or set tracking cookies are in scope exactly like paid ones. The absence of a transaction changes nothing about your data obligations.

Do I need a Data Protection Officer as a solo founder?

Almost certainly not. A DPO is mandatory only for public authorities or organizations whose core activity is large-scale monitoring or large-scale processing of special-category data. A typical indie SaaS collecting account and billing data doesn't meet that bar. You still own the responsibilities yourself — you just don't need a formal appointed officer.

What's the difference between a data controller and a data processor?

You're the controller: you decide what personal data gets collected and why. Vendors like Supabase or Stripe are processors: they handle that data on your instructions. The distinction matters because controllers carry the primary obligations to users, and controller-processor relationships require a DPA under Article 28. In some flows you can also be a processor for your own customers' data — check your specific case.

How fast do I have to respond to a deletion or data request?

Generally within one calendar month of receiving the request, and a data breach that poses risk to people must be reported to your supervisory authority within 72 hours. Building self-service export and delete features is the easiest way to stay inside the one-month window without it dominating your schedule.

Is a privacy policy generator good enough, or do I need a lawyer?

For a straightforward SaaS, a good generator (the ICO's is free and reputable) gets you a solid, honest baseline. The catch is that a generator only describes what you tell it, so you must customize it to your actual data, vendors, and retention periods. Pay a lawyer when your processing is genuinely risky — health data, minors, large-scale profiling — or when a customer contract demands it.

Does GDPR apply if I only have US customers today?

If you truly have zero EU/UK users and don't market to them, the practical exposure is low right now. But the moment your signup form is open to the world, one EU visitor can bring you into scope. Since the realistic minimum is cheap to implement early and painful to retrofit late, most founders should just build to the standard from the start.

The honest bottom line

GDPR for an indie SaaS is not the compliance monster the consulting industry sells. It's a short, mostly one-time list: know you're in scope, document your lawful basis, publish an honest privacy notice, honor data rights, sign your DPAs, and be ready for a breach. Do it early, wire the export-and-delete flow into your product, and it stops being scary and becomes just another part of running a real business. The founders who suffer are the ones who ignored it until an enterprise buyer's security questionnaire — or a regulator's letter — forced a scramble.

If you're building a SaaS with AI coding tools and want the boring infrastructure decisions already made for you, Coding Capybaras is the free boilerplate I built for exactly this workflow — the stack ships with well-lawyered vendors and a data model that makes honest deletion easy, so the compliance floor above is mostly already under your feet.