A legaltech platform for a law firm: what to automate and what to leave alone

Short answer: in a law firm what gets automated is not a funnel but a procedure. An ordinary CRM is built around a deal that a manager runs however they like; a legal process is fixed by law — the stages, the deadlines and the set of documents at each step cannot be changed. Almost everything else follows from that: a state machine instead of a kanban board, documents generated in an editable format, a separate track for money, and an audit log on every action.

Here it is piece by piece, drawing on the partner portal we built for a bankruptcy practice — a platform for running personal bankruptcy procedures, six months with a team of five.

What a legaltech platform is

A legaltech platform runs a legal case from intake to closure along a procedure fixed by law: it holds the stages and deadlines, generates documents from templates, calculates the money on the case and writes an audit log of every action. It differs from a CRM in that the order of steps is imposed from outside and the user cannot change it; it differs from a document management system in that the central entity is not a document but a case with a status.

In B2B such a platform usually solves one of three problems: running repetitive procedures at volume, running a legal department’s contracts and approvals, or running a partner network where external agents handle cases and need limited access.

Off-the-shelf products for a specific procedure barely exist, so this is usually custom development: every firm’s procedure is its own, and it is the procedure that determines the whole logic of the system.

Why an ordinary CRM does not fit

The first impulse of any law firm that has outgrown spreadsheets is to buy a mainstream CRM and configure a funnel. That works right up until three things become clear.

Stages cannot be skipped. In a CRM you can drag a deal from the first stage to the last, and that is a feature. In a bankruptcy procedure you cannot: asset realisation cannot begin before the petition has been filed. If the system allows the jump, sooner or later somebody will make it, and it will come to light in court.

A stage has a mandatory set of documents. Not “it would be useful to attach this” but “without this document the stage is not complete”. A CRM knows nothing about that — it stores files but does not check completeness.

Deadlines are external, not yours. The deadline is set by law, not by a department head. A missed deadline in sales is a lost deal; a missed deadline in a procedure is a damaged case for a client.

Then comes configuring the CRM around these requirements, and a year later every process change runs into the product’s limits. This is the standard build-or-buy fork, which we covered separately, and in legaltech it arrives earlier than in most industries.

A state machine instead of a kanban board

The right model for a legal process is an explicit state machine: a list of states, the permitted transitions between them and the condition for each. In the platform we built there are more than thirty states in a single procedure.

What that gives in practice:

• Impossible transitions simply do not exist. Not “validation blocked it”, but there is no such button in the interface. The difference matters: validation can be bypassed through the API, a non-existent transition cannot.
• Transition history is written automatically. Who moved the case to the next stage and when is not a separate logging feature but a side effect of the model.
• Progress is visible without reports. If a procedure is a position in a known sequence, answering “where are we” requires nobody’s manual work.

The main objection we hear is “what if the process changes?” It will change, and that is normal. Which is why transitions are described as data rather than smeared across handler code. Then adding a stage is a configuration change, not a refactor.

Documents: DOCX, not PDF

A non-obvious thing worth knowing before development starts: lawyers edit documents after they are generated. Always. No template covers every wording, and a lawyer is by definition a person who changes wording.

It follows that generation should produce DOCX rather than PDF. The elegant immutable PDF that demos love means, to a lawyer, retyping the document from scratch.

What else turns out to matter in generation:

• Templates change through the admin panel, with no release. A phrase in a template changes more often than a new version of the platform ships. If fixing a comma needs a deploy, the lawyers go back to their word processor.
• Template versioning. A document generated six months ago must be explicable by the template version in force then, or a disputed situation cannot be untangled.
• Substitution is verifiable. The lawyer should see where a field came from rather than trusting a black box.

Money is the most dangerous place

In a partner model, where lawyers earn commission for the clients they bring, the finance module is the main source of risk. Not technical risk but human: an error in a commission calculation turns instantly into a dispute with a partner, and a dispute with a partner turns into that partner leaving with their clients.

So the calculation of commission, deductions, instalments and penalties is fully covered by tests. This is the rare case where 100% coverage is not a fetish but a deliberate decision: the cost of an error here is out of all proportion to the cost of writing the tests.

The second rule: no calculations in the interface. If an amount is computed on the front end, sooner or later the front end and the back end will diverge, and it will be a partner who discovers it, not a developer.

What not to automate

The section usually missing from proposals.

Legal judgement. The temptation to bolt on a model that “decides whether a case is worth taking” is strong, but responsibility for that judgement lies with the lawyer and cannot be transferred to a system. The most that makes sense is highlighting formal signals: document completeness, deadlines met.

All communication with the client. The portal should absorb the routine questions — which stage the procedure has reached, which documents are ready, what is required from the client. But trying to remove the lawyer from communication entirely has the opposite effect: a client who cannot get through calls more often.

Rare scenarios. Every legal practice has procedures that occur twice a year. Automating them costs as much as automating the frequent ones and never pays back. The honest answer for those is a manual mode with the result recorded in the system.

What genuinely pays back

In our experience the largest effect comes from three things, and none of them looks impressive in a demo.

Structured communication instead of messengers. When the conversation about each client lives in its own thread inside the system and files do not get lost, the load on a supervisor falls threefold: instead of two hundred scattered messages a day, around thirty structured discussions.

Built-in partner training. A course with tests, with functionality limited until it is complete, cut onboarding for a new partner from three weeks of supervisor time to five days. The side effect mattered more than the direct one: partners who had not understood the procedure stopped entering the network.

An audit log on sensitive operations. Legal practice lives under data protection and anti-money-laundering rules, and the question “who did this and when” is not theoretical. Soft delete belongs in the design too: in a legal system nothing should disappear without trace — not a document, not a record, not a user.

Time and budget

Rough figures for a platform of this class: discovery and a process map in two to four weeks, an MVP with one key role in two to three months, the full system with documents, payments and training from six months. Ours took six months with a team of five.

The sensible way to shorten that is not by cutting stages but by sequencing: first the portal for the role that delivers the most, then the others. Trying to ship every role at once is the most reliable way to double the project.

In short

Legaltech differs from ordinary B2B automation in that the process is not yours: the law sets it, and the system is what adapts. Hence a state machine instead of a flexible funnel, DOCX instead of PDF, full test coverage of financial calculations, and an audit log as a mandatory rather than optional element.

If you have a legal practice that has outgrown spreadsheets and messengers, look at legaltech platform development and the case study, which sets out how the partner portal is put together.