Today the first law firm started working with Optimaite Law. More will follow over the next few days. That means Optimaite Law is no longer just a product we show, explain, and discuss with firms. It is in the market.

That is a meaningful moment for us. Not because anything is finished. Quite the opposite: this is where customers decide whether what we are building can hold up in real legal work.

I believe we are building the best law firm software in Germany. But that sentence is not something I get to prove in a post. It has to be decided by the firms that use it every day.

So today I want to mark the launch, but also explain the next two building blocks we are working on: Optimaite Mail and pyeda-mahn.

At first glance they look very different. One is a dedicated mail stack for law firms. The other is an open-source package for Germany's automated judicial dunning procedure.

Underneath, they answer the same question:

What kind of infrastructure does AI-native law firm software need if it is supposed to model real legal work, not just look impressive in a demo?

Why mail needs to become part of the product

In almost every conversation with law firms, the same question appeared sooner or later: what happens with our emails?

It sounds like a simple integration topic. Connect Microsoft 365. Connect Google Workspace. Read IMAP. Done.

But law firm email is not a side channel.

Email often contains half the context of a matter: attachments, follow-up questions, deadlines, forwarded information, client communication, opposing counsel, courts, insurers, experts, and internal coordination.

If you build law firm software and treat email as an external inbox on the edge of the system, you leave a large part of the firm's actual work outside the platform.

Optimaite Mail: a controlled mail stack for law firms

That is why we are building Optimaite Mail as our own mail stack in Germany.

Not as another polished email client. And not because firms need yet another tool.

Mail in a modern law firm platform has to do three things well:

provide real mailboxes, instead of only mirroring someone else's inbox
add a control layer for matter assignment, roles, approvals, auditability, and communication rules
integrate AI where the context is created: in incoming messages, attachments, replies, deadline signals, and the matter file

We will continue to support Google Workspace and Microsoft 365. Many firms use them today, and that will remain practically important.

Long term, though, I want to give law firms a sovereign alternative: mailboxes that do not just work technically, but are designed from the perspective of legal operations.

That means, for example:

incoming emails can be assigned to matters, clients, and participants
attachments are treated as potential parts of the case file, not loose files
deadlines, questions, and tasks can be detected from communication without being blindly automated
replies can be prepared with matter context
approvals, responsibilities, and audit logs remain traceable
sensitive communication can be processed according to firm rules

For AI, this matters a lot. An AI system that sees only one document remains a writing assistant. An AI system that understands the communication history, the matter, and the firm's responsibilities can start preparing real work.

But only if the control layer is right.

Sovereignty here is practical, not ideological

I like large infrastructure products. Microsoft and Google have done many things well. But law firms have specific requirements: professional secrecy, client protection, traceability, data residency, internal approvals, evidence preservation, deletion logic, and retention rules.

For me, sovereignty does not mean building everything ourselves on principle.

It means the firm has to understand and control where communication lives, who can access it, which AI can see which data, which steps happen automatically, and which steps require human approval.

If mail is the central intake channel of a law firm, it cannot remain a thin integration on the edge of the platform.

It has to become part of the platform.

pyeda-mahn: not the flashiest feature, but an important one

The second building block is less shiny, but just as important: pyeda-mahn.

pyeda-mahn is an open-source package for Germany's automated judicial dunning procedure.

It is probably not the feature that creates the most hype on LinkedIn. But this is exactly the kind of component that decides whether legal tech in Germany becomes truly productive.

A judicial dunning process is not just a form. It involves structured data, validation, jurisdiction, procedure states, court messages, sending logic, and traceable steps.

We are building pyeda-mahn so this work can be represented more cleanly in software:

prepare payment orders from structured data
model enforcement orders and follow-up steps
process court messages in a machine-readable way
validate data before sending
catch errors early
document every step clearly

The goal is not to replace legal review.

The goal is to let software do the parts software is better at: checking structure, detecting required fields, keeping data consistent, documenting status transitions, and executing repeatable processes reliably.

The human decides. The system prepares, checks, and records.

Why open source?

We could have built this only inside our platform. In the short term, that would have been easier.

But for legal infrastructure, open source is the better default.

If a package generates data for a court procedure, developers, firms, and other providers should be able to inspect what happens.

Open source creates a different discipline:

interfaces have to be documented clearly
assumptions become visible
validations can be reviewed
errors can be found together
others can build on top of it

Germany needs more of these components. Every legal tech company should not have to rebuild the same base logic for structured procedures, registries, court formats, or legal data again and again.

The larger gap: a knowledge layer for German law

The dunning procedure makes something visible that we also see in many other areas: Germany has a lot of legal structure, but it is often technically hard to access.

Procedures, databases, case law, registries, formats, jurisdictions, public information: much of it exists, but not always in a form modern software can build on cleanly.

I would like to build much more here: a reliable knowledge layer for German law, ready for AI, but not dependent on hallucinations or unchecked text.

That requires structured data, clear interfaces, and better access to case law and procedures.

Some of this can come from private companies. Some of it has to come from the justice system and public infrastructure. And some of it can be open source.

pyeda-mahn is a small, concrete step in that direction.

What this means for Optimaite Law

Optimaite Law should not become a collection of isolated features.

Our goal is a law firm platform where matters, communication, documents, deadlines, beA, billing, the client portal, AI, and workflows work from the same foundation.

Optimaite Mail and pyeda-mahn fit together for exactly that reason:

Mail brings communication context into the platform in a controlled way
pyeda-mahn brings a structured court procedure into a reliable technical form
Optimaite Law connects both with matters, roles, deadlines, documents, and AI

That is less spectacular than a chat window with a shiny prompt.

But it is closer to real law firm work.

The next step

The first firm is live. More are coming.

Now we will see which assumptions hold, where we need to sharpen the product, and which workflows matter most in daily practice.

That is the part I am most excited about. Good law firm software is not built in isolation. It is built in contact with real matters, real deadlines, real clients, and real teams.

If you want to see Optimaite Law, you can request a demo on the website. The best way to understand it is not to read a feature list. It is to see Optimaite on your own workflows.

Go hard or go home.

Optimaite Law is in the market: why we are building Mail and pyeda-mahn