Product & Engineering · April 2026

There is a common pattern in how software gets built for specialized professions. A team builds a general-purpose tool — task management, document storage, communication — and then a specific industry is asked to adapt its workflow to fit the tool. It is faster to build that way. It is also, almost always, the wrong order for legal work.

We took the opposite approach with Madhav.ai. Before any interface was designed, the starting question was: what does a day of legal work actually look like, end to end? Not the idealized version — the real one, with interruptions, partial information, documents that arrive out of order, and decisions that depend on context nobody wrote down.

That exercise surfaces things a generic tool would never anticipate. A matter rarely moves in a straight line — it can stall for months and then need everything reconstructed quickly. A single document might need to be understood in the context of three different matters simultaneously. A junior associate and a senior partner need very different views of the same underlying information, without maintaining two separate systems.

Designing around these realities means some decisions look unusual compared to typical productivity software. The matter, not the document or the task, is the organizing unit. Context follows information automatically instead of requiring it to be manually attached. Permissions are built around how legal teams actually share work, not around a generic notion of "team" and "project."

None of this is about adding more features. It is about getting the underlying structure right before features are even a question. We would rather spend the time getting that structure correct now, while the platform is still young, than retrofit it later — which is, in practice, what most software built for other industries first ends up doing for law.