The Day After You Buy the Software

We’ve all been there. The demo was convincing, the contract is signed and filed away, the invoices have been paid, and the new system is finally installed and running. Then you sit down to do the day’s actual work, and none of it is faster yet. Being sold on a solution and being productive with it are two different days, and every day between them costs you something.

I build and sell software to law firms, so I live on the other side of that day. What follows is the shape of that gap from my perspective, and the technology I’m using to close it.

Buying document drafting or assembly software doesn’t magically make a law firm productive.

The value of a drafting system is in its library of content and logic. The forms, the clauses, the variables, and logical rules turn a firm’s accumulated judgment into documents it can produce on demand. A drafting system with an empty library won’t move the productivity needle. And no two practices’ libraries are alike, because no two practices are alike.

That’s the problem I’m solving for the launch of RediDraft One, the intelligent document drafting product I built. A firm signs on, and then comes the gap. Building its library has historically meant sitting down with the firm’s forms and constructing templates by hand, one at a time. That takes weeks, sometimes months. Firms don’t buy software to wait weeks before it earns its keep, and I’ve seen these delays cost deals. So the goal is simple to state: get a new firm productive as quickly and easily as possible.

An engagement like this runs on momentum of effort. When a firm sees results early, that momentum builds on itself. When results drag, every quiet week gives buyer’s remorse another opportunity to take hold. And history tells me exactly what’s at stake. When a firm is productive and uses RediDraft regularly for nine to twelve months, it tends to use it for a very long time. The gap between sold and productive isn’t a scheduling problem. It’s where the long relationship is won or lost.

The good news is the raw material already exists. A firm with several years of completed estate plans has its practice encoded in the plans it has already delivered. Hand me ten to twenty recently completed plans and everything a library needs is in there: the language, the structure, what changes from client to client, and what never changes at all.

The bad news is that completed plans are saturated with client data. Names, addresses, children, assets, family situations. Confidentiality isn’t a feature request in this business; it’s the ground rule everything else stands on.

Defining the process was pretty easy, and with internal tooling built to support each step, it is not only possible, it is viable.

Strip the identity out first. Every name, address, and identifying detail gets replaced with a typed placeholder that stays consistent across the whole plan set. The person named as the testator in the will is the same placeholder in the trust, so variable relationships survive even though the client identities don’t. A deterministic scanner re-checks every output document, and a person reviews the results before anything moves forward.

Then find the variability in the language. With identity gone, the plans can be compared against each other. Language that appears in every plan is grouped into required components. Language that changes from plan to plan is grouped into optional components the drafting attorney or paralegal includes when appropriate. Analysis proposes the boundaries and the groupings, but a person confirms each of them.

Then organize the result into a library. Variables get names and roles, content gets arranged into the form volumes the firm actually drafts from, and the finished library gets packaged for RediDraft One. Reducing the timeline to days of assisted review instead of weeks of manual template work.

Using AI is a natural fit for a toolset like this. Language models are very good at recognizing names in running text and judging whether two clauses say the same thing. But where the model runs and what it is allowed to do matters a lot.

Many might think the obvious move is to send the text to a cloud AI service. But that was never on the table. The hardest identification work happens before anonymization is finished, which means raw client documents would be going to somebody else’s servers out of my control and out of the firm’s control. I took a different approach. These documents never leave our hardware. The model runs locally, on the machine of the person converting the content. It’s an off-the-shelf open model, pinned to an exact version.

And it operates under rules that don’t bend:

The model proposes; it never decides. Every suggestion it makes lands in a queue where a person confirms it, edits it, or dismisses it.

The model can add warnings; it can never remove one. The deterministic checks are the floor, and no model output can lower that floor.

The model can only quote, never compose. Any name it flags has to appear verbatim in the document, or the suggestion is thrown out. A model can’t hallucinate a finding into this pipeline, because a finding has to point at real text.

There’s no fine-tuning of the model in any of this. The model is frozen, ensuring the same input produces the same behavior, and I can record exactly which model, which version, and which prompt produced any suggestion in the audit trail.

If we aren’t tuning the model, how does the tooling get better? That’s the part I find most interesting, and it’s the part we’re building right now. The system learns, even though the model doesn’t. Every miss becomes an entry in a hand-labeled test set, and usually a new deterministic rule. Every false positive becomes a suppression the next run applies automatically. Every confirmation and dismissal from review accumulates into memory the process consults the next time through. And because the test set exists, improvement is measured, not felt. Precision and recall, this month against last month. If the numbers don’t climb, we’re doing it wrong.

Every one of those improvements is a rule or a record I can open and read. Nothing disappears into model weights where no one can inspect it.

Forty years in this business taught me that the interesting engineering is rarely the newest component. Here the model is the least trusted part of the whole process, and the design keeps it that way on purpose. The process solves the problem. Software tools make processes like this possible. That’s why I build them.