The Long Build

What the extra time bought

RediDraft™ One took considerably longer to reach general availability than we first expected. We would rather account for that time than let it pass without comment, so this page is the accounting. Nearly all of it went into four decisions, and we would make every one of them again.

The scope grew, on purpose

What started as a new desktop application became one engine with three editions: Single User Desktop, Private Web, and SaaS Web, at one price for your whole firm, with the ability to move between them later at no cost. Then we built a native desktop client for the web editions as well, so a firm choosing a web deployment is not also choosing the browser for everyone in the office.

Each of those was an addition to the plan, and each one cost calendar time. The alternative was shipping on schedule and asking firms to live with a narrower product for years afterward. Software that some of our clients have now used for three decades does not get designed around a release date.

The foundation changed underneath the work

Partway in, it became clear that the data model we had carried forward for years was the thing limiting us. So we replaced it. The engine at the center of RediDraft™ One is entirely new, built on an entirely new data model, and beholden to no word processor.

That decision reset the schedule. It also produced the assembly engine we will be building on for the next twenty years instead of working around for the next five, and it is what made the rest of this page possible.

Getting out from under Microsoft Word

For most of this software's life, editing a Form Volume meant driving Microsoft Word from the outside and hoping it cooperated. It usually did. But every Word update, every change to how Microsoft handles macros and add-ins, every tightening of Office security arrived as our problem and, too often, as our customers' problem: library content that assembled fine last month and stopped this month after a simple edit, for reasons that had nothing to do with anyone's practice.

RediDraft™ One is word processor agnostic. It manages the Form Volume components directly and writes the finished document itself, deterministically, rather than automating someone else's application to do it, and it carries its own built-in Form Volume editor. You still open and edit the result in Word, or in whatever else you prefer. What you no longer do is depend on Word being installed, licensed, configured, and in a good mood to edit your Form Volumes and assemble your drafts.

Solving that took real time. It was also the difference between fixing one class of problem and ending it.

And out from under the Windows server

The second problem was the server. Firms running RediDraft on their own hardware have been running it on Windows Server, and keeping a Windows server both secure and fast is a genuine burden: patch cycles, an attack surface far wider than a document assembly repository needs, and performance that has to be defended rather than assumed. For a small firm without IT staff, it was the least pleasant part of owning the software, and for us it was the hardest thing to support well.

Both halves of this release address it. RediDraft™ One's Private Web and SaaS Web editions run on Linux, and the modernized RediDraft™ Classic is built to do the same. Smaller surface, better performance, and a patching story that a firm's IT provider will recognize as ordinary.

This reaches back further than the new release

The part we are proudest of: when this is fully deployed, earlier versions of RediDraft, 6.x and before, will connect to a Linux server too. A firm that never intends to move to RediDraft™ One, and is perfectly happy with the software it has been using for years, still gets out of the Windows server business.

That is the kind of thing you can only do from a new foundation, and it is a fair share of where the time went. It is also consistent with how we have always worked: nobody gets left behind because they did not upgrade on our schedule.

We would not ship it before we trusted it

The last of the time was spent deliberately. Rather than announce the new platform, we used it. It went into daily production inside FasTrac in 2024, on real client work, and early-adopter customers put it to work on their own documents soon after, including sales-contract automation well outside estate planning. Nearly two years of production use shaped RediDraft™ One before the public ever saw it.

For document assembly, that matters more than it might elsewhere. A drafting error does not announce itself in a crash log; it goes out the door inside a client's estate plan. The only honest way to find those is to run the software on real documents, for a long time, before asking anyone else to rely on it.

Where it stands

RediDraft™ Classic, modernized, arrives in August 2026. RediDraft™ One follows in October 2026. Two product lines, both supported, neither a stepping-stone to the other, and a migration path that stays as simple as it has always been: export your library, import it, keep working.

We took longer than we said we would. What we have to show for it is a document assembly engine that owes nothing to Microsoft Word, a server story that runs on Linux and reaches all the way back to RediDraft 6.x, three editions at one price, and two years of production use behind all of it.

If you are a customer and want to know what this means for your firm, your server, or your timeline, write to us. You will get an answer from someone who worked on it.