When I started building Atmos Football, privacy and GDPR were not top of mind. It was a simple tool for my own 5-a-side group. Then it grew. It reached the Play Store. It started collecting analytics and showing ads. And suddenly I had users in the EU.

The short version: if your app has users in Europe, GDPR applies — even if you're a solo developer in another country. "It's just a hobby app" isn't a defence. The good news is that the obligations are proportionate. A small app with minimal data doesn't need the same infrastructure as a big tech product. This post shares what I actually did, what I learned, and the practical steps that worked for Atmos Football.

1. Does GDPR Apply to a Hobby App?

Yes — if you have users in the EU or UK, GDPR applies regardless of where you (the developer) are based.

For a Play Store app that can be downloaded anywhere in Europe, that means compliance is required. The same goes for a web app that people in the EU can access.

The obligations scale with risk and data volume. Atmos Football collects relatively little personal data, so the requirements are manageable. But ignoring them entirely risks Play Store rejection, AdSense disapproval, or (in theory) regulatory trouble.

I take it seriously for three reasons:

  • Respect for users who trust the app with their football data.
  • Platform requirements (Play Store and AdSense both expect a privacy policy and proper consent mechanisms).
  • Avoiding future headaches if the app keeps growing.

There is also a simpler reason. The people in the app are not users in the abstract — they are the same twelve people you play football with on Thursday. The data belongs to people you know. That changes the question from "what am I legally required to do" to "what would I be comfortable doing with data that belongs to my friends." The legal requirements and the honest answer turn out to be roughly the same.

2. What Data This App Collects (and Doesn't)

Transparency starts with knowing exactly what you hold.

What we collect:

  • Firebase Auth: Email address, display name, and UID for signed-in users.
  • Firestore: Game results (including player names as entered by the organiser), group membership, weekly sign-up responses (cleared each week), and basic payment status flags (visible only to organisers).
  • GA4 Analytics: Anonymised usage data (page views, feature usage) — only when consent is granted. Firebase UID is attached for signed-in users to enable better grouping, but only after consent.
  • AdMob (Android): Google Advertising ID for personalised ads — again, only with consent.
  • Fitness data (optional): Summary metrics stored in Firebase (in the EU region). Raw high-resolution GPS, heart rate, and velocity data stay on-device only (IndexedDB) and are never sent to servers unless the user explicitly syncs summaries.

What we deliberately don't collect:

  • Photos, full location history, payment card details, bank account numbers, chat messages, or any special-category data beyond optional fitness tracking.

Player names in game records are personal data under GDPR. This creates an interesting edge case for deletion requests (covered below).

Everything is minimised. If I don't need it, it isn't stored.

3. The Cookie Consent Banner

Google requires explicit consent for analytics and advertising cookies in the EU. We handle this with a simple, binary consent banner rather than a full Consent Management Platform.

The banner:

  • Appears only when needed (not on every page load for returning users).
  • Stores the choice as 'granted' or 'denied' in localStorage (atmos_consent).
  • On page load, GA4 defaults to 'denied' (set in index.html). The banner re-applies 'granted' for returning users within GA4's consent window.
  • On Android, the same banner calls updateAdMobConsent() so one decision covers both GA4 and AdMob.
  • Dispatches a custom event (atmos_consent_changed) so other parts of the app (e.g. ad banner logic) can react.

Users can reset their preference at any time via a link on the Privacy page.

For a small app, this simple yes/no approach is proportionate. It's not as sophisticated as a big CMP, but it meets the requirements without over-engineering.

4. The Right to Erasure — The Interesting Edge Case

GDPR Article 17 gives users the right to have their personal data deleted ("right to be forgotten").

In Atmos Football this has two distinct paths:

Match record erasure (shared data):

Game results are shared records. Deleting one player's name would corrupt the stats, Elo history, and chemistry data for everyone else in that game.

The solution is anonymisation rather than deletion. The player's name is replaced across all affected games with a neutral identifier like "Removed Player #1". The match result, scores, and data for remaining players stay intact. Associated data (sign-up responses, active player list entries) is also cleared.

The distinction matters beyond the technical. Deletion treats the individual as the unit of concern. Anonymisation treats the shared record as the unit of concern — it honours the individual's right while preserving what others built together. Most privacy decisions in a collaborative app have this shape: the individual right and the collective record are both real, and the solution has to hold both.

This is handled manually after the user emails Atmos.football@gmail.com. We aim to acknowledge within 72 hours and complete within 30 days.

Player account erasure (self-serve):

Signed-in users can delete their own account via My Account → Delete account. This permanently removes:

  • Email, display name, and Firebase Auth account
  • Subscribed groups, push tokens, player identity links
  • All synced fitness summary data

Note: Deleting an account does not affect match records the user previously entered as organiser. Those require the separate anonymisation process.

This dual approach balances user rights with the reality that football stats are inherently collaborative.

5. The Privacy Policy

Every app needs one. The Play Store and AdSense both require a clear privacy policy.

Ours is bundled into the app at build time and shown in the dedicated Privacy tab. It's also linked from the Play Store listing and standalone pages.

The policy covers:

  • What data is collected and why
  • Lawful basis for each type (legitimate interest for core match data, explicit consent for analytics/advertising and health data)
  • Retention periods (match results indefinitely for historical integrity, sign-up responses cleared weekly, analytics 14 months, fitness data deleted on account deletion)
  • How to request erasure or exercise other rights
  • Who we share data with (essentially only Firebase/Google for hosting and analytics)

I started with a generator as a template, then customised it heavily to match our actual practices. The most important rule: be accurate. A policy that doesn't reflect reality is worse than a simple, honest one.

6. Special-Category Data — Fitness Tracking

Adding optional fitness tracking (heart rate, GPS routes, sleep, etc.) moves us into Article 9 territory — special-category (health) data, which requires explicit consent and stricter handling.

Our approach:

  • Explicit opt-in in account settings, separate from general consent.
  • Raw high-resolution data stays on-device only (IndexedDB).
  • Only summary metrics are optionally synced to a private per-user Firebase subcollection in the EU region.

This on-device-first split was a deliberate privacy-by-design choice, not just an engineering one.

The Bottom Line for Indie Developers

GDPR compliance for a small hobby app doesn't require a legal team. It requires three practical things:

  1. Don't collect what you don't genuinely need.
  2. Be transparent and honest about what you do collect.
  3. Provide clear ways for users to delete their data.

The 80/20 rule applies: a clear privacy policy, a simple consent mechanism, and workable deletion paths cover most obligations. Add proper analytics/ad consent if you use GA4 or AdMob, and handle health data with extra care if you go there.

You don't need to be perfect. You need to be thoughtful and proportionate. The apps that get this wrong are usually the ones that collected everything first and thought about why later. The apps that get it right started with the question rather than the data.

If you're building something similar, start by listing exactly what data your app touches. Then ask: "Would I be comfortable explaining this to a user who cares about privacy?"

That mindset has served Atmos Football well.

You can read the full policy in the app's Privacy tab or try the Launch Demo (no account required for basic use).

For the full story of how the app came to be, see How We Built Atmos Football.

— James