GDPR Basics for App Builders: What a Small App Actually Needs

The General Data Protection Regulation (GDPR) is the European Union's data protection law; the UK has its own near-identical version. It applies to organisations anywhere in the world that offer services to people in the EU or UK and handle their personal data. If your app has sign-ups from Europe, it very likely applies to you.

That sounds intimidating. For a small app, the practical requirements are mostly common sense done deliberately. This is a plain-English overview, not legal advice — for anything high-stakes (health data, children, large scale), talk to a lawyer.

What counts as personal data

Any information relating to an identifiable person. That's broad:

Names, email addresses, phone numbers, postal addresses.
IP addresses, device identifiers, cookie IDs.
Account usernames, profile photos.
Location data, purchase history, anything users write about themselves.

Some categories are special and need much more care: health, religion, ethnicity, sexual orientation, political views, biometrics. If your app handles these, get proper advice.

The principles, in plain English

Have a good reason for collecting each piece of data, and tell people what it is.
Collect only what you need. Don't ask for a phone number you'll never use.
Use it only for what you said. Data collected for accounts isn't automatically fair game for marketing.
Keep it accurate, and let people correct it.
Don't keep it forever. Delete what you no longer need.
Keep it secure.
Be able to show you did all this.

Lawful basis: why you're allowed to process it

GDPR requires a lawful basis for each use of personal data. For a typical app, the common ones are:

Contract — you need it to provide the service the user signed up for (their email to log in, their address to ship an order).
Legitimate interests — reasonable uses people would expect, balanced against their rights (basic security logging, fraud prevention).
Consent — freely given, specific, and as easy to withdraw as to give. Typically needed for marketing emails and non-essential tracking cookies.
Legal obligation — e.g. keeping invoices for tax law.

Pre-ticked boxes aren't consent. Neither is "by using this site you agree."

The rights your users have

Users can ask you to:

Access their data — tell them what you hold and give them a copy.
Correct it.
Delete it ("the right to be forgotten"), with some exceptions, like records you're legally required to keep.
Export it in a usable format (data portability).
Object to certain uses, like marketing.

Generally you must respond within one month. For a small app, you can handle these by email. What matters is that you can — which means knowing where each user's data lives, including backups, logs, and third-party services. A "delete my account" button that really deletes (or anonymises) their data is a good investment. (Soft Deletes and Audit Logs discusses the trade-offs of keeping deleted data.)

Third-party services (processors)

Every service that handles your users' data on your behalf — hosting, database, email provider, analytics, error tracking, AI APIs — is a processor. You need:

A data processing agreement (DPA) with each. Most established providers offer a standard one, often accepted automatically in their terms.
To be aware of transfers outside the EU/UK — for example to US providers — and that the provider has a recognised transfer mechanism in place. Established providers usually document this.
To list them (at least by category) in your privacy policy.

Be thoughtful about sending personal data to AI APIs: check the provider's data usage and retention terms, and don't send more than the feature needs.

Cookies and analytics

Tracking cookies generally need consent under the separate ePrivacy rules. Strictly necessary cookies (login, cart, security) don't. Privacy-friendly analytics that don't use cookies or personal data can avoid the consent banner. (What Is a Cookie? and Analytics for Beginners.)

Data breaches

If personal data leaks — a database exposed, a laptop stolen, an API key abused — you may need to notify your data protection authority within 72 hours of becoming aware, and tell affected users if the risk to them is high. Keep a record of any breach, even small ones. The best preparation is not having one: A Security Checklist for Vibe-Coded Apps.

A practical checklist for a small app

Write down what personal data you collect, why, where it's stored, and who processes it
Collect only what you need
Publish a clear privacy policy (Does My App Need a Privacy Policy?)
Use consent for marketing emails and tracking cookies; make opting out easy
Accept DPAs from your providers
Be able to export and delete a user's data on request
Delete data you no longer need; set retention for logs and backups
Secure it: HTTPS, access controls, encrypted backups, no secrets in code
Know what you'd do in a breach

EasySpawn keeps each project's data in its own isolated workspace and managed database, with secrets in server-side environment variables — a solid base for the "keep it secure" part of your obligations. See how it works or join the waitlist.