Freshly Arrived - MaraDocs Demo Mode and Software Architecture

We used the Easter weekend to develop and release a demo mode for MaraDocs.

The MaraDocs blog is a mix of announcement platform for MaraDocs-related events and a place to put legal and tech-related thoughts on paper.

We are incredibly proud...

Raui and I have worked intensively on MaraDocs over the past year. After several months of preparatory work on my part, we spent a solid 8 months in pure product development. Always with our goal in sight: To create the document processing solution for law firms that would free us all from the pain of increasingly poor quality incoming mail.

We worked with a few partner law firms (shout out to RA Bafteh from BSvH!) to ensure we weren't developing past the end user. And we received a lot of very useful tips: For example, the document preview was developed largely based on feedback from an early user (family law attorney from Freiburg, thank you very much :)) and the feedback from the secretarial staff at Kurtz & Lynen law firm (https://kanzlei-kurtz.net).

...and yet there's still work to do

A good product alone doesn't make a successful product. MaraDocs is top-notch and is used and loved daily by those who use it for their daily work. But those who don't use it yet usually aren't aware of it yet.

In an attention-overloaded world, it's not easy to get the attention of potential customers.

The potential customer's journey is long:

• There's something out there...

• I'll try it out...

• I actually go to the website...

• I register with my email address...

• I click on the login link I received by email...

• I open the app and add email attachments to optimize and realize the product is brilliant.

Shortcuts into the app

With demo mode, we can drastically reduce the journey and offer potential customers an uncomplicated, early, and genuine experience of trying out MaraDocs. MaraDocs is fun: The clean UI and moving and combining pages into new PDFs has something playful about it.

At the same time, demo mode costs us nothing. For background, you need to know that uploading real files and email attachments incurs costs in our infrastructure. We need to maintain certain resources to be able to process user jobs quickly and responsively. A demo mode that would send real files to our servers and didn't even require registration could easily lead to our servers being overloaded by a multitude of requests and our actual customers suffering as a result.

Technical implementation

We use React / NextJs in the frontend. The React app running in the browser communicates in normal mode with our file processing servers via WebSocket (WebSocket is a bidirectional connection where the server can also independently send results to the browser without the browser polling).

It was important to me to develop demo mode in such a way that it always reflects the current development status of MaraDocs and doesn't represent a new, separate system that would need to be developed independently.

Redux Middleware

A large part of the app's internal workflow logic is controlled by Redux middlewares. Ultimately, you can think of the app as a huge state machine where different events trigger predefined workflows and change the internal data representation.

An event could be clicking a button (e.g., rotate this PDF page) or inserting a file into the app or even a WebSocket message from the server with the results of an optimized PDF.

I decided to implement the asynchronous parts of the actions following these events—such as sending data to the server via WebSocket, but also some of the extensive PDF processing we do in the browser—in middleware logic. This middleware(s) listens for and reacts to certain events and then executes logic.

Hot-Swapping Middlewares

In demo mode, our normal app is started. However, when registering the various middlewares, the one that normally handles WebSocket communication is replaced with a demo middleware that displays simulated (pre-prepared) results with a small delay for corresponding events.

These files therefore don't need to be analyzed and optimized by our servers each time, but only once. After that, they can be loaded repeatedly from our static cache and in this way cause virtually no costs.

General thoughts on Redux

Redux is a particular way of managing state in JavaScript apps. It's based on the idea that only so-called actions, which must be executed in a specific way, are allowed to change the state data present in the app. React, for example, can use this to ensure that visible parts of the app respond to state changes.

The Redux library that made this software model popular, at least in the frontend world (Redux), is sometimes considered overly complex and is being displaced in many newer projects by more lightweight alternatives. However, we carefully weighed its use for ourselves. In particular, the powerful middleware structure has allowed us to bring an app as complex as MaraDocs into the browser.

The demo mode and the easy handling of turning it on and off by replacing a single "module" (the middleware) confirms for me that we bet on the right horse here.

Conclusion

I'm particularly pleased about colleagues from the legal profession who share my passion for digitalization and software development.

Today's article was a bit more technical. But that's how it is sometimes: You start out innocuously and then dive a bit deeper into the topics after all.

Feedback / Questions very welcome via LinkedIn or by email to info@maradocs.io.