LegAI

No formal roles — four of us worked across everything. My weight went into three places: framing the product strategy, bringing VC and founder conversations from my own network, and building the local ML detection script with AI assistance. The Figma work and the report were shared.

This is a business case study. The course was about building a product argument, not running a design process, so what follows is a market bet, the evidence we gathered for and against it, the interaction decisions that came out of testing, and the reason we stopped.

A startup with 15 people ships a feature to EU users on a Tuesday. Nobody in the building is a lawyer. Somewhere in that release is a logging call that writes an email address to plaintext, or a third-party SDK quietly shipping personal data outside the EEA.

They will find out in one of two ways. An expensive external consultant tells them six months later, or a regulator does. Either way, three things follow: the release slips, the team burns weeks unpicking work it already shipped, and somewhere on the horizon sits a fine.

We did not run a survey. We used my network and went to the people who would have to pay for this, or fund the people who would.

VCs and startup founders confirmed the problem, clearly and without much prompting. Compliance genuinely competes with velocity. Developers do not want a separate compliance process bolted onto their week, they want the check where the work already happens. Every founder we spoke to had a story about a legal question that stalled a release.

What they did not confirm was that anyone would buy it. Founders agreed the pain was real, then priced it below the cost of building the thing that would fix it. That gap sat in the back of the project the whole way through, and it is the reason the last section of this page exists.

Compliance is not a product category. It is a continent. Intellectual property, cyber security, financial regulation, employment law, accessibility, and each one branches again.

• Cut one: GDPR only.Not because it is the biggest problem, but because the EU publishes the rule set. There is an authoritative, public, articulated document to build against. Every other domain would have meant inventing our own interpretation of the law, which is exactly the thing we were not qualified to do.
• Cut two: code-level GDPR only.GDPR compliance also lives in contracts, in vendor agreements, in how you answer a data subject access request. None of that is machine-checkable. What is machine-checkable: how data gets collected, where it gets logged, whether it gets hashed, how long it is retained, what leaves the building. So that became the product.
• Cut three: startups of 5 to 50 people.EU-facing, healthcare and fintech first. Small enough to have no legal function, regulated enough to care, technical enough to install a VS Code extension.

The product split into two, because the people using it wanted two completely different things.

• The extension.For the developer, in flow, inside VS Code. Detection surfaces inline, next to the offending line, with a plain-language explanation of the risk. Three actions: ignore, resolve later, assign. The design constraint here was interruption cost. Every flag is a tap on the shoulder, and a developer who is being tapped on the shoulder too often will uninstall the extension.
• The dashboard.For the manager, who is not in the code and does not want to be. Compliance status across projects, violations by severity, overrides waiting for review. Role-scoped, so a team lead sees recurring issues across sprints and a senior manager sees escalation and risk.

A regex layer for the obvious patterns. Data collection calls, logging, hashing, hard-coded secrets. Cheap, fast, and it catches the majority of real violations because most real violations are not clever.

An ML layer on top of it, RandomForest and GradientBoosting classifiers over code transformed into feature vectors, for the patterns that do not sit still. The same violation looks different across codebases, and regex is brittle in the face of a coding style it has not seen.

A reconciliation step between the two, because when a rule and a model disagree, something has to decide. This existed for exactly one reason: to hold down false positives.

Four practitioners: an ML engineer, a startup CEO, a developer, and a product manager who also writes code.

The interface was Figma. The detection was real.

Each participant ran our script locally, on their own machine, against a codebase they had written themselves. The script found real GDPR violations in their real code. Then we walked them through the designed screens and asked what they would do with what they had just been shown.

That combination is the whole reason the session produced anything useful. If the findings had been fake, we would have gotten polite feedback on a mockup. Because the findings were about their own work, we got reactions.

The script found four violations correctly. It also flagged a secure password field that was not a violation at all.

The developer who wrote that code did not think "interesting edge case." He thought the tool was wrong about him.

• Override with justification.The developer can dismiss any flag. The tool does not argue. But the dismissal requires a written reason and supporting evidence, and both go into the record.
• Maker-checker.The override lands in the manager's queue with the justification attached. The manager approves or rejects, and can leave feedback. The human overrules the machine, and accountability survives the disagreement.
• Three views, not one.The dashboard stopped being a single screen for everyone. Senior managers see risk and compliance status across all projects. Team managers monitor unresolved issues and work the override queue. Developers see their own violations, with the option to justify or escalate.

The final slide of our presentation listed what LegAI needed next. Funding. ML engineers. A full-stack developer. A legal professional. A partnership with an LLM provider. Demos with real startups to validate a proof of concept we had not yet validated.

That slide is the argument for stopping, written by us, without noticing.

Detection across arbitrary production codebases needs labelled training data at a scale we did not have and could not get. GDPR judgment you would stake a company on needs a lawyer in the room, and our roadmap said so in as many words. And the founders who agreed the problem was painful would not price it high enough to fund the thing that would fix it.

We could design the interaction honestly. We could not honestly claim the detection would hold up in production. So we made the argument, wrote it up, and left it there.