The GDPR fear usually shows up as two pictures in your head. One is a letter with a regulator’s logo on it. The other is quieter: someone emails and asks you to delete everything you hold about them, and you realise you have no idea where it all is.
The reassuring part is that most of what GDPR asks of a small app is checkable by you, in an afternoon, with a browser and a bit of patience. I’m an engineer, not a lawyer, so treat this as a practical starting point rather than legal advice. But the common gaps in an AI-built app are technical, and technical things can be looked at.
1. Have a clear reason to collect the data
GDPR calls this a lawful basis. In plain terms, you need a reason to collect each piece of personal data, and for most things a small app does, the honest reason is either “I need this to provide the service they asked for” or “they agreed to it”.
The place this bites is consent for tracking. If your app sets analytics or marketing cookies, the visitor has to agree before those cookies are set. A banner that appears while the tracking already runs behind it’s decoration, not consent. The cookies are set on load, the banner is cosmetic, and clicking “accept” changes nothing because it already happened.
To check it:
- Open your site in a private or incognito window.
- Open devtools (
F12or right-click, Inspect), go to theApplicationtab (in Firefox it isStorage). - Look at
CookiesandLocal Storagebefore you touch the banner.
If you see analytics cookies (anything starting _ga, a _fbp from Facebook, and similar) sitting there before you have clicked anything, the banner isn’t doing its job. Non-essential cookies should only appear after a visitor agrees.
2. Hold less data
This is the cheapest privacy improvement there is, and AI-built apps tend to need it. A generated signup form often collects phone number, date of birth, company, job title, none of which the app uses. Every field you store is something you now have to protect, disclose and be able to delete.
Go through your forms and your database and ask, for each field, whether the app does anything with it. If nothing reads it, stop collecting it and delete what you already have. Less data means less risk and fewer obligations. It’s the one item on this list that makes every other item smaller.
3. Encrypt data in transit, and don’t store sensitive fields in the clear
Two separate things live here.
- In transit. Every page and every API call should be over
HTTPS, notHTTP. Most hosting gives you this by default now, so the check is quick: load your site, look for the padlock, and make sure typing thehttp://version redirects you tohttps://. If any form posts to a plainhttp://address, that data crosses the network readable by anyone in the middle. - At rest. Sensitive fields shouldn’t sit in your database as plain readable text. Passwords in particular must be hashed, never stored as the actual password. If you can open your database table and read a column of real passwords, that needs fixing before launch. The same care applies to anything genuinely sensitive you hold.
4. Know where the data goes (this is the big one)
Your app almost certainly sends personal data to other companies. Each one is a processor you’re responsible for and, in most cases, have to name in your privacy policy. The usual suspects are your analytics tool, your email provider (the service that sends password resets and receipts), and your payment provider.
For an AI-built app there’s one more, and it’s the one founders miss. If your app calls an AI API, an OpenAI, Anthropic or similar endpoint, then whatever the user typed is being sent to that provider. A support chat, a document someone uploaded for summarising, the text of their profile: if it passes through a prompt, it leaves your servers. That has real GDPR weight. It’s a data transfer to a third party, often in another country, and it’s personal data you’re handing over. Most founders building with these tools never quite register that their own app is forwarding user content to an outside provider.
To check it: open the network tab in devtools, use your app the way a user would, and watch which outside domains your app talks to. Every third-party domain that receives personal data is something you need to know about and, usually, disclose.
5. Make the privacy policy match reality
A privacy policy is a description of what your app does with data. The failure mode with a generated one is that it describes some other app. It lists tools you have never used and stays silent on the AI API you call every day. A policy that’s wrong in this direction is worse than a short honest one, because it’s now a written claim that doesn’t match your behaviour.
Once you have done the exercise in section 4 and you know every place data goes, the policy writes itself. Name the processors you use. Say what you collect and why. Mention the AI provider if you use one. Accuracy matters more than length here.
6. Be able to find, export and delete a person’s data
People have the right to ask what you hold about them, to get a copy, and to have it deleted. You don’t need a polished self-service portal for a small app. You do need to be able to answer when the request lands.
The practical test is to pick a real user and try it yourself. Can you find everything tied to that person? Their row in the database, yes, but also their entries in related tables, anything in your email tool, anything sitting in logs. Can you export it in a readable form, and can you delete it without breaking the app? This is easy to leave until the first request arrives, and awkward to build under time pressure once it has. Doing the dry run now tells you whether the data is tidy enough to act on.
Where to start
You don’t have to do all six before you launch. If you fix two things first, fix these:
- The cookie banner. Make sure non-essential cookies are genuinely blocked until a visitor agrees, using the private-window check in section 1. This is the most visible gap and the easiest to verify.
- Where data goes. Write down every outside service your app sends personal data to, and treat the AI API as the one most likely to be missing from your list. Everything else, the policy, the disclosures, the deletion process, follows from having that map.
The rest is worth doing properly, and it’s the kind of methodical work that’s easier with someone who has done it before sitting next to you. If you want a second pair of eyes on the whole thing, this is exactly what I look at, and it fits inside the full launch checklist. Tell me what you’ve built and I’ll help you work out what needs fixing first.
