GDPR for Web Apps: The Compliance Work That Actually Matters

GDPR has a reputation problem among developers. It sounds like a legal document that will eat a month of work, so teams either ignore it or buy a banner script and consider it handled. The reality is closer to the middle: a lot of it is legal work you can't fake, and a meaningful chunk of it is engineering work with a clear checklist. This is the engineering side.

The regulation applies if you have users in the EU, regardless of where your servers sit. If that's you, here's what the work actually breaks down into.

Inventory before anything else

You can't protect data you haven't listed. The first pass is a plain document: every place personal data enters the system, where it's stored, how long it's kept, and who else receives it. For a typical SaaS this includes the obvious stuff (accounts, orders) and the stuff people forget: error logs with stack traces containing email addresses, analytics events, email provider archives, backups.

That inventory decides everything downstream. Most "GDPR failures" are really inventory failures: a processor was never listed, or data was kept in a table nobody remembered.

If you run analytics, marketing pixels, or anything beyond strictly necessary cookies, you need consent before those load, and the bar is higher than most implementations reach:

Nothing non-essential loads before the user answers. No tracking scripts slipped in under the banner.
Rejecting is as easy as accepting. A "reject all" button with equal weight, not a gray link under a giant "Accept".
The user can change their mind later. A link to cookie or privacy settings in the footer, not a one-way door.
Consent records exist: who consented, to what, when, under which banner version.

The good news for us: this is where cookieless analytics earns its keep. Aggregate, cookieless tools with no personal identifiers fall outside the consent requirement entirely, which deletes a whole category of work. We run WebSpectra on our own projects for this reason.

Build data subject requests into the app

GDPR gives users the right to access their data, correct it, export it, and have it deleted. In a SaaS, these arrive as emails unless you build something better, and answering by hand doesn't scale and doesn't prove anything.

What we implement:

Export: a self-service download (JSON or CSV) of everything tied to the account. In practice this is one query per table keyed on the user ID, which is trivial if you planned for it and painful if your user data is smeared across tables without consistent foreign keys.
Erasure: delete or anonymize the account's data. Some records can't be fully deleted (invoice rows with legal retention requirements, for instance), so the pattern is anonymize the personal fields, keep the accounting record, and be able to say exactly what was kept and why.
A deadline you can meet: the regulation gives a month. If fulfillment is manual, a month goes fast.

The audit trail matters as much as the feature. When a user (or a regulator) asks what happened to a deletion request, "the developer ran a SQL statement" is a weak answer.

Processors, retention, and backups

Every third party that touches personal data is a "processor" and needs a data processing agreement: hosting, email delivery, error tracking, payment providers, support tools. Most major providers have DPAs you can sign from their dashboard in ten minutes. The work is making the list complete and keeping it that way.

Retention is where developers have real leverage. DELETE is a legitimate feature: logs older than 90 days, analytics events past their useful life, accounts of users who churned two years ago. Scheduled cleanup jobs are cheap, they shrink your backup surface, and they shrink your blast radius.

Backups are the part everyone forgets. A deletion request fulfilled in the production database is not fulfilled if the user still exists in nightly backups. That doesn't mean restoring backups to purge one row; it means documented backup retention (say, 30 days) in your privacy policy, so "we delete on request, backups age out within X days" is an honest, compliant statement.

The split between legal and code

A privacy policy and DPAs need someone who knows the law; we don't write those, and neither should you fake them with a template you found. But the engineering half, the data inventory, the consent gate, the export and delete features, retention jobs, and honest backup policy, is normal product work with clear requirements. Most teams can ship it in days when it's planned, and that's the right way to think about it: not a legal tax, just a set of product features any serious SaaS ends up needing anyway.

We build GDPR-aware Laravel and Vue applications at SrcTeam, from consent tooling to self-service data exports. If you need compliance work priced and planned, get in touch.