Turning legal expertise into a software product

Legal products fail on scope and on liability, in that order. The version that works is usually narrow enough to be about one document or one deadline, and honest about being a tool rather than advice.

The instinct is to build the thing that replaces the work. The products that succeed usually replace the admin around the work, which is less interesting and far more sellable.

What you already know that a developer does not

You know which parts of a matter are genuinely judgement and which are a checklist somebody is doing badly from memory. Nobody outside the profession can tell those apart, and the checklist part is where a product lives.

You also know the deadlines, the sequences and the consequences of missing them, which is a real product on its own.

Why these builds stall

Two ways. Scope, because a matter has infinite variation and every exception looks essential from the inside. And liability, because the moment a tool appears to give advice, the risk changes shape and the questions get harder.

The stall usually shows up as a build that keeps growing to cover the next unusual case, which is a product that never ships.

What to build first

One document or one deadline. The letter you send weekly, the checklist you keep in your head, the sequence that goes wrong when someone is on leave.

It should be obviously a tool rather than advice, and it should say so plainly. That constraint makes the product smaller, which is the point.

What to leave out

• Matter management. That category is crowded and the incumbents handle a decade of edge cases you have not met.
• Anything that generates final advice rather than a draft a professional reviews.
• Multi-jurisdiction in version one. One jurisdiction, done properly.
• Client portals, until the core tool is being used weekly.