If you are a solo developer or a two-person studio shipping an app or a marketing site that any European user can reach, the General Data Protection Regulation (GDPR) almost certainly applies to you. It does not care that you are small. It does not care that you are based in the US, Turkey, or anywhere else. What it cares about is whether you process the personal data of people in the EU or EEA — and if you have a signup form, analytics, or a contact email, you probably do.
The good news: GDPR readiness for a lean indie product is mostly a short list of concrete, checkable things. This page is that list. Each item is something you can act on this week, and most of them map to a public-surface signal you can scan for in seconds. This is a readiness checklist, not legal advice — it helps you find gaps before a reviewer, a user, or a data-protection authority does.
How to use this checklist
Work top to bottom. For each item, decide whether it applies to your product, then either tick it off or note it as a gap. Several items end with a LaunchTrust detector you can run against your own public page — those detectors report a signal (detected / not detected / unable to determine), not a pass-or-fail grade. A signal tells you whether the thing a reviewer would look for is actually present on the page you scanned; it does not certify that your setup is legally sufficient.
The checklist
1. Know what personal data you actually handle
Before anything else, write down every piece of personal data your app touches: email addresses, names, device identifiers, IP addresses, location, in-app behavior, support messages. Under GDPR, "personal data" is broad — an IP address or an advertising ID can count. You cannot apply the rest of this list until you know your own data map.
- I have a written, current list of every category of personal data I collect, where it lives, and who it goes to.
2. Apply data minimisation
GDPR expects you to collect only what you need for a stated purpose, and to keep it only as long as you need it. For an indie app this is also a cost and risk reducer: data you never collected cannot leak, and cannot show up in a subject access request.
- Every field I collect maps to a real purpose. I have removed "nice to have" fields, set retention limits, and turned off SDK data collection I do not use.
3. Identify a lawful basis for each purpose
Every processing activity needs a lawful basis — most commonly consent, contract (you need the data to deliver the service the user asked for), or legitimate interests. You do not need a lawyer to start: write one line per purpose naming its basis. Note that consent has a high bar (freely given, specific, informed, unambiguous) and is usually the wrong basis for things you can justify another way, such as running the core feature a user signed up for.
- I can state a lawful basis for each processing purpose, and I am not leaning on "consent" where contract or legitimate interests genuinely fit.
4. Publish a clear, reachable privacy policy
Transparency is the backbone of GDPR. A privacy policy that explains what you collect, why, your lawful bases, who you share data with, how long you keep it, and how users exercise their rights is the standard way to meet it — and Apple and Google expect one too. The policy must be reachable, not buried.
- My app and site link to a privacy policy that describes data, purposes, third parties, retention, and user rights, in plain language.
Scan for it: the privacy policy detector reports whether a privacy-policy link or wording is present on the page you point it at.
5. Get cookie and tracker consent right
If your website or webview sets non-essential cookies or loads analytics and marketing scripts, the ePrivacy rules generally require prior, informed consent before those load — and GDPR sets the standard for what valid consent looks like. Strictly necessary cookies (auth, cart, CSRF) are exempt; analytics and ad pixels are not. The classic gap regulators flag is trackers firing with no banner, or a banner where "reject" is harder than "accept."
- Non-essential cookies and trackers do not fire until the user opts in, "reject" is as easy as "accept," and choices can be changed later.
Scan for it: the cookie consent banner detector reports whether a recognizable consent banner or CMP is present.
6. Audit your third-party trackers and processors
Every analytics tool, crash reporter, ad SDK, and hosted backend is a third party that may receive personal data. Under GDPR these are usually processors, and you are generally expected to have a data processing agreement with each, to know where they send data, and to disclose them. A single dropped-in pixel can put EU/UK transfer rules in play.
- I have inventoried every third-party SDK and service, confirmed a processing agreement is in place, and disclosed them in my privacy policy.
Scan for it: the third-party tracker detector lists common tracking and analytics signatures found in your page HTML.
7. Offer account and data deletion (right to erasure)
GDPR gives users a right to erasure, and Google Play increasingly expects apps that support account creation to also offer account deletion — including a deletion path reachable from a public web URL, not only inside the app. A missing deletion route is one of the most common reasons an indie submission stalls.
- Users can delete their account and associated data, and the deletion route is reachable from a public page, not hidden behind a login.
Scan for it: the account & data deletion detector reports whether a deletion route is referenced on your public surface.
8. Support the other data subject rights
Beyond deletion, GDPR gives users rights to access, rectification, portability, restriction, and objection. You do not need a full self-service portal on day one, but you do need a real, monitored way for someone to ask — and a plan to respond within the expected timeframe.
- My privacy policy explains how users exercise their rights, and there is a working, monitored contact channel that actually reaches me.
9. Respect automated privacy signals
Some browsers send signals such as Global Privacy Control (GPC) that express an opt-out of sale or sharing of personal data. Honoring recognized signals is increasingly treated as part of doing consent properly, and it is a low-effort, high-trust thing for a small team to get right.
- I am aware of automated opt-out signals and have a plan to honor recognized ones where they apply to my product.
Learn more: the Global Privacy Control detector explains the signal and how it is surfaced.
10. Secure the data you keep
GDPR requires "appropriate technical and organisational measures." For an indie app the basics carry most of the weight: serve everything over HTTPS, do not leak API keys or .env files into your frontend bundle, keep dependencies patched, and limit who can see production data. A breach caused by an exposed secret is both a security failure and a GDPR one.
- Transport is encrypted end to end, no secrets or config files are exposed publicly, and access to personal data is limited and logged.
11. Plan for breaches before one happens
GDPR expects you to detect, document, and — where required — report certain personal-data breaches to your supervisory authority, often within a tight window, and to affected users when the risk is high. A one-page internal runbook (who finds out, who decides, who notifies) is enough to start.
- I have a short, written breach-response plan and know which supervisory authority I would contact.
12. Know whether you need an EU representative or DPO
If you are established outside the EU but offer goods or services to, or monitor, people in the EU, you may need to appoint an EU representative. A Data Protection Officer is required only in specific cases (large-scale or sensitive processing). Most tiny indie apps will not need a DPO, but you should confirm rather than assume.
- I have checked whether an EU representative or DPO requirement applies to my situation, instead of guessing.
A concrete example
When the privacy-policy and deletion signals are wired correctly, the markup a scanner keys on looks ordinary — a normal footer link is enough:
<a href="/legal/privacy">Privacy Policy</a>
<a href="/account/delete">Delete your account</a>The opposite failure mode is just as ordinary: the words "Privacy Policy" sitting in the footer as plain text with no link, or a deletion flow that only exists three taps deep inside the logged-in app with no public URL. Both read as "not detected" from the outside — which is exactly how a reviewer or a curious user would experience them.
Check this in 30 seconds
Run your homepage or landing page through the free LaunchTrust scanner. In one pass it reports the public-surface signals behind items 4 through 9 of this checklist — privacy-policy link, cookie consent banner, third-party trackers, and a reachable deletion route — so you can see which boxes you can genuinely tick before you point real EU traffic at the product. It reads the same public HTML your visitors get; no login, no crawl of private pages. Pair it with the European Union jurisdiction overview for the wider regional picture.
FAQ
Does completing this checklist make my app GDPR-ready? It moves you a long way toward it, but it cannot guarantee the outcome. This is a readiness checklist and the scanner reports signals — detected, not detected, or unable to determine — to help you find gaps before launch. It does not certify the result, render a verdict, or substitute for legal advice. Whether you meet GDPR depends on facts a public scan cannot see, like your backend processing and contracts. Use this to prepare, then confirm specifics with a qualified professional.
I'm a solo dev based outside the EU. Does GDPR really apply to me? Often, yes. GDPR can apply when you offer goods or services to, or monitor the behavior of, people in the EU or EEA — regardless of where you are located. If EU users can sign up, buy, or be tracked, assume it is in scope until you have confirmed otherwise.
My app collects almost no data. Do I still need most of this? Probably more than you would expect. Even an email signup, an analytics SDK, or server logs that capture IP addresses involve personal data. The lighter your data footprint, the shorter your work — but a reachable privacy policy and a way to honor user rights are commonly expected even for minimal apps.
Which items can LaunchTrust actually check for me? The public-surface ones: privacy policy presence (detector), cookie consent banner (detector), third-party trackers (detector), and an account/data deletion route (detector). Items like lawful basis, processing agreements, and breach planning are internal — the checklist flags them, but no scan can confirm them.
Compliance aid, not legal advice. LaunchTrust reports signals, not a verdict or certification.