MaraDocs Year in Review 2025 - And What We're Planning Next

The Birth of MaraDocs

From Idea to a Completely Different Prototype

Our first drafts and plans for what would later become MaraDocs began in spring 2024.

I had this idea that these tedious, time-consuming photo and email file processing tasks needed to be automated. I was simply frustrated by the time and inconvenience that the format of digital client submissions created in our law firm through my own legal practice.

I started with rough sketches of the optimal process flow and simultaneously began exploring machine learning. I remember the inner resistance: Would I, as a non-mathematician, be able to develop my own ML models and use them in a serious product? (Yes - it was a lot of learning, but it works…)

Pretty soon the first prototype was ready: MaraMail was born. We had built a privacy-compliant email API to which you could send one of these emails in question, and MaraMail would extract all attachments, crop documents, perform text recognition, and then create clean PDFs from them. It would then send an email with the results back to the sender.

We Need Interaction!

It became clear fairly quickly that sending to an email address and waiting for a result was a rather unusual user interface for a program. And both Raui and I quickly realized that such a product (where there's nothing to see) was also nearly impossible to market.

So I had to develop a usable app. Something tangible.

Until then, I had only rudimentary experience developing user interfaces. My first frontend hobby project was a React app written in plain JavaScript (not TypeScript) that I used to control various home automation devices like lights. But I was neither a designer nor did I have any in-depth knowledge of complex web apps.

At the end of October 2024, I started writing the first lines of the now visible part of MaraDocs. It would become an incredibly exciting (learning) journey. And much more work than I could have imagined in my initial naivety.

Some Technical Details from Development...

The Stack is Set

Since I had already written an app using React, it made sense that MaraDocs would also be written in React. I liked the general model: data only flows in one direction through the component tree. You write declarative code and React takes care of re-rendering the visible UI when data updates.

React alone isn't enough for such a project. You need persistent data somewhere: Who are my customers? Who can log in? Who bought which license? Etc…

Here we decided on NextJs (with ServerActions) and Prisma ORM on a self-hosted PostgreSQL database. NextJs is the most obvious choice when using React anyway. I don't regret this decision to this day. It allowed me to iterate very quickly through various ideas and approaches and was actually relatively quick to learn.

State libraries and the power of middleware

I was already familiar from my previous hobby project with the problem of "deeply passed-down state" and knew that for a more complex project like MaraDocs, I would need to use a state library that allows me a kind of centralized data management in the frontend.

It's difficult as a complete newcomer in this area to make the right decision or selection, and at the same time this very early but necessary commitment to a technology is also very defining for the entire further course of development. After a few days of research, I decided on Redux RTK. This is certainly a controversial decision: Redux is relatively old and is often badmouthed on the internet in the relevant developer forums (Reddit, etc…).

Without going into too much detail: Redux is based on a data or process architecture where visible components depend on the state and update when it changes. The only way to change this data is through so-called dispatchers that receive or execute actions and thus change the state. (state means something like current data).

Here too, I don't regret the decision. Redux forces a certain architectural pattern on you. Data (structures) and the functions that modify them (actions) are defined in one place, and this automatically creates a certain structure in the project. You could say Redux is relatively opinionated about how you structure your code.

Additionally, the architecture of actions offers a powerful intervention point: Middleware.

Through one or more middleware levels, we can intercept dispatched actions or execute additional tasks based on them. An example: In the frontend, the user clicks "Import Image" and selects an image from their hard drive. The component in the frontend receives the image and then dispatches an addImage action containing information about the imported image. In the middleware, we intercept this action, generate a unique ID, extract the image, send it via API call to the MaraDocs API, and then forward the action with enriched information to the store.

This is where the circle closes: The visible part of the website now sees in the store that there's another image and displays it based on the data stored in the store.

This works really great.

Socket.io - when you think it needs to be fast

An early mistake was that at the beginning of MaraDocs development, we decided to communicate with the file-processing server processes via socket.io.

As a basic explanation: Normally, web pages are always requested from the browser. If you open Wikipedia, for example, your browser requests the page from Wikipedia. Not the other way around. However, this also means that Wikipedia cannot send you updates during your visit to the page. (Maybe not necessary for Wikipedia anyway...)

With MaraDocs, essentially the following happens: You or the browser upload, for example, a photo file (send it to our file-processing server) and wait for it to process the file. Intermediate results, which in turn affect the view on the website, include for example:

• Photo contains one or more documents
• the coordinates of the corner points of the contained documents
• the new image files of the cropped documents
• the PDF result with text recognition is ready
• etc...

Of course, we want these intermediate results to be sent back to the browser as quickly as possible for all uploaded files and displayed there for the user.

It therefore makes sense to use a technology suitable for this two-way communication initiation: Socket.io.

Socket.io establishes a permanent connection between browser and server and also allows the server to send its own messages (events). The program in the browser (MaraDocs) must now listen for new events on this connection and then do certain things depending on their content.

This fundamentally works well - and MaraDocs worked according to exactly this principle until November 17, 2025.

An effect I underestimated was that we had architecturally approached the so-called event driven design. This is of course an established architecture pattern in software development, but I would argue that for a classic web app, it brings more disadvantages than advantages. In particular, the "spatial" separation in code between event-sending functions and result-processing functions creates significant complexity. Advantages like type safety have to be expensively bought by using libraries like protobuf. Testing is also difficult.

We ultimately decided to say goodbye to socket.io in a major (really very major) restructuring and return to the browser-requests paradigm, where we model all previous events again as simple REST API calls, where the server delivers the result directly on the call. More on this in the next section.

MaraDocs API aka MaraDocs 2.0

To solve the problems I encountered in spring with emails and files sent by clients in my legal practice, we had to reach deep into the technical toolbox in many respects.

The scalable, secure, parallel processing of many files using various machine learning models on our own servers is in itself a technical masterpiece (respect goes to Raui Ghazaleh, my co-founder, at this point).

We realized quite early in development that the technical potential of our software goes far beyond what the MaraDocs WebApp covers.

The usable MaraDocs WebApp is designed exactly for its use case and works great at it: A user manually drags emails into the browser, sorts results into finished PDFs, and downloads them.

However, our system can do much more: Through the MaraDocs API we developed over the last 4 months (August to November 2025), it becomes possible to integrate automation (for example with n8n) or MaraDocs directly into third-party software.

We are in discussions with various companies that want to integrate partial functions of MaraDocs (for example email extractions or OCR) into their software.

We are very excited about the further development of this business branch of our company.

For us, however, it was clear that we wanted to treat the MaraDocs WebApp itself as a customer of our own API. So we completely replaced the previous processing model with socket.io with dedicated API calls and now serve exclusively our publicly available MaraDocs API with MaraDocs.

This system has been running stably in production since November 17, 2025.

And the Business?

Advotec in Berlin and RAExpo in Munich

We received an incredible amount of positive feedback in the LegalTech and legal software scene. MaraDocs was represented at the Advotec trade fair (accompanying the German Lawyers' Day) in Berlin and at the RAExpo in Munich.

The reactions of (potential) customers were particularly exciting: When demonstrating MaraDocs, it becomes apparent very early whether a law firm has a need for MaraDocs or not. For me personally, it was always incredibly fulfilling when colleagues agreed (and visibly battle-tested):

"Yes, yes, exactly, terrible, these bad photographs, everything rotated wrong and then the feet at the bottom!"

MaraDocs in the Legal Software Market

But beyond contact with numerous colleagues who provided us with valuable feedback both at trade fairs and in later customer contact, the exchange with other players in the legal software market has helped us enormously.

We were especially able to network well with the colleagues at stp.one and saw a large thematic overlap. This makes sense: From my own experience, I know that the law firm software (the case management software) is the heart of every law firm. That's the place where lawyers and staff practically "live" when they work.

In my law firm, we have been successfully using Advoware from stp.one for many years. Advoware and MaraDocs complement each other extremely well in everyday law firm life. Especially for emails where clients have embedded photos in the email or even sent images in the proprietary Apple format (.heic), MaraDocs excels and converts all of this into optimal, text-recognized, size-reduced PDFs that you can then continue working with in Advoware.

At this point: Many thanks to the colleagues at stp.one. We look forward to a successful joint year 2026 with you.

Networking in the Scene

But even beyond the noteworthy partnership with stp.one, we made valuable new contacts with many exceptional and likeable companies and entrepreneurs at the trade fairs.

Contact with the SEO and marketing specialists from OMmatic, the founders of iurApp, or the opportunity to present MaraDocs to other software companies like Actaport or industry giants RA Micro and Wolters Kluwer at the RA Expo have helped us as entrepreneurs but also as a company - and more importantly: gave us a great time at the trade fair or at the subsequent pub visit!

In any case, I'm curious to see what this will mean for MaraDocs in the coming year.

Thank you! We look forward to seeing you in 2026!

What We're Planning for the Coming Year

We achieved an incredible amount with MaraDocs in 2024 and 2025. With a lot of sweat (at least cognitively), perseverance, and staying power, we developed a wonderful software from scratch that I myself enjoy using every day in my legal practice.

We have a very long list of features we want to build in the coming year:

• Visual improvement of scan results (background removal)
• Reintroduction of MaraMail functionality with link to the MaraDocs session
• Optional Outlook plugin or MaraDocs as a native (installable) app
• Improved compression of results / more options
• PDF stamp function or PDF annotation
• and much more...

From a business perspective, we naturally want to reach and convince many more law firms of MaraDocs. We also know that the tax consulting firm market is similarly suitable and want to win more customers here.

A major topic for us is also the internationalization of MaraDocs. We already have customers in Germany, Austria, Switzerland, and Poland, but we currently don't support any language other than German. So there's still a lot to do to be successful in other European markets as well.

In any case, we look forward to the future with plenty of drive, fresh ideas, and good spirits 😀!

Thank you to everyone who accompanies us on this journey!

Martin and Raui from MaraDocs.

MaraDocs Creates Optimized PDFs from Client Documents

If you receive images instead of PDFs from clients, you no longer need to convert them manually. MaraDocs handles the complete process – fast, reliable, and without quality loss.

• Simply import entire emails
• all images are automatically analyzed and extracted
• as a result, you receive optimized PDFs

MaraDocs - as if the client had used a scanner app.

🚀 Try it now: Try MaraDocs for free

---