What do you need to know about GDPR when creating an app?

Building an app and staying on the right side of GDPR are the same project, and the decisions that determine whether you comply happen long before the first line of code. The lawful basis you choose, the data model you design, the third-party tools you integrate, the authentication flow you sequence, all of it carries compliance implications, and all of it is far harder to change once built.

Compliance is an architectural decision, not a legal box to tick at the end of build.

We see this tension on almost every product we work on. Teams arrive with a clear idea of what they want to build, and GDPR feels like a legal box to tick at the end. The reality is that compliance is an architectural decision. Get it right early and it costs almost nothing. Get it wrong and you are looking at rewrites, delays, and potential fines that dwarf the original build budget. The cost of non-compliance is nearly three times the cost of compliance, according to Globalscape's Data Protection Regulations Study, and that ratio is consistent with what happens when teams try to retrofit privacy into a product that was not designed with it in mind.

This article covers the key questions you need to answer before, during, and after building an app, from choosing a lawful basis to designing your data model, from handling location data to managing third-party SDKs. The goal is to give you a working understanding of what GDPR asks of an app, and what the practical implications of those requirements are for the way you build.

What GDPR actually requires of an app

GDPR sets out a small number of core principles, and every compliance obligation flows from them. Personal data must be collected for a specific, legitimate purpose. Only the data necessary for that purpose should be collected. Data must be kept accurate and stored securely. It should not be held for longer than needed. And users have rights over their own data, to access it, correct it, and in many cases delete it.

For an app, this translates into a set of concrete requirements. You need a lawful basis for every category of data you collect. You need to tell users what you are collecting, why, and what you will do with it, in plain language, before you collect it. You need to give users a way to withdraw consent, access their data, and request deletion. If you are processing sensitive data such as health information or financial records, the requirements are stricter still.

You also need to think about what happens when things go wrong. GDPR requires that data breaches are reported to the relevant supervisory authority within 72 hours of discovery, where there is a risk to users. That means your security architecture and your incident response process are both compliance concerns, not just engineering ones.

The practical implication is that GDPR touches almost every part of your product. It shapes your onboarding flow, your consent design, your data model, your security decisions, and the third-party tools you choose to integrate. None of those are purely technical decisions.

Why compliance cannot be retrofitted after build

The most expensive GDPR mistake a product team can make is treating compliance as a post-launch task. By the time an app is built, the structural decisions are already made. The data model is set, the authentication flow is in place, the third-party SDKs are integrated, and the consent mechanisms are whatever they happen to be. Changing any of those things after the fact is a rebuild.

We saw this play out directly on a dating app project we worked on, where the client chose to skip discovery for the messaging component and focus only on onboarding. The decision seemed reasonable at the time, onboarding was the complex part. But skipping discovery for messaging meant the feature was built generically, without the safeguards the product's core premise required. It allowed automated and fake messages, which directly contradicted the verified-profile approach the onboarding had established. The mismatch meant the entire messaging section had to be rewritten, costing approximately £15,000 in additional budget and around two months of extra work.

That figure is not unusual for a significant architectural correction. And GDPR-related rewrites tend to be more expensive still, because they often require changes across multiple layers of the product simultaneously, the database, the API, the front-end flows, and the legal documentation, rather than a single isolated fix.

The practical lesson is that compliance decisions belong in the design phase, not the QA phase. Every conversation about what data to collect, how to store it, and what users can do with it should happen before a database schema is written.

Lawful basis: choosing the right one before you write a line of code

GDPR requires that every piece of personal data you collect has a lawful basis. There are six options, and choosing the wrong one, or choosing one without thinking, creates problems that are difficult to undo later. The most commonly misused is consent. Consent is appropriate in specific circumstances, but it carries obligations that teams often underestimate: it must be freely given, specific, informed, and unambiguous. Users must be able to withdraw it as easily as they gave it. And if consent is withdrawn, you must stop processing that data.

For apps that do not rely on consent, a more appropriate basis is legitimate interests, where processing is necessary for a purpose the organisation has a genuine reason to pursue, balanced against the user's rights. For transactional apps, contract performance is often the right basis: processing is necessary to deliver what the user has agreed to. For apps handling health data or financial records, explicit consent or another specific basis is required.

The choice of lawful basis affects your product design in direct ways. If you rely on consent, you need a consent mechanism that meets the standard. If you rely on legitimate interests, you need a documented assessment of that balance. If you process data under contract, you need to be clear about what the contract actually covers, and what it does not.

The transparency test is useful here. If you had to tell users exactly what you were doing with their data and why, would they consider it fair? If the answer is uncertain, the basis needs more thought before the build begins, not after it.

Data minimisation: only collecting what you can justify

Data minimisation is one of GDPR's core principles, and it is also one of the most consistently ignored ones in app design. The default tendency is to collect everything that might be useful later. An analytics event for every screen. A full address when a postcode would do. A date of birth when only an age check is needed. Each individual decision feels reasonable, but the cumulative result is a product that holds far more personal data than it can justify.

This matters for two reasons. First, data you hold is data you are responsible for securing, auditing, and eventually deleting. Every extra field in your database is an ongoing obligation. Second, users notice. Six in ten users report abandoning an app installation after discovering excessive data requirements, according to eSpincorp. Asking for more than you need is not neutral, it actively reduces the number of people who will use your product.

A practical discipline here is to question every data point before it enters the schema. What is this field for? At what point in the user journey is it actually needed? Could a different, less sensitive piece of data serve the same purpose? If information can be collected at a later stage, when the user has more context and more trust in the product, it should be. Collecting it upfront because it might be useful is not a lawful basis.

Before finalising your data model, list every field you plan to collect and write one sentence explaining why you need it. If you cannot write that sentence, remove the field.

The discipline of data minimisation also makes the rest of your compliance work easier. Smaller data sets are simpler to secure, simpler to audit, and simpler to delete when users request erasure.

When anonymity and legal accountability conflict

Some app concepts create a genuine tension between two legitimate requirements: the user's right to privacy, or anonymity, and the legal need to retain data in case of criminal activity or abuse. An anonymous messaging product is the clearest example. Users expect their messages to be private and their identities to be hidden. But if a user sends harassing or threatening messages, law enforcement may need to trace those messages back to a real person.

We worked directly on an anonymous messaging app where this conflict was central to the product design. The resolution we implemented was a data retention policy of around six months. Even if a user deleted their account after sending abusive messages, the data would not be immediately wiped. If police needed to open an investigation, the data was still available. The approach did not ignore GDPR obligations, it acknowledged the right to erasure while recognising that other legal frameworks can take precedence in specific circumstances.

This kind of tension requires a documented decision, not just a technical one. The lawful basis for retaining data beyond a deletion request needs to be clearly articulated in your privacy policy and your internal records of processing activities. Vague references to "legal requirements" are not sufficient, you need to identify the specific legal obligation that overrides the erasure request.

The broader point is that anonymity as a product feature does not remove GDPR obligations. It changes how those obligations are met, and in some cases it creates additional ones.

Location data and the difference between useful and unsafe

Location data is one of the most powerful categories of personal data an app can collect, and one of the most sensitive. It can reveal where someone lives, where they work, what medical facilities they visit, and what their daily routine looks like. GDPR treats it accordingly, location data is personal data, and in many cases it qualifies as sensitive data requiring explicit consent and stronger protections.

We worked on a fitness social app where location was central to the product concept. The original design showed users' real-time locations on a map so they could connect with nearby people for shared workouts. Research revealed that a significant proportion of the user base was female, which made precise real-time location sharing a genuine safety risk rather than just a privacy inconvenience. We fundamentally redesigned the feature to introduce randomised location offsets. Users could see the approximate area where a potential workout partner was located, but not their exact position. The option to share a precise location existed, but only after users had conversed and reviewed each other's profiles, an opt-in step rather than a default.

This approach preserved the core value of the feature: enough proximity information to judge whether a meetup was feasible. But it removed the risk of exposing precise locations to strangers before any trust had been established.

If your app uses location data, define the minimum precision actually needed for the feature to work. Approximation is often sufficient, and the gap between "nearby" and "exact coordinates" is significant for user safety.

The principle is that location data should be as imprecise as the use case allows, collected only when the feature is active, and never shared without a clear user action.

Authentication, identity, and when you cannot defer login

The general principle we follow on app projects is to defer login as late as possible. Forcing users to create an account before they have experienced any value is a reliable way to lose a large proportion of them. On a gifting platform and a sports second-hand marketplace we worked on, deferring login until later in the journey consistently produced higher sign-up rates, users had already invested time in the product and had a reason to commit.

But there are cases where deferring login is not an option, and the anonymous messaging app we worked on was one of them. Because the product allowed users to send messages to each other, we needed to be able to tie every message back to a verified account on the back end, even though the messaging appeared anonymous within the product itself. This was not a product preference. It was a legal requirement, driven by the need to handle cases of abuse or harassment. Without authentication at the point of entry, there was no mechanism to identify who had sent a message if a complaint or criminal investigation required it.

The decision to require upfront authentication therefore needs to be made on legal and safety grounds, not on product instinct alone. The question to ask is whether the nature of the content users can generate, messages, reviews, financial transactions, health records, creates a legal obligation to tie that content to a verified identity from the outset.

Security architecture decisions that affect compliance

Security and compliance are often treated as separate concerns, but under GDPR they are the same concern. Article 32 requires that you implement appropriate technical measures to protect personal data. What counts as appropriate depends on the sensitivity of the data, the risks involved, and the current state of the art in security practice. That is a deliberately flexible standard, and it means security decisions made during architecture are compliance decisions whether or not they are labelled as such.

On a performance coaching survey app we built, the biggest security challenge came from a deliberate early architectural choice: we skipped a traditional API layer for the MVP, connecting the app directly to Firebase instead. That decision was sensible for the build cost and timeline. But without an API acting as a controlled intermediary between the client and the database, every security guarantee had to come from Firebase's own security rules. We had to scrutinise those rules in detail, every read and write permission, every condition, to ensure that neither the app nor the web response page could be exploited. The absence of an API layer meant there was no second line of defence if a rule was misconfigured.

The lesson is that architectural shortcuts which reduce cost or speed up delivery often shift security work elsewhere rather than removing it. Skipping an API does not remove the need for a controlled access layer, it moves that responsibility into the database rules themselves, where mistakes are harder to catch and harder to fix.

When evaluating architectural decisions for an MVP, document where each security responsibility sits. A decision to skip an API layer should include a note about what that means for database-level security rules and who is responsible for auditing them.

Consent design: when and how you ask users for data

Consent under GDPR requires more than a checkbox. It must be specific, users need to know exactly what they are consenting to, not just agree to a general privacy policy. It must be informed, the information provided must be clear enough for a user to make a real decision. And it must be freely given, consent bundled into terms of service, or required before accessing any part of the product, does not meet the standard.

The design of consent moments therefore matters in ways that go beyond aesthetics. A consent screen that buries the key information in small text, or that presents refusal as harder than acceptance, is likely non-compliant. The ICO is explicit that consent mechanisms must be as easy to decline as to accept.

One practical principle that consistently produces better results is asking permission rather than asserting requirements. The framing shift from "We need your location to show nearby users" to "Can we use your location to show you people nearby?" feels small, but it changes the psychological dynamic significantly. Users feel they have a choice, which means the consent they give is more genuine and more durable.

Timing matters too. Asking for camera access before a user has any reason to take a photo, or requesting notification permissions on the first screen of onboarding, are both patterns that generate refusals. The right moment to ask for access is when the user is about to use the feature that requires it, so the request has obvious context and the benefit is immediately visible.

The right to erasure and what it means for your data model

GDPR gives users the right to request deletion of their personal data, and that right has direct implications for how you design your database. If your data model stores user information in ways that make selective deletion difficult, fragmented across multiple tables, cached in analytics systems, embedded in logs, you have a compliance problem that only becomes apparent when a user actually makes a deletion request.

The anonymous messaging app we worked on illustrates how this works in practice. Users had the right to request deletion of their data, and we honoured that in the product. But we also had a legal obligation to retain certain data for a period in case of criminal investigation. The resolution was a defined retention period of around six months, after which data was deleted even if no deletion request had been made. This gave us a defensible position on both sides of the tension: we were not holding data indefinitely, and we were not immediately wiping data that might be needed for a legitimate legal purpose.

Building this kind of policy into your data model from the start is straightforward. Retrofitting it after launch, when data is already stored in ways that make selective or time-limited deletion complex, is significantly harder.

1. Map every location where personal data is stored, including caches, logs, and analytics systems.
2. Define a retention period for each data category and build automated deletion into the system.
3. Document any legal basis for retaining data beyond a user deletion request.
4. Test the deletion process before launch, not after the first erasure request arrives.

Third-party SDKs and the compliance risks they introduce

Third-party SDKs for analytics, advertising, crash reporting, or authentication are now standard fixtures in app development. Each of those integrations is a data processing arrangement, and under GDPR, you are responsible for the data practices of the tools you use, not just your own code. If an analytics SDK collects device identifiers and sends them to a server in the United States without adequate safeguards, that is your compliance problem, not the SDK vendor's.

The scale of this risk is routinely underestimated. According to NowSecure's Mobile App Security Research, 77% of analysed mobile apps contain personally identifiable information. A significant portion of that exposure comes from third-party libraries rather than first-party code. And only 52% of developers say they always consider security when evaluating a new third-party library, compared with 67% who consider functionality, according to Veracode's research.

The practical requirement is a Data Processing Agreement with every third party that handles personal data on your behalf. Many SDK vendors provide standard DPAs, but you need to actually read them, specifically the sections on data retention, sub-processors, and international data transfers. An SDK that routes data through a sub-processor in a country without an adequacy decision requires additional safeguards.

Before integrating any third-party SDK, check what data it collects by default and whether that collection can be configured or disabled. Many analytics tools collect more than you need, and most allow you to reduce scope through configuration.

What to document before, during, and after build

GDPR requires that organisations are able to demonstrate compliance, not just claim it. That obligation, known as the accountability principle, means documentation is evidence that you have thought through your data processing activities and made deliberate, defensible decisions. In the event of a complaint or an ICO investigation, your documentation is what separates a compliant organisation from one that got lucky.

The core document is a Record of Processing Activities. This sets out what personal data you collect, the lawful basis for each category, where it is stored, how long it is retained, and who it is shared with. It does not need to be elaborate, but it does need to be accurate and kept up to date as the product changes.

Before build

Before you write any code, you should have a clear lawful basis for every data category you plan to collect, a draft privacy notice in plain language, and a documented decision on authentication timing. If you are processing sensitive data or doing anything that carries a high privacy risk, a Data Protection Impact Assessment is required, and is good practice even when not strictly mandatory.

During and after build

During build, document any significant architectural decisions that affect compliance, particularly decisions that involve trade-offs, such as skipping an API layer or implementing a specific retention policy. After launch, your documentation needs to stay current. New features, new third-party integrations, and changes to data retention practices all require updates to your Record of Processing Activities. Compliance is a practice you maintain.

Conclusion

GDPR is a set of principles that shape how you design a product from the first design decision to the last deployment. The teams that get this right are the ones that treat data handling as a product question rather than a legal one, asking at every stage what they actually need, why they need it, and whether the way they are collecting it is something they would be comfortable explaining to a user in plain English.

The stories in this article, the dating app rewrite that cost £15,000, the anonymous messaging app's six-month retention policy, the fitness social network's location redesign, the Firebase security audit on the coaching app, are all examples of compliance decisions that had to be made one way or another. The difference between making them early and making them late is measured in budget, in time, and occasionally in whether a product launches at all.

The principles are consistent across all of them. Collect less. Ask permission. Document your reasoning. Build deletion in from the start. Choose your third-party tools carefully. And treat the lawful basis for every data category as a design constraint rather than an afterthought.

If you are building an app and want to work through these questions before they become expensive to answer, let's talk about your product.

Frequently Asked Questions