What registering for data protection taught me about building real products
I assumed that if I collected almost no personal data, the legal obligations would mostly not apply. That assumption was wrong, and finding out why changed how I build.
My first instinct about personal data was, I thought, a responsible one: collect as little as possible, keep what you must on the user’s own device, and the legal weight of the whole area mostly lifts. It is a nice theory. It is also the wrong shape, and understanding why took me longer than it should have.
The theory is not wrong about risk. It is wrong about accountability. Minimising data genuinely reduces what can go wrong — fewer records, smaller blast radius, less to lose. But whether an obligation applies to you is a separate question from how much data you hold, and answering the first question with a good answer to the second is a category error.
Where the reasoning broke
The design I was proud of is real and still stands. In ITISYOU Tools, the PDF and image tools do their work inside your browser. Your file is not uploaded, so there is no copy on a server, no retention window to define and no deletion process to get wrong. That is a genuinely better design than the alternative, and I would build it the same way again.
The error was extrapolating from it. I reasoned roughly like this: the tools barely touch personal data, therefore the network barely touches personal data, therefore the obligations are minimal, therefore I can defer thinking about them. Each step is a slightly bigger leap than the last, and the last one is not a conclusion at all — it is a decision to stop looking.
What broke it was ATSYou. A CV is not incidental personal data. It is a dense record of someone’s employment history, education, and often enough their location and contact details, handed over deliberately and processed by automated means. No amount of local-first design elsewhere in the network changes what that one product does.
What I actually did
I stopped trying to reason my way to an answer and went and found out what applied. The outcome was straightforward once I stopped avoiding it: the registration process applied, I completed it, and I paid the data protection fee. That was recorded on 21 August 2026.
I want to be precise about what that does and does not mean, because this is exactly the kind of thing that gets overstated on a website:
- It means I am registered and the fee is paid. That is a legal requirement met, not an achievement.
- It does not make ITISYOU “fully compliant”, and I do not use that phrase anywhere. Compliance is ongoing work across notices, retention, rights handling and security, and it is not something a payment settles.
- There is no certificate to display and no badge to earn. Registration is an entry in a public register, not a mark of quality.
- I hold no registration number in my own project records, so this site publishes no number. If that seems like an odd omission, it is a deliberate one — I would rather say nothing than print a figure I cannot verify from a source I hold.
What changed in how I build
The useful part was not the registration. It was what the process forced me to articulate, which was a set of questions I had been carrying around unanswered:
What do I actually collect, per product, in writing? Not “not much”. A list. Writing it down for each product separately turned up two places where I was collecting something because a framework default did, not because I had chosen to.
Which of that is essential and which is optional? This distinction now drives real behaviour rather than policy text. Space asks before it measures anything and the measurement stays off until you allow it. This main site collects no analytics at all, which is why it has no cookie banner — a banner with nothing to consent to is theatre, and I would rather not perform it.
What happens when someone asks for their data back, or asks me to delete it? Before, I would have improvised. Having to describe the route in advance meant designing one.
Am I holding this because I need it, or because I might? This one keeps coming up. “Might be useful later” is the most expensive reason to keep personal data, and it is almost always the real reason.
The part that transfers
The lesson generalises beyond data protection, and it is the reason this is filed as a build lesson rather than a legal note.
A technical solution can reduce a risk enormously and still not answer the question of who is responsible when it goes wrong. Encryption does not remove the duty to handle a breach. Processing on-device does not remove the duty to tell people what you do. Refusing to invent a claim — which is the core of how ATSYou works — does not remove my responsibility for what the product produces.
Engineering can shrink a problem until it is nearly invisible. It cannot make the problem someone else’s. That is the whole lesson, and I would rather have learned it from a registration form than from an incident.
The privacy notice for this site describes what this site alone does, which is very little. Each product publishes its own, because they genuinely differ, and copying one across would be the same category error in a new outfit.