Guide
GDPR for your software: what to look for before it becomes a problem
Many people reduce GDPR to "put up the cookie notice." That is the tip of the iceberg. GDPR shapes how your software collects, stores, uses and deletes personal data —and those are design decisions, not a banner you paste on at the end. This guide explains, in business language, what your system should comply with so it never turns into a nasty surprise.
By Miguel Alejandro Hayes· Founder, Hayes Projects
Beyond the cookie banner
The cookie notice is what you see, but GDPR is about the substance: collect only the data you need (minimization), have a clear legal basis to use it, store it securely, and be able to serve people’s rights —access, rectification and deletion— when they ask. If your software is not built for that, compliance becomes manual and fragile work.
The useful question is not "do I have the banner?" but "if a customer asks me to delete all their data, can my system do it cleanly?". If the answer is "we’d have to hunt for it by hand across several places," there is your risk.
What your system should do by design
Four basics: collect the minimum personal data needed; record consent verifiably where it applies; be able to export and delete a person’s data with no stray copies left behind; and know where data lives and who touches it (including the third-party providers you use). This is "privacy by design," and it is far cheaper to build in from the start than to patch later.
The "where data lives" point matters especially if you operate across countries —say Spain and the U.S.—: transferring personal data between regions has rules, and your architecture has to account for them.
How we approach it
When we build or integrate software, privacy is not a module bolted on at the end: it is decided with the architecture —what is stored, where, for how long, and how it is deleted. That way compliance stops being a race against the banner and lives in the foundations.
We are not a law firm: "what the law and your privacy policy require" is your legal advisor’s. Ours is making the software able to comply —so deleting, exporting or limiting data is a button, not an odyssey.
Frequently asked
Is GDPR just the cookie banner?
+
No. The banner is what you see; the substance is how you collect, store, use and delete personal data. Those are software design decisions, not a final add-on.
What is the most important thing my software must allow?
+
Collecting the minimum needed, recording consent where it applies, and being able to export and delete a person’s data cleanly. If that is manual work, you have risk.
Do you provide GDPR legal advice?
+
No. The legal framework is your advisor’s. We make the software comply by design: privacy from the architecture, not patched at the end.
About the author
Miguel Alejandro Hayes — Founder, Hayes Projects
Economist and essayist turned developer. He founded Hayes Projects, a Miami venture studio and custom software lab, to build software that ships, scales and solves real problems.
Meet the founder→Could your software cleanly delete all of a customer’s data today? If you are unsure, book 20 minutes and we will review it.
Book 20 min — no pitch →Prefer email?
Leave your email and we'll reach out with an idea for your case.
No obligation. No spam — just one useful, concrete reply.