The frustration that started it
DPOkit didn't begin as a product idea. It started as a personal annoyance. After taking on a Data Protection Officer role, I quickly discovered that the software options for actually doing the job fell into three categories:
- Enterprise platforms that cost thousands per month and require dedicated implementation teams
- Generic document generators that produce templates nobody trusts and nobody maintains
- Consultant deliverables, PDF reports that are comprehensive the day they're delivered and stale six months later
None of these were built by people who had actually held the DPO role. They were built by people who had talked to DPOs, which is a fundamentally different thing. The gap between "what a DPO needs day to day" and "what legal software vendors think a DPO needs" is enormous.
What a DPO actually does
The job isn't writing privacy policies. That's maybe 10% of it. The real work is:
Keeping a living inventory of data processing activities. What data do we collect? Why? Where does it go? Who can access it? This is a database problem, not a document problem.
Assessing new projects for privacy risk. Before engineering builds something, someone needs to ask: what personal data does this involve, and is that necessary? This is a workflow problem.
Responding to data subject requests. When someone asks for their data or asks to be forgotten, there's a process. It needs to be trackable, auditable, and complete within the regulatory timeframe.
Training and awareness. Most data breaches aren't malicious. They're mistakes by people who didn't know better. The DPO is responsible for making sure people know better.
Building DPOkit
I built the first version as a plugin, a concrete, installable thing that could slot into existing workflows rather than demanding a complete platform switch. The architecture was deliberately simple:
A processing activity register that lives as structured data, not a Word document. An assessment workflow that engineers can complete in 10 minutes instead of filling out a 40-question form they'll abandon halfway through. A request tracker that makes it obvious when deadlines are approaching.
The technical challenge wasn't complex. The hard part was deciding what to leave out. Every compliance framework has edge cases and exceptions. Building software that handles every possible scenario produces an unusable product. Building software that handles the 80% that matters every single day, that's the craft.
What legal software gets wrong
The biggest pattern I noticed across every legal tech product I evaluated: they optimize for liability coverage, not usability. The goal is to produce something comprehensive enough that if something goes wrong, the vendor can say "the tool warned you about this." The result is overwhelming interfaces that nobody uses properly.
A compliance tool that sits unused is worse than no tool at all, because it creates an illusion of compliance that doesn't exist. The best compliance software is the kind that people actually use, which means it needs to be fast, clear, and embedded in workflows that already exist.
The lesson
Building DPOkit reinforced something I now believe deeply: the best domain software is built by people who have done the domain work. Not people who have interviewed practitioners. Not people who have studied the market. People who have actually been frustrated by the existing tools in their actual job.
That's not a criticism of legal tech founders. It's an observation about where good software comes from. And it's one of the reasons I'm interested in building tools myself rather than waiting for someone else to solve the problems I encounter.