MaraDocs Jahresrückblick 2025 - Und was wir noch vorhaben

Die Geburt von MaraDocs

Von der Idee zu einem gänzlich anderen Prototypen

Unsere ersten Entwürfe und Pläne zu dem, was später einmal MaraDocs werden sollte, begannen im Frühjahr 2024.

Ich hatte diese Idee, dass man diese lästigen, zeitraubenden Foto- und E-Mail-Dateibearbeitungen automatisieren müsse. Ich war aus meiner eigenen anwaltlichen Tätigkeit einfach von dem Zeitaufwand und der Umständlichkeit genervt, die das Format der digitalen Mandantenzusendungen bei uns in der Kanzlei erzeugt hat.

Ich fing mit groben Skizzen zum optimalen Prozessablauf an und begann parallel, mich mit Maschine-Learning zu beschäftigen. Dabei erinnere ich mich an den inneren Widerstand: Würde ich als Nicht-Mathematiker dazu in der Lage sein, eigene ML-Models zu entwickeln und diese in einem ernsthaften Produkt einsetzen können? (Ja - war viel Lernarbeit, aber es geht…)

Relativ bald stand der erste Prototyp: MaraMail war geboren. Wir hatten eine datenschutzkonforme E-Mail-API gebaut, an die man eine dieser hier gegenständlichen E-Mails senden konnte, und MaraMail würde alle Anhänge extrahieren, Dokumente ausschneiden, Texterkennung ausführen und dann saubere PDFs daraus erstellen. Im Anschluss sendete es dann eine E-Mail mit den Ergebnissen an den Einsender zurück.

Wir brauchen Interaktion!

Es war relativ schnell klar, dass der Versand an eine E-Mail-Adresse und das Warten auf ein Ergebnis eine relativ ungewöhnliche Benutzerschnittstelle zu einem Programm ist. Und sowohl Raui als auch ich merkten recht schnell, dass ein solches Produkt (bei dem es nichts zu sehen gibt) sich auch kaum vermarkten ließ.

Ich musste also eine bedienbare App entwickeln. Etwas zum Anfassen.

Bisher hatte ich nur rudimentäre Erfahrungen mit der Entwicklung von user interfaces gemacht. Mein erstes Frontend-Hobby-Projekt war eine in plain JavaScript (also kein TypeScript) geschriebene React-App, mit der ich verschiedene Home-Automation-Geräte wie z.B. Lichter steuern konnte. Aber ich war weder ein Designer noch hatte ich wirklich vertiefte Kenntnisse über komplexe WebApps.

Ende Oktober 2024 fing ich an, die ersten Zeilen des heute sichtbaren Teils von MaraDocs zu schreiben. Es sollte eine unglaublich spannende (Lern-)Reise werden. Und viel mehr Arbeit, als ich mir in meiner anfänglichen Naivität hätte vorstellen können.

Ein paar technische Details aus der Entwicklung...

Der Stack steht

Da ich zumindest schon einmal eine App mit Hilfe von React geschrieben hatte, lag es nahe, dass MaraDocs ebenfalls in React geschrieben werden würde. Ich mochte das allgemeine Modell: Daten fließen immer nur in eine Richtung des component tree. Man schreibt deklarativen Code und React kümmert sich darum, die sichtbare UI bei Updates der Daten zu re-rendern.

React alleine reicht bei so einem Projekt nicht. Man braucht irgendwo persistente Daten: Wer sind meine Kunden? Wer kann sich einloggen? Wer hat welche Lizenz gekauft? Etc…

Hier haben wir uns für NextJs (mit ServerActions) und Prisma ORM auf einer selbstgehosteten PostgreSQL Datenbank entschieden. NextJs ist ohnehin die naheliegendste Wahl, wenn man React verwendet. Ich bereue diesen Schritt bis heute nicht. Er erlaubte mir das sehr schnelle Iterieren der verschiedenen Ideen und Ansätze und war tatsächlich relativ schnell zu lernen.

State libraries and the power of middleware

Ich kannte schon aus meinem Vorgänger-Hobby-Projekt die Problematik von „tief durchgereichtem State“ und wusste, dass ich für ein komplexeres Projekt wie MaraDocs auf eine state library zurückgreifen musste, die mir eine Art zentrales Datenmanagement im Frontend erlaubt.

Es ist schwierig, als absoluter Neuling auf diesem Gebiet die richtige Entscheidung bzw. Auswahl zu treffen und gleichzeitig ist diese sehr frühe, aber notwendige Festlegung auf eine Technologie auch sehr bestimmend für den gesamten weiteren Verlauf der Entwicklung. Ich habe mich nach einigen Tagen der Recherche für Redux RTK entschieden. Dies ist sicherlich eine umstrittene Entscheidung: Redux ist relativ alt und wird im Internet in den einschlägigen Entwicklerforen (Reddit usw…) häufig schlecht geredet.

Ohne zu sehr ins Detail zu gehen: Redux basiert auf einer Daten- bzw. Prozessarchitektur, bei der sichtbare Komponenten vom state abhängen und sich bei Änderungen updaten. Der einzige Weg, diese Daten zu ändern, funktioniert über sog. dispatcher, die actions entgegen nehmen bzw. ausführen und damit den state verändern. (state bedeutet soviel wie aktuelle Daten).

Auch hier bereue ich die Entscheidung nicht. Redux zwingt einem ein gewisses architektonisches Pattern auf. Daten(-strukturen) und die sie verändernden Funktionen (actions) werden an einem Ort definiert und auf diese Weise ergibt sich automatisch eine gewisse Struktur im Projekt. Man könnte sagen, Redux ist relativ opinionated was die Strukturierung des eigenen Codes angeht.

Darüber hinaus bietet die Architektur der actions eine mächtige Eingriffsmöglichkeit: Middleware.

Über eine oder mehrere middleware level können wir in abgesendete actions eingreifen bzw. von diesen ausgehend weitere Aufgaben ausführen. Ein Beispiel: Im Frontend klickt der User auf „Bild importieren“ und wählt ein Bild von seiner Festplatte aus. Der component im Frontend nimmt das Bild entgegen und schickt (dispatch) daraufhin eine addImage action, die Informationen zum importierten Bild enthält. In der middleware fangen wir diese action ab, generieren eine einmalige ID, extrahieren das Bild und senden es per api call an die MaraDocs API und leiten dann die action mit angereicherten Informationen an den store weiter.

Hier schließt sich der Kreis: Der sichtbare Teil der Webseite sieht jetzt im store, dass es ein weiteres Bild gibt, und stellt dieses auf Basis der im store gespeicherten Daten dar.

Das funktioniert wirklich großartig.

Socket.io - wenn man denkt, dass es schnell gehen muss

Eine frühe Fehlentscheidung war, dass wir uns bei Beginn der Entwicklung von MaraDocs dazu entschieden hatten, mit den dateiverarbeitenden Serverprozessen per socket.io zu kommunizieren.

Als kleine Basiserklärung: Normalerweise werden Webseiten immer vom Browser aus angefragt. Öffnen Sie beispielsweise Wikipedia, dann fragt ihr Browser die Seite von Wikipedia an. Nicht umgekehrt. Das bedeutet allerdings auch, dass Wikipedia Ihnen während Ihres Besuches auf der Seite keine Updates schicken kann. (Ist bei Wikipedia vielleicht auch nicht notwendig...)

Bei MaraDocs passiert im Wesentlichen folgendes: Sie bzw. der Browser laden zum Beispiel eine Fotodatei hoch (schicken diese also an unseren dateiverarbeitenden Server) und warten darauf, dass dieser die Datei bearbeitet hat. Zwischenergebnisse, von denen wiederum die Ansicht auf der Webseite abhängt, sind dabei z.B.:

• Foto enthält ein oder mehrere Dokumente
• die Koordinaten der Eckpunkte der enthaltenen Dokumente
• die neuen Bilddateien der ausgeschnittenen Dokumente
• das PDF-Ergebnis mit Texterkennung ist fertig
• etc...

Wir wollen natürlich, dass diese Zwischenergebnisse so schnell wie möglich für alle hochgeladenen Dateien wieder an den Browser zurückgesendet werden und dort für den Benutzer angezeigt werden.

Es liegt daher nahe, auf eine Technologie zurückzugreifen, die für diese Zwei-Wege-Kommunikation-Initiierung geeignet ist: Socket.io.

Socket.io baut eine permanente Verbindung zwischen Browser und Server auf und ermöglicht auch dem Server, eigene Nachrichten (events) zu schicken. Das Programm im Browser (MaraDocs) muss nun auf dieser Verbindung nach neuen events lauschen und dann in Abhängigkeit von deren Inhalt bestimmte Dinge tun.

Dies funktioniert grundsätzlich gut - und MaraDocs funktionierte bis zum 17. November 2025 nach genau diesem Prinzip.

Ein von mir unterschätzter Effekt war, dass wir uns damit architektonisch dem sog. event driven design angenähert haben. Dies ist natürlich ein etabliertes Architekturpattern in der Softwareentwicklung aber ich möchte behaupten, dass es für eine klassische Webapp mehr Nachteile als Vorteile bringt. Insbesondere die „räumliche" Trennung im Code zwischen event-sendenden Funktionen und ergebnis-verarbeitenden Funktionen erzeugt eine nicht zu unterschätzende Komplexität. Vorteile wie z.B. Typesafety müssen teuer mit erkauft werden, indem Libraries wie z.B. protobuf verwendet werden. Ebenso ist das Testen schwierig.

Wir haben uns letztlich dazu entschieden, in einer großen (wirklich sehr großen) Umbaumaßnahme von socket.io Abschied zu nehmen und wieder zum der-Browser-fragt-an Paradigma zurückzukehren, in dem wir alle vorherigen events wieder als einfache REST api calls modeln, bei denen der Server das Ergebnis direkt auf den call übermittelt. Mehr dazu im nächsten Abschnitt.

MaraDocs API aka MaraDocs 2.0

Um die von mir im Frühjahr bei meiner anwaltlichen Tätigkeit auftretenden Probleme mit von Mandanten übersandten E-Mails und Dateien zu lösen, mussten wir in vielerlei Hinsicht recht tief in die Technikkiste greifen.

Die skalierbare, sichere, parallele Bearbeitung vieler Dateien unter Zuhilfenahme verschiedener Maschine-Learning-Modelle auf eigenen Servern ist für sich eine technische Meisterleistung (der Respekt geht an dieser Stelle an Raui Ghazaleh, meinen Mitgründer).

Wir haben schon recht früh in der Entwicklung gemerkt, dass das technische Potential unserer Software weit über das hinaus geht, was die MaraDocs WebApp abbildet.

Die benutzbare MaraDocs WebApp ist genau für ihren Einsatzzweck konzipiert und funktioniert dabei großartig: Ein Benutzer zieht händisch E-Mails in den Browser, sortiert Ergebnisse zu fertigen PDFs zusammen und lädt diese herunter.

Unser System kann allerdings viel mehr: Über die von uns in den letzten 4 Monaten (August bis November 2025) entwickelte MaraDocs API wird es möglich, Automatisierung (zum Beispiel mit n8n) oder MaraDocs direkt in Drittsoftware einzubinden.

Wir sind im Gespräch mit verschiedenen Firmen, die Teilfunktionen von MaraDocs (zum Beispiel E-Mail-Extraktionen oder OCR) in ihre Software integrieren wollen.

Wir sind hier sehr gespannt auf die weitere Entwicklung dieses Geschäftszweiges unserer Firma.

Für uns war jedoch klar, dass wir die MaraDocs WebApp selbst als Kunden unserer eigenen API betrachten wollen. Wir haben also das bisherige Prozessierungsmodell mit socket.io vollständig gegen dezidierte api calls ausgetauscht und bedienen nun mit MaraDocs ausschließlich unsere öffentlich verfügbare MaraDocs API.

Dieses System läuft nun stabil und in production seit dem 17. November 2025.

Und das Business?

Advotec in Berlin und RAExpo in München

Wir haben unglaublich viel positive Resonanz in der LegalTech- und LegalSoftware-Szene erfahren. MaraDocs war auf der Advotec-Messe (begleitend zum Deutschen Anwaltstag) in Berlin und auf der RAExpo in München vertreten.

Spannend waren vor allem die Reaktionen von (potentiellen) Kunden: Es zeigt sich bei der Demonstration von MaraDocs sehr früh, ob eine Kanzlei den Bedarf für MaraDocs hat oder eben nicht. Für mich persönlich war es immer wahnsinnig erfüllend, wenn Kolleginnen und Kollegen zustimmend (und sichtlich leiderprobt) zustimmten:

„Ja, ja, genau, furchtbar, diese schlechten Fotografien, alles falsch gedreht und unten dann noch die Füße drauf!"

MaraDocs im LegalSoftware-Markt

Doch neben dem Kontakt mit zahlreichen Kolleginnen und Kollegen, die uns sowohl auf den Messen als auch im späteren Kundenkontakt wertvolles Feedback geliefert haben, hat uns der Austausch mit anderen Playern im LegalSoftware-Markt extrem weitergebracht.

Wir konnten uns vor allem mit den Kolleginnen und Kollegen von stp.one gut vernetzen und haben eine große thematische Überschneidung gesehen. Das leuchtet auch ein: Aus eigener Erfahrung weiß ich, dass die Kanzleisoftware (die Aktenverwaltungssoftware) das Herzstück einer jeden Kanzlei ist. Das ist der Ort, in dem Anwältinnen und Mitarbeiter praktisch „leben“, wenn sie arbeiten.

In meiner Kanzlei setzen wir seit vielen Jahren erfolgreich Advoware von stp.one ein. Advoware und MaraDocs ergänzen sich im Kanzleialltag einfach extrem gut. Gerade E-Mails, bei denen Mandanten Fotos in die E-Mail eingebettet haben oder die Bilder gar im proprietären Apple-Format (.heic) übersendet haben, brilliert MaraDocs und wandelt all dies in optimale, texterkannte, größenreduzierte PDFs um, mit denen man dann in Advoware wieder weiterarbeiten kann.

An dieser Stelle: Vielen Dank an die Kolleginnen und Kollegen von stp.one. Wir freuen uns auf ein erfolgreiches gemeinsames Jahr 2026 mit euch.

Netzwerken in der Szene

Doch auch neben der hervorzuhebenden Partnerschaft mit stp.one haben wir wertvolle neue Kontakte mit vielen außergewöhnlichen und sympathischen Unternehmen, Unternehmern und Unternehmerinnen auf den Messen geknüpft.

Der Kontakt zu den SEO- und Marketingspezialisten von OMmatic, den Gründern von iurApp oder auch die Gelegenheit, auf der RA Expo MaraDocs anderen Softwarefirmen wie z.B. Actaport oder Branchengrößen RA Micro und Wolters Kluwer vorzustellen, haben uns als Unternehmer aber auch als Unternehmen weitergebracht - und viel wichtiger: Auf der Messe oder beim anschließenden Wirtshausbesuch eine tolle Zeit beschert!

Ich bin jedenfalls gespannt, was sich daraus für MaraDocs im kommenden Jahr ergibt.

Vielen Dank! Wir freuen uns auf euch im Jahr 2026!

Was wir im kommenden Jahr vorhaben

Wir haben mit MaraDocs in 2024 und 2025 wahnsinnig viel erreicht. Mit viel Schweiß (zumindest in kognitiver Hinsicht), Ausdauer und Durchhaltevermögen haben wir aus dem Nichts eine wunderbare Software entwickelt, die ich selbst gerne jeden Tag in meiner anwaltlichen Tätigkeit einsetze.

Wir haben eine sehr lange Liste an Features, die wir im kommenden Jahr einbauen wollen:

• Optische Verbesserung der Scan-Ergebnisse (Hintergrund entfernen)
• Wiedereinführung der MaraMail-Funktionalität mit Link in die MaraDocs-Session
• Wahlweise Outlook-Plugin oder MaraDocs als native (installierbare) App
• verbesserte Kompression der Ergebnisse / mehr Auswahlmöglichkeiten
• PDF-Stempel-Funktion bzw. Annotieren von PDFs
• und vieles mehr...

In geschäftlicher Hinsicht wollen wir natürlich viel mehr Kanzleien erreichen und von MaraDocs überzeugen. Wir wissen auch, dass der Markt der Steuerberatungskanzleien ähnlich geeignet ist und möchten hier weitere Kunden gewinnen.

Ein großes Thema für uns ist auch die Internationalisierung von MaraDocs. Aktuell haben wir bereits Kunden in Deutschland, Österreich, der Schweiz und Polen, allerdings unterstützen wir derzeit noch keine weitere Sprache neben Deutsch. Hier gibt es also noch einiges zu tun, um auch auf den weiteren europäischen Märkten erfolgreich zu sein.

Wir blicken jedenfalls mit viel Tatendrang, frischen Ideen und frohen Mutes der Zukunft entgegen 😀!

Vielen Dank an alle, die uns auf diesem Weg begleiten!

Martin und Raui von MaraDocs.

MaraDocs erstellt optimierte PDFs aus Unterlagen von Mandanten

Wer Bilder statt PDFs von Mandanten erhält, muss nicht länger händisch konvertieren. MaraDocs übernimmt den kompletten Prozess – schnell, zuverlässig und ohne Qualitätsverlust.

• Ganze E-Mails einfach importieren
• alle Bilder werden automatisch analysiert und extrahiert
• im Ergebnis erhalten Sie optimierte PDFs

MaraDocs - als hätte der Mandant eine Scanner-App benutzt.

🚀 Jetzt testen: Kostenlos MaraDocs ausprobieren

---