GDPR-first software: what it actually means in practice

Every SaaS company based in Europe has privacy policy text that mentions GDPR. Most of them wrote it because their lawyer said they had to. That's compliance-as-checkbox, and it's very different from what we mean when we say we build GDPR-first software.

Here's the practical difference.

GDPR-first is a design constraint, not a legal task

When GDPR is treated as a legal requirement, you collect the data you want, build the features you want, and then have a lawyer review it at the end. You end up with a long privacy policy that technically discloses everything.

When GDPR is a design constraint, you ask the question before building: do we actually need this data? If yes, what's the minimum we need, and how long do we need it? Who can access it, and can we limit that automatically?

These questions change what you build. They often mean you build less.

What it looks like in our products

We collect the minimum

k-notes stores your notes, your account email, and a hashed password. That's it. No device fingerprinting, no reading patterns, no behavioral tracking.

k-tasks stores your tasks, your team memberships, and basic activity for the audit log. We don't analyze how you use the product to serve you ads, because we don't run ads.

k-cv stores your CV content, because that's the product. We don't cross-reference it with LinkedIn or sell it to recruiters. Your career data is yours.

We keep data in Europe

Our infrastructure runs on Neon Postgres with EU data residency. Vercel's edge network is used for delivery, but user-generated content stays in European databases. This matters under GDPR's data transfer restrictions.

Deletion is real

When you delete your account, your data is deleted. Not archived for 90 days "just in case." Not kept in backups indefinitely. We run a cleanup cron that removes deleted account data from backups within 30 days.

This sounds obvious. It isn't. Many companies retain data far longer than their privacy policies imply, either because deletion is hard to implement or because the data has value.

Analytics without surveillance

We use Vercel Analytics, which doesn't use cookies and doesn't track individual users across sessions. For users who consent, Google Analytics provides aggregate traffic data. We don't use pixels, retargeting, or third-party tracking.

Why this matters for businesses buying software

If you're buying SaaS tools for your business, the GDPR obligations extend to you. When you use a tool that processes personal data of your customers or employees, you become the data controller. The SaaS company is your data processor. Under GDPR, you're responsible for ensuring that processor meets the required standards.

This means the privacy practices of the tools you use are your problem too.

Some questions worth asking your current SaaS providers:

• Where is our data stored?
• How long is it retained after we cancel?
• Do you share our data with third parties? For what purposes?
• Can we get a Data Processing Agreement?

Good vendors answer these questions immediately. Evasive answers are a signal.

The business case for privacy

Privacy-respecting software isn't just ethically preferable — it's increasingly a commercial advantage. Enterprise customers in regulated industries (finance, healthcare, legal) require GDPR-compliant vendors before signing contracts. Privacy has become a procurement criterion.

It's also operationally simpler. Not collecting unnecessary data means less to protect, less risk in a breach, less to manage when someone exercises their right to deletion.

We didn't build GDPR-first software because compliance is profitable. We built it this way because it aligns with how we think software should work: you pay for a service, the service works, your data is yours.

---

If you're building a product and want to think through the privacy architecture from the start, we're happy to consult on it. Good privacy design is easier to do early than to retrofit later.