From Practicing Law in Three Countries to Building Legal Software

People occasionally ask how a practicing lawyer ends up building software for a living, as if it were a sideways move. It was not sideways. It was the same instinct, aimed at a different tool.

Where the instincts came from

I trained and practised law across India, the UAE and Singapore before I ever wrote a line of software, and that order matters more than it might seem. I learned to read a matter, the facts, the obligations, the risk, the consequence, in real courtrooms first, under real deadlines, with a real client's outcome attached to whether I got the structure of an argument right. That habit, reading a messy situation and finding the structure underneath it, did not stay in the courtroom. Every system I have shipped since is that same reading habit, pointed at a keyboard instead of a bench.

Three jurisdictions taught me something a single-country practice would not have: how differently the same underlying legal work gets organised depending on the system around it. A dispute in an Indian court, a commercial matter in the UAE, and a corporate filing in Singapore are structurally different exercises on the surface, different procedure, different documents, different pace. Underneath, they decompose the same way, into matters, actions that repeat, deadlines that do not move, people who own each step, evidence that has to hold up, and research that either compounds or evaporates. Practising across borders is what made that structure visible to me before I had a name for it.

Learning what scale actually breaks

At a certain point I moved from practising to building, joining a legal technology company and helping take it past 100,000 Indian lawyers within about a year. That stretch of scale taught me where a legal process actually breaks under volume, and it is rarely where lawyers assume. It is not the substantive legal judgement that breaks at scale, judgement holds up fine, it is the unstructured parts: intake that depends on a specific person remembering to ask the right question, a deadline that lived in someone's calendar and nowhere else, a document whose provenance nobody could trace once the file changed hands. Scale does not create new problems. It makes existing structural gaps impossible to ignore.

After that I went independent, consulting into American firms and running an AI and business venture out of Dubai. Independence changed the nature of the question I was answering. Inside a company you optimise the system you already have. As an independent consultant, every engagement started from zero, a different practice, a different jurisdiction, a different set of habits, and the only thing that carried over between them was the underlying structure I kept finding: the same six primitives wearing different clothes. Eventually I stopped consulting on other people's systems built on that structure and started building my own: MatterOS and LexOS.

Nine years, the same question, asked 200 times

For over nine years I have worked as an independent builder, starting with no-code tools for whoever needed a working system, then following the tooling forward through every generation up to agentic AI today. Roughly 200 projects, delivered for solo lawyers and large business houses alike, and every one of them was the same underlying question, asked in a different accent: what is this process actually made of? That question is the entire origin of the MATTER Method. It did not arrive as a theory I sat down to invent. It arrived as the thing I kept finding, project after project, until it had a name.

What actually carried over from the courtroom

Not the case law, most of it is jurisdiction-specific and irrelevant outside the courtroom it was argued in. What carried over is judgement about risk and consequence, the instinct to ask what happens if this step fails before building the step, and an allergy to systems that look organised on a slide but collapse the moment a real, messy matter runs through them. I have sat through enough vendor demos, on both sides of the table now, to know the difference between a system that has actually held a real case and one that has only held a sample dataset.

If there is a single honest lesson in the move from courtroom to codebase, it is that the two are less different than they look from outside either one. Both are exercises in taking something that feels chaotic to everyone in the room and finding the structure that was there the whole time. I still do that work. It just runs on different tools now.