When Valeo Software, LLC closed its doors in 2004 everyone involved thought the existing FastDraft users would move to something else. They knew it wouldn’t happen overnight but were convinced it would happen. Tim Owensby put together a plan he thought would keep the existing users supported while they transitioned to another document assembly product.

But an interesting thing happened … the last release of FastDraft in late 2003 was so stable there just were many support issues to address and many users never transitioned to anything else.

Fast forward to late 2009 when a law firm in Wisconsin reached out to Tim seeking options to keep FastDraft running when Windows 7 replaced Windows XP. The last release of FastDraft would not function on Windows 7. After talking to other FastDraft users, Tim decided to update FastDraft for Windows 7 and start charging users for support. There were several problems impeding the release of an updated version of FastDraft. One was the trademark Valeo Software had for FastDraft had expired and another was someone else owned the FastDraft domain name. The new version required a web server to support the Windows desktop client application, therefore a domain name was needed. A big technical problem was the way FastDraft integrated with Word when editing a form volume was being depreciated and would not be supported in future versions of Microsoft Word. There were a host of other issues related to going from a 32 bit Windows application to the new 64 bit operating system that had to be overcome.

Tim pressed forward with the technical issues and by late spring of 2010 he had a stable version running on Windows 7 32 bit and 64 bit operating systems. But it couldn’t be released as FastDraft. After briefly exploring the costs to reacquire the FastDraft domain, Tim chose RediDraft as the new name. The thought process was this release was “temporary” and eventually the user base of FastDraft, now RediDraft, would naturally decrease to zero within five to ten years. RediDraft 1.0 was released in August of 2010. In most cases, the conversion from FastDraft to RediDraft required nothing more than an export of a FastDraft library and importing it into RediDraft. By the end of 2010 all known existing users of FastDraft had been converted.

But the user base didn’t decline as expected over time, in fact unknown FastDraft users somehow found out about RediDraft and signed up. This was without any advertising or outreach … RediDraft didn’t even have a marketing or sales web site at that time!

RediDraft has been updated several times since it’s release in August of 2010 as new versions of Windows and Word have been released. But after twelve years there are some Word related issues some users are experiencing that can’t be easily addressed in the current code base. In early 2022, it was obvious a decision had to be made. Tim had to either provide a path forward for existing RediDraft users or sunset the product once and for all. How do you sun set a product when its user base refuses to give up on it? Do you release the source to the remaining users? Do you make it an open source project and try to get someone to take up the task of maintaining it? Do you just set some date to shut down the cloud servers and notify the user base? None of these seemed acceptable.

In July 2022, Tim started researching options to solve the Word related issues and make RediDraft easier to use, manage and maintain. The upcoming 2024 RediDraft release is a complete rewrite based on this research and is expected to be generally available in the first quarter of 2024. Tim started with a blank canvas and completely re-imagined RediDraft. Keeping with the history of simple conversions to later versions, here are a few of the requirements Tim set for the next release of RediDraft.

First, it had to be secure. When RediDraft was released in 2010 Tim didn’t feel the Windows server environment in general was secure enough to offload any of the assembly process to the server. He settled on a model where the variable answers and the components selected for an answer never left the user’s PC. This made RediDraft incredibly secure. RediDraft utilized the .NET framework and used a quasi-supported library to parse, split and reassemble Word documents all on the user’s PC. The cloud server enforced user roles and acted as a repository for what was in the RediDraft libraries but the most sensitive information remained on the user’s PC and no part of it ever touched the servers.

This next release of RediDraft does not use Windows servers nor the .NET environment. The technology stack is mature, secure, scalable and reliable. How a user decides to use it is extremely flexible. The subscribers decide where they want their sensitive data to live and whatever choice they make their data is fully encrypted during transport and storage with full zero trust encryption.

During the development process penetration testing has been a continual part of the process. It would of course be foolish to claim it is impossible to hack into the servers running RediDraft 2024 but we have taken every known step to make sure it is as hard as possible to prevent it. Penetration testing will continue on a regular basis as new potential vulnerabilities are identified in the operating system, proxy servers, database servers and the application framework to make sure RediDraft remains secure, scalable, and reliable.

Second, there had to be an easy, reliable and repeatable upgrade path for the existing user’s content to move to the new version. There are several technical reasons the servers and databases cannot be upgraded in place but converting to the new version must be simple and reliable.

Third, users familiar with curating their content in RediDraft within Microsoft Word must be able to continue to use Word to create and edit their Form Volumes. Those users with complex or specific formatting needs must be able to maintain that within Word as well and have it seamlessly applied during assembly.