Why I Build Software Instead of Practicing Law Full Time

People sometimes assume the move from practicing law to building legal software was a retreat, that the courtroom did not work out, or that building software was simply more lucrative, so I took the easier path. Neither is true, and the actual reason is more specific and, I think, more honest than either explanation.

The work I was actually good at was not the argument

I trained and practiced across India, the UAE and Singapore, and I was a competent lawyer, but the part of the job I was genuinely good at, and genuinely drawn to, was never standing up and making the argument. It was the work before that: reading a messy, unstructured situation, facts scattered across documents and conversations and a client's half-remembered version of events, and finding the actual structure underneath it. Case theory work, not advocacy performance. That distinction matters, because it means what pulled me toward software later was not a rejection of legal work, it was a continuation of the specific part of legal work I actually cared about.

What I kept noticing, project after project

Working across three jurisdictions and then inside a legal technology company scaling toward 100,000 lawyers, I kept encountering the same pattern: the substantive legal judgment in a matter was almost never where things actually broke. Judgment held up fine, held up under pressure, held up at scale. What broke, consistently, was the unstructured scaffolding around that judgment, an intake process that depended on one person remembering to ask the right question, a deadline that lived only in someone's calendar, a document whose origin nobody could trace once a file changed hands. None of that is a legal skill problem. It is a systems problem wearing legal clothes, and I found myself more interested in fixing the systems problem than in continuing to practice inside systems I could see were broken.

Advocacy scales by adding people. Systems scale by removing the need for as many

This is the part I think is the real answer, stated plainly rather than diplomatically. A lawyer's advocacy, however good, scales linearly: one more matter needs one more lawyer's time, roughly, no matter how skilled that lawyer is. A well-built system scales differently: the same structural fix, the same action library, the same evidence-anchoring discipline, the same deadline logic, applies to the next matter and the next thousand matters without requiring proportionally more time from anyone. I found that difference genuinely more interesting to work on than the version of the job where getting better only ever means getting faster at the same linear task.

I did not stop believing in the value of a good lawyer

This is worth being direct about, because it is easy to read a legal-tech builder's story as an implicit argument that lawyers matter less than the systems around them. I do not believe that, and it is not what nine years of building has taught me. What I believe, and what the MATTER Method is actually built on, is that a good lawyer's judgment is the scarce, valuable thing, and almost everything I build exists to protect that judgment's time from being spent on work that does not require it. Supervision-first, in MatterOS's own language: you approve, it executes. That is not a system replacing a lawyer's judgment. It is a system built specifically so a lawyer's judgment is the part of the day that gets more of the day, not less.

Why I still keep one foot in practice rather than leaving it entirely

I still work directly with lawyers, still sit in the paper-first conversations that start every build, still hear, matter by matter, where a real practice's structure actually breaks. That contact is not sentimental attachment to the profession, though there is some of that too. It is functional: the moment I stop hearing directly from lawyers about where the real breakage is, the systems I build start drifting toward what looks elegant on a whiteboard instead of what actually survives a real, messy matter. Nine years and roughly 200 systems have taught me that the gap between those two things is exactly where most legal software fails, and staying close enough to real practice to feel that gap is the whole reason the builds I do ship keep working past the first six months.

The honest version of the answer

I build software instead of practicing law full time because the specific thing I was best at inside legal work, finding the structure underneath a messy situation, turned out to be a skill that compounds when applied to systems and mostly does not when applied one matter at a time to advocacy. That is not a story about law failing me or about software being a better career choice in the abstract. It is a story about matching a specific instinct to the tool where it actually multiplies, and building that match honestly enough that I still recognize the lawyer in the builder, most days, without much translation required.