Wszystkie wpisy
|Dostępne również w:DEENFRESITNO

Podsumowanie roku 2025 MaraDocs - I co jeszcze planujemy

Czas na podsumowanie, wydarzyło się wiele... Rok Maramia GmbH, MaraDocs, MaraDocs 2.0, MaraDocs API i partnerstwa. To podsumowanie roku daje techniczny i biznesowy wgląd w nasz rok 2025.

Martin Kurtz
Podsumowanie rokuMaraDocsSzczegóły techniczneBiznes
Podsumowanie roku 2025 MaraDocs - I co jeszcze planujemy

Narodziny MaraDocs

Od pomysłu do zupełnie innego prototypu

Nasze pierwsze szkice i plany tego, co później miało stać się MaraDocs, rozpoczęły się wiosną 2024 roku.

Miałem pomysł, że trzeba zautomatyzować te uciążliwe, czasochłonne procesy edycji zdjęć i plików e-mailowych. Z mojej własnej praktyki prawniczej byłem po prostu sfrustrowany nakładem czasu i niewygodą, jaką powodował format cyfrowych przesyłek od klientów w naszej kancelarii.

Zacząłem od grubych szkiców optymalnego przebiegu procesu i równolegle zacząłem zajmować się uczeniem maszynowym. Pamiętam wewnętrzny opór: Czy ja, jako nie-matematyk, będę w stanie rozwijać własne modele ML i wykorzystywać je w poważnym produkcie? (Tak - wymagało to dużo pracy nad nauką, ale się da…)

Stosunkowo szybko powstał pierwszy prototyp: MaraMail został narodzony. Zbudowaliśmy zgodne z przepisami o ochronie danych API e-mailowe, do którego można było wysłać jeden z tych e-maili, a MaraMail wyodrębniał wszystkie załączniki, wycinał dokumenty, wykonywał rozpoznawanie tekstu, a następnie tworzył z nich czyste pliki PDF. Następnie wysyłał e-mail z wynikami z powrotem do nadawcy.

Potrzebujemy interakcji!

Dość szybko stało się jasne, że wysyłanie na adres e-mail i oczekiwanie na wynik to dość nietypowy interfejs użytkownika do programu. Zarówno Raui, jak i ja dość szybko zauważyliśmy, że taki produkt (w którym nie ma nic do zobaczenia) będzie też trudny do wprowadzenia na rynek.

MaraDocs jako aplikacja webowa z możliwością interakcji dla użytkowników

Musiałem więc opracować aplikację z interfejsem użytkownika. Coś namacalnego.

Do tej pory miałem tylko podstawowe doświadczenie w tworzeniu interfejsów użytkownika. Moim pierwszym hobbystycznym projektem frontendowym była aplikacja React napisana w czystym JavaScript (czyli nie TypeScript), za pomocą której mogłem sterować różnymi urządzeniami automatyki domowej, takimi jak światła. Ale nie byłem ani projektantem, ani nie miałem naprawdę głębokiej wiedzy o złożonych aplikacjach webowych.

Pod koniec października 2024 roku zacząłem pisać pierwsze linijki obecnie widocznej części MaraDocs. Miała to być niesamowicie ekscytująca (naukowa) podróż. I znacznie więcej pracy, niż mogłem sobie wyobrazić w mojej początkowej naiwności.

Kilka szczegółów technicznych z rozwoju...

Stack jest gotowy

Ponieważ napisałem już przynajmniej jedną aplikację za pomocą React, było oczywiste, że MaraDocs również zostanie napisany w React. Podobał mi się ogólny model: dane zawsze płyną tylko w jednym kierunku drzewa komponentów. Pisze się kod deklaratywny, a React dba o ponowne renderowanie widocznego interfejsu użytkownika przy aktualizacji danych.

Sam React nie wystarcza przy takim projekcie. Potrzebne są gdzieś trwałe dane: Kim są moi klienci? Kto może się zalogować? Kto kupił jaką licencję? Itp…

Tutaj zdecydowaliśmy się na NextJs (z ServerActions) i Prisma ORM na samodzielnie hostowanej bazie danych PostgreSQL. NextJs jest i tak najbardziej oczywistym wyborem, gdy używa się React. Do dziś nie żałuję tej decyzji. Pozwoliło mi to na bardzo szybkie iterowanie różnych pomysłów i podejść i było rzeczywiście stosunkowo szybkie do nauczenia.

Biblioteki stanu i moc middleware

Znałem już z mojego poprzedniego hobbystycznego projektu problematykę „głęboko przekazywanego stanu" i wiedziałem, że dla bardziej złożonego projektu jak MaraDocs muszę sięgnąć po bibliotekę stanu, która pozwoli mi na rodzaj centralnego zarządzania danymi w frontendzie.

Jest trudno jako absolutny początkujący w tej dziedzinie podjąć właściwą decyzję lub wybór, a jednocześnie ta bardzo wczesna, ale konieczna decyzja o technologii jest również bardzo determinująca dla całego dalszego przebiegu rozwoju. Po kilku dniach researchu zdecydowałem się na Redux RTK. To z pewnością kontrowersyjna decyzja: Redux jest stosunkowo stary i często jest źle oceniany w internecie na odpowiednich forach programistycznych (Reddit itp…).

Nie wchodząc zbytnio w szczegóły: Redux opiera się na architekturze danych/procesów, w której widoczne komponenty zależą od stanu i aktualizują się przy zmianach. Jedyny sposób zmiany tych danych działa poprzez tzw. dispatchery, które przyjmują lub wykonują akcje i w ten sposób zmieniają stan. (stan oznacza mniej więcej aktualne dane).

Inteligentne przygotowanie dokumentów z MaraDocs

Dzięki MaraDocs zmienisz załączniki e-mail od swoich klientów w idealne skany. Wycinanie, prostowanie, łączenie, rozpoznawanie tekstu i wiele więcej.

Zacznij teraz za darmo

Również tutaj nie żałuję decyzji. Redux narzuca pewien wzorzec architektoniczny. Struktury danych i funkcje, które je zmieniają (akcje), są definiowane w jednym miejscu i w ten sposób automatycznie powstaje pewna struktura w projekcie. Można powiedzieć, że Redux jest stosunkowo opinionated jeśli chodzi o strukturyzację własnego kodu.

Ponadto architektura akcji oferuje potężną możliwość interwencji: Middleware.

Poprzez jeden lub więcej poziomów middleware możemy ingerować w wysłane akcje lub wykonywać dalsze zadania na ich podstawie. Przykład: W frontendzie użytkownik klika „Importuj obraz" i wybiera obraz z dysku twardego. Komponent w frontendzie przyjmuje obraz i następnie wysyła (dispatch) akcję addImage, która zawiera informacje o zaimportowanym obrazie. W middleware przechwytujemy tę akcję, generujemy unikalny identyfikator, wyodrębniamy obraz i wysyłamy go przez wywołanie api do MaraDocs API, a następnie przekazujemy akcję z wzbogaconymi informacjami do store'a.

Tutaj koło się zamyka: Widoczna część strony internetowej widzi teraz w store, że jest kolejny obraz i wyświetla go na podstawie danych przechowywanych w store.

To działa naprawdę świetnie.

Aplikacja webowa MaraDocs z modelem przepływu Redux
Aplikacja webowa MaraDocs z modelem przepływu Redux

Socket.io - gdy myśli się, że musi być szybko

Wczesną błędną decyzją było to, że na początku rozwoju MaraDocs zdecydowaliśmy się komunikować z procesami serwerowymi przetwarzającymi pliki przez socket.io.

Jako małe wyjaśnienie podstaw: Normalnie strony internetowe są zawsze żądane przez przeglądarkę. Otwierając na przykład Wikipedię, przeglądarka żąda strony z Wikipedii. Nie odwrotnie. Oznacza to jednak również, że Wikipedia nie może wysyłać aktualizacji podczas wizyty na stronie. (Przy Wikipedii może to nie być konieczne...)

W MaraDocs zasadniczo dzieje się następująco: Przesyłacie na przykład plik zdjęcia (wysyłacie go więc na nasz serwer przetwarzający pliki) i czekasz, aż przetworzy plik. Wyniki pośrednie, od których z kolei zależy widok na stronie internetowej, to na przykład:

  • Zdjęcie zawiera jeden lub więcej dokumentów
  • współrzędne punktów narożnych zawartych dokumentów
  • nowe pliki obrazów wyciętych dokumentów
  • wynik PDF z rozpoznawaniem tekstu jest gotowy
  • itp...

Oczywiście chcemy, aby te wyniki pośrednie zostały jak najszybciej odesłane do przeglądarki dla wszystkich przesłanych plików i tam wyświetlone użytkownikowi.

Dlatego oczywiste jest sięgnięcie po technologię odpowiednią do tej dwukierunkowej inicjacji komunikacji: Socket.io.

Socket.io buduje stałe połączenie między przeglądarką a serwerem i umożliwia również serwerowi wysyłanie własnych wiadomości (zdarzeń). Program w przeglądarce (MaraDocs) musi teraz nasłuchiwać nowych zdarzeń na tym połączeniu, a następnie w zależności od ich zawartości robić określone rzeczy.

Komunikacja oparta na zdarzeniach przez połączenia websocket
Komunikacja oparta na zdarzeniach przez połączenia websocket

To zasadniczo działa dobrze - i MaraDocs działał dokładnie według tej zasady do 17 listopada 2025 roku.

Efektem, który niedoceniłem, było to, że w ten sposób architektonicznie zbliżyliśmy się do tzw. event driven design. Jest to oczywiście ugruntowany wzorzec architektoniczny w rozwoju oprogramowania, ale chciałbym twierdzić, że dla klasycznej aplikacji webowej przynosi więcej wad niż zalet. W szczególności „przestrzenne" rozdzielenie w kodzie między funkcjami wysyłającymi zdarzenia a funkcjami przetwarzającymi wyniki tworzy niemożliwą do niedoceniania złożoność. Zalety takie jak np. bezpieczeństwo typów muszą być drogo wykupione przez użycie bibliotek takich jak np. protobuf. Również testowanie jest trudne.

Ostatecznie zdecydowaliśmy się w ramach dużego (naprawdę bardzo dużego) działania przebudowy pożegnać z socket.io i wrócić do paradygmatu przeglądarka-żąda, w którym modelujemy wszystkie poprzednie zdarzenia ponownie jako proste wywołania REST api, w których serwer przekazuje wynik bezpośrednio na wywołanie. Więcej o tym w następnej sekcji.

MaraDocs API aka MaraDocs 2.0

Aby rozwiązać problemy, które pojawiły się u mnie wiosną w mojej działalności prawniczej z e-mailami i plikami wysyłanymi przez klientów, musieliśmy w wielu aspektach sięgnąć dość głęboko do skrzynki z narzędziami technicznymi.

Skalowalne, bezpieczne, równoległe przetwarzanie wielu plików przy użyciu różnych modeli uczenia maszynowego na własnych serwerach jest samo w sobie technicznym arcydziełem (szacunek kieruję w tym miejscu do Raui Ghazaleha, mojego współzałożyciela).

Dość wcześnie w rozwoju zauważyliśmy, że potencjał techniczny naszego oprogramowania wykracza daleko poza to, co przedstawia aplikacja webowa MaraDocs.

Używalna aplikacja webowa MaraDocs jest zaprojektowana dokładnie do swojego celu i działa przy tym świetnie: Użytkownik ręcznie przeciąga e-maile do przeglądarki, sortuje wyniki do gotowych plików PDF i pobiera je.

Nasz system może jednak znacznie więcej: Poprzez opracowane przez nas w ciągu ostatnich 4 miesięcy (sierpień do listopad 2025) API MaraDocs możliwa staje się automatyzacja (na przykład z n8n) lub integracja MaraDocs bezpośrednio w oprogramowanie innych firm.

Prowadzimy rozmowy z różnymi firmami, które chcą zintegrować funkcje częściowe MaraDocs (na przykład ekstrakcje e-mail lub OCR) w swoim oprogramowaniu.

Jesteśmy tu bardzo ciekawi dalszego rozwoju tej gałęzi biznesowej naszej firmy.

Dla nas jednak było jasne, że chcemy traktować aplikację webową MaraDocs samą jako klienta naszego własnego API. Wymieniliśmy więc dotychczasowy model przetwarzania z socket.io całkowicie na dedykowane wywołania api i obsługujemy teraz z MaraDocs wyłącznie nasze publicznie dostępne API MaraDocs.

Ten system działa teraz stabilnie i w produkcji od 17 listopada 2025 roku.

Zasubskrybuj newsletter już teraz

Bądź z nami na bieżąco i otrzymuj najnowsze wiadomości, artykuły i zasoby pocztą e-mail.

A biznes?

Advotec w Berlinie i RAExpo w Monachium

Otrzymaliśmy niesamowicie wiele pozytywnych reakcji w środowisku LegalTech i LegalSoftware. MaraDocs był obecny na targach Advotec (towarzyszących Niemieckiemu Zjazdowi Adwokatów) w Berlinie oraz na RAExpo w Monachium.

Szczególnie ekscytujące były reakcje (potencjalnych) klientów: Podczas demonstracji MaraDocs bardzo szybko pokazuje się, czy kancelaria ma zapotrzebowanie na MaraDocs, czy nie. Dla mnie osobiście zawsze było niesamowicie satysfakcjonujące, gdy koleżanki i koledzy przytakiwali (i wyraźnie doświadczeni w cierpieniu):

„Tak, tak, dokładnie, straszne te złe zdjęcia, wszystko źle obracane, a na dole jeszcze stopy na zdjęciu!"

MaraDocs na rynku LegalSoftware

Ale oprócz kontaktu z licznymi koleżankami i kolegami, którzy dostarczyli nam cennych informacji zwrotnych zarówno na targach, jak i w późniejszym kontakcie z klientami, wymiana z innymi graczami na rynku LegalSoftware niezwykle nas posunęła do przodu.

Udało nam się szczególnie dobrze nawiązać kontakt z koleżankami i kolegami z stp.one i dostrzegliśmy duże tematyczne pokrywanie się. To również ma sens: Z własnego doświadczenia wiem, że oprogramowanie kancelaryjne (oprogramowanie do zarządzania aktami) jest sercem każdej kancelarii. To miejsce, w którym adwokaci i pracownicy praktycznie „żyją", kiedy pracują.

W mojej kancelarii od wielu lat z powodzeniem używamy Advoware od stp.one. Advoware i MaraDocs po prostu doskonale się uzupełniają w codziennej pracy kancelarii. Szczególnie w przypadku e-maili, w których klienci umieścili zdjęcia w treści e-maila lub przesłali obrazy w zastrzeżonym formacie Apple (.heic), MaraDocs błyszczy i konwertuje to wszystko na optymalne, rozpoznane tekstowo, zredukowane rozmiarowo pliki PDF, z którymi można następnie pracować dalej w Advoware.

W tym miejscu: Dziękujemy koleżankom i kolegom z stp.one. Cieszymy się na udany wspólny rok 2026 z wami.

Networking w branży

Ale również poza wyróżniającym się partnerstwem z stp.one nawiązaliśmy wartościowe nowe kontakty z wieloma wyjątkowymi i sympatycznymi firmami, przedsiębiorcami i przedsiębiorczyniami na targach.

Kontakt ze specjalistami SEO i marketingu z OMmatic, założycielami iurApp lub również możliwość zaprezentowania MaraDocs na RA Expo innym firmom softwarowym, takim jak np. Actaport czy gigantom branży RA Micro i Wolters Kluwer, posunęły nas do przodu jako przedsiębiorców, ale także jako firmę - i co ważniejsze: Na targach lub podczas późniejszej wizyty w karczmie spędziliśmy świetny czas!

Jestem w każdym razie ciekawy, co z tego wyniknie dla MaraDocs w nadchodzącym roku.

Dziękujemy! Cieszymy się na was w roku 2026!

Co planujemy w nadchodzącym roku

Perspektywy 2026 - co planujemy

Osiągnęliśmy niesamowicie wiele z MaraDocs w 2024 i 2025 roku. Z dużą ilością potu (przynajmniej w znaczeniu poznawczym), wytrwałością i determinacją opracowaliśmy z niczego wspaniałe oprogramowanie, które sam chętnie używam każdego dnia w mojej praktyce prawniczej.

Mamy bardzo długą listę funkcji, które chcemy wbudować w nadchodzącym roku:

  • Optyczne ulepszenie wyników skanowania (usuwanie tła)
  • Przywrócenie funkcjonalności MaraMail z linkiem do sesji MaraDocs
  • Opcjonalnie wtyczka Outlook lub MaraDocs jako natywna (instalowalna) aplikacja
  • ulepszona kompresja wyników / więcej opcji wyboru
  • Funkcja stemplowania PDF / adnotowanie plików PDF
  • i wiele więcej...

Jeśli chodzi o biznes, chcemy oczywiście dotrzeć do znacznie większej liczby kancelarii i przekonać je o MaraDocs. Wiemy również, że rynek kancelarii doradztwa podatkowego jest podobnie odpowiedni i chcemy tutaj pozyskać dalszych klientów.

Dużym tematem dla nas jest również internacjonalizacja MaraDocs. Obecnie mamy już klientów w Niemczech, Austrii, Szwajcarii i Polsce, jednak obecnie nie obsługujemy jeszcze innego języka oprócz niemieckiego. Jest więc jeszcze sporo do zrobienia, aby odnieść sukces również na innych rynkach europejskich.

W każdym razie patrzymy w przyszłość z dużą energią, świeżymi pomysłami i radosną odwagą 😀!

Dziękujemy wszystkim, którzy towarzyszą nam na tej drodze!

Martin i Raui z MaraDocs.

Zasubskrybuj newsletter już teraz

Bądź z nami na bieżąco i otrzymuj najnowsze wiadomości, artykuły i zasoby pocztą e-mail.

MaraDocs tworzy zoptymalizowane pliki PDF z dokumentów od klientów

Kto otrzymuje zdjęcia zamiast plików PDF od klientów, nie musi już ręcznie konwertować. MaraDocs przejmuje cały proces – szybko, niezawodnie i bez utraty jakości.

  • Po prostu zaimportuj całe e-maile
  • wszystkie obrazy są automatycznie analizowane i wyodrębniane
  • w wyniku otrzymujesz zoptymalizowane pliki PDF

MaraDocs - jakby klient użył aplikacji skanera.

🚀 Wypróbuj teraz: Wypróbuj MaraDocs za darmo