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 on your machine. Client data lives in your browser's own storage, on your own disk, the way a desktop application would hold it. When you ask the assistant to draft or analyse, only the specific text you approve for that one step is sent to an AI model. Nothing else. Nothing in the background.

That single decision constrained everything that came after it. It is why the privilege check runs in the browser rather than on a server. It is why there is no vendor database of your files to breach or subpoena. It is why a human sits on every consequential step, approving what leaves and reviewing what comes back — the product drafts, it never files, and it never acts on its own.

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 by solicitors, 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.
  • Browser-resident architecture — what "on your machine" means in practice, and what leaves versus what never does.
  • 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