Updated 29 September 2026. The decision below still stands; how it is built has changed. Matters were first held in the browser's own storage. They now live in an encrypted vault your firm controls, and on managed plans AI requests pass through our AI service on their way to the provider, without being stored.

We are solicitors' people building for solicitors. This is the first entry in a build log about how the product was made, module by module: the decisions behind it, not the sales pitch. We are starting here because everything else in the product follows from one choice we made in the first week.

The question we could not get past

When you evaluate an AI tool for legal work, one question sits underneath every other: when I put this matter into the box, where does the file actually go?

Most tools answer it the same way. The document leaves your machine. It is uploaded to a server you do not run, processed there, and often kept there. The moment you click send, your control over a privileged communication ends and someone else's terms begin.

We could not build on that. Not as a feature to bolt on later: as a foundation. A tool that requires a privileged file to leave your machine has already made the decision that matters, and made it wrongly.

The opposite decision

So we drew the line the other way, on the first line of the design. The matter stays under your control. Today the case file lives in an encrypted vault your firm controls, on your own computer, or on a server your firm runs, not in a database of ours. When you ask the assistant to draft or analyse, only the text needed for that one step is sent to an AI model. Uploading a document also sends its text, for an automatic summary after the privilege check. Reading and editing send nothing.

That single decision constrained everything that came after it. It is why the privilege check runs before AI egress. It is why there is no vendor database of your files to breach or subpoena. On the attended registry path, consequential registered drafting, filing and signing skills pause for human review; direct and unregistered paths are outside that guarantee.

Built for the work, not dressed up as legal

There is a version of a legal AI that is a general tool with a legal skin: a chatbot with the word "solicitor" painted on it. That is not what this is. The templates are written for England and Wales from the first keystroke, not translated from somewhere else. The compliance output is anchored to SRA expectations and UK GDPR, not a generic privacy notice bent to fit. The privilege gate understands legal professional privilege as a duty, not as a setting.

That through-line, built for solicitors, not a generic tool with a legal skin, is the reason the whole thing exists. We will keep returning to it.

Where this series goes

Over the next entries we will walk through the parts as they were built:

  • The privilege gate: the check that runs before anything reaches an AI, and where it hard-blocks rather than warns.
  • Where your matters live: the encrypted vault in practice, and what leaves it for an AI step.
  • The engagement letter drafter: our first module, and why it had to know the jurisdiction.
  • Client onboarding: day-one onboarding that produces the compliance pack, not another checklist.

You can also bring your own AI key, so your contract for the model is with the provider and your usage is billed to you directly. More on that later in the series.

The short version: we started with the client's file because that is where a careful firm's duty starts. Everything else is downstream of getting that right.

← All posts