We use cookies to improve your experience. By continuing to use this site, you agree to our Privacy Policy.
GDPR for web apps, minus the legalese. What to build and what to skip.
Georgiana Nutas
-2-1600x900.webp)
Written by
Georgiana Nutas
Building modern web applications at BluDeskSoft. We write about what we learn along the way.
We'd love to chat about your project. First consultation is always free - no strings attached.
Is Supabase good for production? An honest take on security, scaling, and cost.
If you are building a product for anyone in Europe, GDPR compliance for web apps is not a legal footnote you bolt on the week before launch. It shapes how you collect data, where you store it, how you let users leave, and what happens when something breaks. Most founders we talk to treat it as paperwork for the lawyers. Then they find out half of it is engineering work: decisions baked into the database schema and the signup flow, not a policy PDF nobody reads.
The reassuring part is that you do not need to become a data protection lawyer. You need to understand what the regulation is actually asking for and turn it into choices your team can make while building. That is what this guide is for: founders and product teams shipping web software, not a compliance department.
The General Data Protection Regulation took effect on 25 May 2018. It governs how organizations handle the personal data of people in the EU and the wider European Economic Area. The catch that surprises many founders: it does not care where your company is registered. If you process the personal data of someone in Germany or France, the rules apply to you, whether your servers are in Frankfurt or Ohio.
Two definitions do most of the work here.
Personal data is anything that can identify a person, directly or indirectly. Obvious ones are names and email addresses. Less obvious ones trip people up: IP addresses, device identifiers, cookie IDs, location data, even a user ID that maps back to a real person. If you can connect it to a human, treat it as personal data.
Then there is your role. If you decide why and how data gets processed, you are the controller. If you handle data on someone else's behalf, you are a processor. Your SaaS is usually the controller for your own users and a processor for your customers' data. Your hosting provider and analytics vendor are your processors. This matters because the responsibilities differ, and your contracts need to reflect who is responsible for what.
Founders outside Europe often assume they are off the hook. Usually they are not. Run through these:
Do you have users, customers, or leads based in the EU? Do you collect any data that could identify them, including through analytics or a contact form? Do you offer your product to people in the EU, even in English, even for free? Do you track people's behavior while they are in the EU?
A yes to any one of these means GDPR applies to that data. For most web products with an international audience, that is a yes on day one.
The regulation is built on seven principles. On paper, they read like abstract law. In practice, each one maps to a decision you make in the product.
Lawfulness, fairness, and transparency means you need a valid reason to process data, and you have to tell people what you are doing in language they can read. No dark patterns, no burying it in a 40-page policy.
Purpose limitation means you collect data for a stated reason and do not quietly reuse it for something else later. If you gathered emails for account login, you cannot start selling them to advertisers without a new basis.
Data minimization is the one developers should love. Collect only what you actually need. That optional "company size" field you added because it might be useful someday? If you are not using it, it is a liability, not an asset.
Accuracy means people can correct wrong information about themselves.
Storage limitation means you do not keep data forever. Set retention periods and delete what you no longer need. Old data you forgot about is exactly what leaks in a breach.
Integrity and confidentiality are the security principles: encryption, access controls, the basics of not leaving the door open.
Accountability is the one that bites during an audit. You have to be able to show your work, not just claim you comply. Documentation is part of the job.
Article 25 of the GDPR is the one that turns into architecture. It requires data protection by design and by default, which is a formal way of saying privacy should be built into the system, not sprinkled on after the fact. You can read the exact text on gdpr-info.eu if you want the source, and the European Data Protection Board publishes practical guidance.
In a real codebase, "by design" comes down to a handful of habits.
Collect less. Every field in your signup form is a decision you will have to defend. Default to the minimum.
Encrypt data at rest and in transit. This is table stakes now, not a premium feature.
Pseudonymize where you can. If your analytics only needs a hashed ID rather than an email, use the hash.
Lock down access. Role-based permissions so an intern cannot query the entire user table. Audit logs so you know who touched what.
Then there is "by default," which is subtler and gets missed. The most privacy-protective setting has to be the one a user gets without doing anything. Profiles private by default, not public. Marketing emails off until someone opts in, not on until they opt out. If your product ships with everything switched to maximum data collection, you have failed this part before anyone reads a line of your privacy policy.
We think about these choices early on the web applications we build, because retrofitting privacy into a live product is painful, slow, and expensive. It is much cheaper to get the schema right the first time.
GDPR gives people a set of rights over their data. For a web app, most of these are not legal abstractions. They are features you have to build.
The right of access: users can request a copy of the data you hold about them. In practice, you want an export function rather than someone manually digging through the database each time.
The right to rectification: they can fix incorrect data. Usually this is just a working account settings page.
The right to erasure, often called the right to be forgotten: they can ask you to delete their data. This is where a lot of apps fall apart, because "delete" turns out to mean a soft flag that leaves the real records intact, plus copies scattered across backups, logs, and third-party tools. A real deletion flow is harder than it looks and worth designing on purpose.
The right to data portability: users can take their data and move it elsewhere in a common format such as JSON or CSV.
The right to object: they can say no to certain processing, especially direct marketing.
One number to remember: you generally have one month to respond to these requests. For genuinely complex cases, you can extend it, but the default clock is 30 days. If handling a single request means a developer spends an afternoon writing one-off SQL, you will not scale past a handful of them. Build the tooling.
This is where enforcement actually lands for most small products. You need a lawful basis for every kind of processing, and consent is only one of six. A lot of founders reach for consent by reflex when a different basis fits better.
The contract covers the processing required to deliver the service someone signed up for. Legitimate interest can cover things like security monitoring or basic product analytics, as long as you have weighed it against the user's privacy. Consent is for the optional stuff: marketing, non-essential cookies, tracking.
When you do rely on consent, it has to be a real yes. Freely given, specific, and unambiguous. That kills a few common patterns. No pre-ticked boxes. No "by using this site you agree" as if silence were agreement. No cookie banner that only offers an "Accept All" button with the reject option hidden two menus deep. Regulators have handed out serious fines over exactly these consent tricks, and the cookie banner is the most visible place a visitor judges whether you take privacy seriously.
Third-party scripts deserve special attention. That analytics snippet, chat widget, or embedded font can set cookies and ship data to another company the moment your page loads, before the user has agreed to anything. If it fires before consent, it is a problem no matter how clean the rest of your app is.
You will eventually have a security incident. Everyone does. GDPR is less interested in whether you were perfect and more interested in how you respond.
If a breach puts people's data at risk, you generally have 72 hours to notify the relevant supervisory authority from the moment you become aware of it. If the risk to users is high, you may also need to tell the affected people directly. Three days is not long when you are also trying to figure out what happened, so you want a plan written down before you need it: who gets called, who assesses the risk, who drafts the notice. You also need to keep an internal record of breaches, including those that did not meet the notification threshold.
The fines are the part everyone quotes, and they are real. Serious violations can result in a fine of up to €20 million or 4% of global annual turnover, whichever is higher. For most startups, the bigger risk is not the maximum fine. It is the smaller enforcement actions, the legal complaints, and the reputational hit when privacy-conscious users notice you were careless.
The same gaps show up over and over, and almost none of them require a lawyer to spot:
Analytics and tracking scripts that load before consent is obtained. Over-collecting data because a form field was easy to add and nobody questioned it. No retention policy, so five years of dead accounts sit in the database. A "delete account" button that hides the account instead of removing the data. No record of processing activities, so nobody can answer basic questions during an audit. Sending EU user data to US tools without checking how that transfer is handled. Treating the privacy policy as a copy-paste template rather than a description of what the product actually does.
None of these are exotic. They result from treating privacy as an afterthought, which is exactly what Article 25 is trying to prevent.
If you are early and want a place to begin, start here. Map what personal data you collect and why. Delete the fields you cannot justify. Write down your lawful basis for each type of processing. Build export and delete flows for user data. Fix your cookie banner so reject is as easy as accept. Encrypt data at rest and in transit. Set retention periods. Draft a simple breach response plan. Keep a short record of processing activities. It is not the whole regulation, but it covers most of what a growing web product actually needs.
Yes, if you process the personal data of people who are in the EU. The regulation follows the data subject, not your company's address. A US startup with European users is on the hook in the same way as a company in Paris.
Anything that can identify a person, directly or indirectly. Names and emails are obvious. So are IP addresses, cookie identifiers, device IDs, and location data. If a piece of information can be traced back to a specific human, treat it as personal data.
Most small startups do not. A formal DPO is required mainly when your core activity involves large-scale monitoring or processing of sensitive data. If that describes you, appointing one is not optional. If you are a small team running a normal SaaS, you still need someone accountable for privacy, but not necessarily a titled DPO.
The headline figure is up to €20 million or 4% of global annual turnover, whichever is higher, for the most serious violations. Smaller infringements carry lower ceilings. In practice, the fine that hits a startup is rarely the maximum, but enforcement, complaints, and lost trust add up.
No. A cookie banner is one visible piece of a much larger picture. It handles consent for non-essential cookies, but it does nothing for data minimization, user rights, security, retention, or breach response. A good banner on top of a careless app is still a careless app.
GDPR compliance for web apps looks intimidating from the outside, mostly because it's often framed as legal work, even though much of it is product and engineering work. Collect less. Secure what you keep. Let people see, correct, and delete their own data. Ask for consent honestly. Have a plan for when something breaks. Do those, and you have covered most of what matters for a normal web product.
The cheapest time to handle any of this is before you build, not after a user files a complaint. If you are planning a new product or reworking an existing one, we build custom web applications with these decisions handled from the schema up, so privacy is part of the foundation rather than a scramble before launch. If you want a second pair of eyes on where your product stands, get in touch, and we will talk it through.
BluDeskSoft
-1-800x450.webp)