Engineering

Software for legal workflows, not lawyers for software

Domain design · LegalTech · UX architecture

Problem

Most legal software asks firms to reorganize around generic CRM concepts — leads, pipelines, opportunities — that do not match how IP desks think. Practitioners compensate with spreadsheets and memory. Adoption fails not because lawyers resist technology, but because the abstraction fights the domain.

Context

Nepalese IP firms organize around client companies, physical and digital files, matters tied to specific assets, and statutory clocks that do not forgive missed renewals. Department of Industry status, bulletin updates, and litigation hearings each attach to different parts of that hierarchy. Software that collapses this into flat “records” creates daily friction.

Constraints

Statutory clocks do not forgive UX experiments. Confidential portfolios require role boundaries. Training time is scarce — screens must match mental models staff already have.

Architecture

company → file → matter → asset. API and database share desk nouns. Register search links into matter context. Litigation sits beside IP assets, not in a disconnected module.

Implementation

Mapped the physical desk before screens. Built deadlines and documents at the hierarchy level practitioners use when explaining a case. UI language: marks, classes, renewals, DoI status — not SaaS marketing terms.

Result

Firms including Global Law Associates and Janak Bhandari & Associates use NepalIPMS for daily operations — the place renewals and matters live, not a parallel system.

What I Learned

Mirror the desk. Domain-shaped products compound in value; generic CRMs compound in workarounds.

← All essays