MaraDocs årsrapport 2025 - Og hva vi har planlagt

Fødselen av MaraDocs

Fra idé til en helt annerledes prototype

Våre første utkast og planer til det som senere skulle bli MaraDocs, begynte våren 2024.

Jeg hadde denne ideen om at man måtte automatisere disse kjedelige, tidkrevende foto- og e-postfilbehandlingene. Jeg var rett og slett irritert fra min egen advokatvirksomhet over tidsbruken og tungvintheten som formatet på digitale klientforsendelser skapte hos oss på kontoret.

Jeg begynte med grove skisser av den optimale prosessavviklingen og startet parallelt å beskjeftige meg med maskinlæring. Her husker jeg den indre motstanden: Ville jeg som ikke-matematiker være i stand til å utvikle egne ML-modeller og kunne bruke disse i et seriøst produkt? (Ja - det var mye læringsarbeid, men det går...)

Relativt raskt sto den første prototypen klar: MaraMail var født. Vi hadde bygget en personvernvennlig e-post-API som man kunne sende en slik e-post til, og MaraMail ville ekstraktere alle vedlegg, klippe ut dokumenter, utføre tekstgjenkjenning og deretter lage rene PDF-er ut av det. Etterpå sendte den en e-post med resultatene tilbake til avsenderen.

Vi trenger interaksjon!

Det ble relativt raskt klart at forsendelse til en e-postadresse og venting på et resultat er et relativt uvanlig brukergrensesnitt til et program. Og både Raui og jeg merket ganske raskt at et slikt produkt (der det ikke finnes noe å se) også nesten ikke lot seg markedsføre.

Jeg måtte altså utvikle en app som kunne betjenes. Noe å ta på.

Hittil hadde jeg bare rudimentære erfaringer med utvikling av user interfaces. Mitt første frontend-hobbyprosjekt var en React-app skrevet i plain JavaScript (altså ikke TypeScript), som jeg kunne styre forskjellige hjemmeautomasjonsenheter som f.eks. lys med. Men jeg var verken designer eller hadde jeg virkelig dyptgående kunnskaper om komplekse webapper.

Slutten av oktober 2024 begynte jeg å skrive de første linjene av den i dag synlige delen av MaraDocs. Det skulle bli en utrolig spennende (lærings-)reise. Og mye mer arbeid enn jeg i min opprinnelige naivitet kunne ha forestilt meg.

Noen tekniske detaljer fra utviklingen...

Stacken står

Siden jeg i det minste allerede hadde skrevet en app ved hjelp av React, lå det nær at MaraDocs også ville bli skrevet i React. Jeg likte den generelle modellen: Data flyter alltid bare i én retning av component tree. Man skriver deklarativ kode og React tar seg av å re-rendre den synlige UI-en ved oppdateringer av dataene.

React alene er ikke nok ved et slikt prosjekt. Man trenger persistent data et sted: Hvem er mine kunder? Hvem kan logge inn? Hvem har kjøpt hvilken lisens? Etc…

Her har vi valgt NextJs (med ServerActions) og Prisma ORM på en selvhostet PostgreSQL-database. NextJs er uansett det mest nærliggende valget når man bruker React. Jeg angrer ikke på dette valget den dag i dag. Det lot meg iterere de forskjellige ideene og tilnærmingene veldig raskt og var faktisk relativt raskt å lære.

State libraries and the power of middleware

Jeg kjente allerede fra mitt forgjenger-hobbyprosjekt problemet med «dypt gjennomsendt state» og visste at jeg for et mer komplekst prosjekt som MaraDocs måtte ty til et state library som ga meg en slags sentral datahåndtering i frontend.

Det er vanskelig som absolutt nybegynner på dette området å ta den riktige avgjørelsen eller utvelgelsen, og samtidig er denne veldig tidlige, men nødvendige festingen til en teknologi også veldig bestemmende for hele den videre utviklingsprosessen. Jeg bestemte meg etter noen dagers research for Redux RTK. Dette er sikkert en kontroversiell avgjørelse: Redux er relativt gammelt og blir på internett i de relevante utviklerfora (Reddit etc...) ofte snakket dårlig om.

Uten å gå for mye i detalj: Redux er basert på en data- eller prosessarkitektur der synlige komponenter avhenger av state og oppdateres ved endringer. Den eneste måten å endre disse dataene på, fungerer via såkalte dispatchers som tar imot eller utfører actions og dermed endrer state. (state betyr omtrent som aktuelle data).

Også her angrer jeg ikke på avgjørelsen. Redux tvinger på en et visst arkitektonisk mønster. Datastrukturer og de endrende funksjonene (actions) defineres på ett sted, og på denne måten oppstår automatisk en viss struktur i prosjektet. Man kunne si at Redux er relativt opinionated når det gjelder struktureringen av egen kode.

I tillegg tilbyr arkitekturen av actions en kraftig inngripsmulighet: Middleware.

Via ett eller flere middleware levels kan vi gripe inn i avsendte actions eller utføre flere oppgaver utgående fra disse. Et eksempel: I frontend klikker brukeren på «Importer bilde» og velger et bilde fra harddisken sin. Komponenten i frontend tar imot bildet og sender (dispatch) deretter en addImage action som inneholder informasjon om det importerte bildet. I middleware fanger vi opp denne actionen, genererer en unik ID, ekstrakterer bildet og sender det via api call til MaraDocs API og videresender deretter actionen med berikede opplysninger til store.

Her lukkes sirkelen: Den synlige delen av nettsiden ser nå i store at det finnes et ytterligere bilde, og fremstiller dette på basis av dataene lagret i store.

Dette fungerer virkelig fantastisk.

Socket.io - når man tror det må gå raskt

En tidlig feilbeslutning var at vi ved begynnelsen av utviklingen av MaraDocs hadde bestemt oss for å kommunisere med de filbehandlende serverprosessene via socket.io.

Som en liten grunnleggende forklaring: Normalt blir nettsider alltid forespurt fra nettleseren. Åpner du for eksempel Wikipedia, forespør nettleseren din siden fra Wikipedia. Ikke omvendt. Det betyr imidlertid også at Wikipedia ikke kan sende deg oppdateringer under besøket ditt på siden. (Er kanskje heller ikke nødvendig hos Wikipedia...)

Ved MaraDocs skjer i hovedsak følgende: Du eller nettleseren laster for eksempel opp en fotofil (sender denne altså til vår filbehandlende server) og venter på at denne har behandlet filen. Mellomresultater, som igjen visningen på nettsiden avhenger av, er for eksempel:

• Foto inneholder ett eller flere dokumenter
• koordinatene til hjørnepunktene til de inneholdte dokumentene
• de nye bildfilene til de utklipte dokumentene
• PDF-resultatet med tekstgjenkjenning er ferdig
• etc...

Vi ønsker selvfølgelig at disse mellomresultatene sendes tilbake til nettleseren så raskt som mulig for alle opplastede filer og vises der for brukeren.

Det ligger derfor nær å ty til en teknologi som egner seg for denne toveis-kommunikasjons-initieringen: Socket.io.

Socket.io bygger en permanent forbindelse mellom nettleser og server og gjør det også mulig for serveren å sende egne meldinger (events). Programmet i nettleseren (MaraDocs) må nå lytte etter nye events på denne forbindelsen og deretter gjøre bestemte ting avhengig av deres innhold.

Dette fungerer grunnleggende godt - og MaraDocs fungerte frem til 17. november 2025 etter nettopp dette prinsippet.

En av meg undervurdert effekt var at vi dermed arkitektonisk hadde nærmet oss den såkalte event driven design. Dette er selvfølgelig et etablert arkitekturmønster i programvareutvikling, men jeg vil påstå at det for en klassisk webapp bringer mer ulemper enn fordeler. Spesielt den «romlige» separasjonen i koden mellom event-sendende funksjoner og resultat-behandlende funksjoner skaper en ikke ubetydelig kompleksitet. Fordeler som f.eks. typesikkerhet må kjøpes dyrt ved at libraries som f.eks. protobuf brukes. Testing er også vanskelig.

Vi bestemte oss til slutt for å ta farvel med socket.io i en stor (virkelig veldig stor) ombyggingstiltak og gå tilbake til nettleseren-forespør-paradigmet, der vi modellerer alle tidligere events igjen som enkle REST api calls, der serveren overfører resultatet direkte på callet. Mer om det i neste avsnitt.

MaraDocs API aka MaraDocs 2.0

For å løse de problemene som oppsto hos meg våren ved min advokatvirksomhet med e-poster og filer oversendt fra klienter, måtte vi på mange måter gripe ganske dypt i teknikkassen.

Den skalerbare, sikre, parallelle behandlingen av mange filer ved hjelp av forskjellige maskinlæringsmodeller på egne servere er i seg selv en teknisk mesterprestasjon (respekten går på dette punktet til Raui Ghazaleh, min medgründer).

Vi merket ganske tidlig i utviklingen at det tekniske potensialet til programvaren vår strekker seg langt utover det som MaraDocs WebApp avbilder.

Den brukbare MaraDocs WebApp er designet nøyaktig for sitt bruksformål og fungerer fantastisk: En bruker drar manuelt e-poster inn i nettleseren, sorterer resultater til ferdige PDF-er sammen og laster disse ned.

Systemet vårt kan imidlertid mye mer: Via den MaraDocs API vi har utviklet de siste 4 månedene (august til november 2025), blir det mulig å automatisere (for eksempel med n8n) eller integrere MaraDocs direkte i tredjepartsprogramvare.

Vi er i samtaler med forskjellige firmaer som ønsker å integrere delfunksjoner av MaraDocs (for eksempel e-postekstraksjon eller OCR) i sin programvare.

Vi er veldig spent på den videre utviklingen av denne forretningsgrenen til firmaet vårt.

For oss var det imidlertid klart at vi ville betrakte MaraDocs WebApp selv som kunde av vår egen API. Vi har altså fullstendig byttet ut den tidligere prosesseringsmodellen med socket.io mot dedikerte api calls og betjener nå med MaraDocs utelukkende vår offentlig tilgjengelige MaraDocs API.

Dette systemet kjører nå stabilt og in production siden 17. november 2025.

Og business?

Advotec i Berlin og RAExpo i München

Vi har opplevd utrolig mye positiv respons i LegalTech- og LegalSoftware-miljøet. MaraDocs var representert på Advotec-messen (ledsagende til den tyske advokatdagen) i Berlin og på RAExpo i München.

Spennende var særlig reaksjonene fra (potensielle) kunder: Det viser seg ved demonstrasjon av MaraDocs veldig tidlig om et advokatkontor har behov for MaraDocs eller ikke. For meg personlig var det alltid vanvittig tilfredsstillende når kolleger nickende (og synlig skadelidende) samtykket:

«Ja, ja, akkurat, forferdelig, disse dårlige fotografiene, alt feil rotert og så føttene med nederst!»

MaraDocs i LegalSoftware-markedet

Men foruten kontakten med tallrike kolleger som har gitt oss verdifull tilbakemelding både på messene og i senere kundekontakt, har utvekslingen med andre aktører i LegalSoftware-markedet brakt oss enormt videre.

Vi kunne særlig knytte gode kontakter med kollegene hos stp.one og har sett en stor tematisk overlapping. Det er også forståelig: Av egen erfaring vet jeg at advokatkontor-programvaren (saksstyringsprogramvaren) er hjertet i ethvert advokatkontor. Det er stedet der advokater og medarbeidere praktisk talt «lever» når de jobber.

På mitt kontor har vi i mange år brukt Advoware fra stp.one med suksess. Advoware og MaraDocs utfyller hverandre i kontorhverdagen rett og slett ekstremt godt. Særlig e-poster der klienter har innebygd bilder i e-posten eller har oversendt bildene i det proprietære Apple-formatet (.heic), briljerer MaraDocs og konverterer alt dette til optimale, tekstgjenkjente, størrelsesreduserte PDF-er som man så kan jobbe videre med i Advoware.

På dette punktet: Tusen takk til kollegene hos stp.one. Vi ser frem til et vellykket felles år 2026 med dere.

Nettverksbygging i miljøet

Men også foruten det fremhevede partnerskapet med stp.one har vi knyttet verdifulle nye kontakter med mange ekstraordinære og sympatiske selskaper, gründere på messene.

Kontakten med SEO- og markedsføringsspesialistene hos OMmatic, gründerne av iurApp eller også muligheten til å presentere MaraDocs for andre programvarefirmaer som f.eks. Actaport eller bransjegigantene RA Micro og Wolters Kluwer på RA Expo, har brakt oss videre som gründere men også som selskap - og mye viktigere: Gitt oss en flott tid på messen eller ved det etterfølgende kroprobesøket!

Jeg er i alle fall spent på hva dette resulterer i for MaraDocs i det kommende året.

Tusen takk! Vi ser frem til dere i år 2026!

Hva vi har planlagt det kommende året

Vi har oppnådd vanvittig mye med MaraDocs i 2024 og 2025. Med mye svette (i det minste i kognitiv forstand), utholdenhet og gjennomføringsevne har vi utviklet en fantastisk programvare fra ingenting, som jeg selv gjerne bruker hver dag i min advokatvirksomhet.

Vi har en veldig lang liste over funksjoner vi ønsker å bygge inn det kommende året:

• Optisk forbedring av skanneresultatene (fjerne bakgrunn)
• Gjeninnføring av MaraMail-funksjonaliteten med lenke til MaraDocs-sesjonen
• Valgfritt Outlook-plugin eller MaraDocs som native (installerbar) app
• forbedret kompresjon av resultatene / flere valgmuligheter
• PDF-stempel-funksjon eller annotering av PDF-er
• og mye mer...

I forretningsmessig forstand ønsker vi selvfølgelig å nå mange flere advokatkontorer og overbevise om MaraDocs. Vi vet også at markedet for regnskapskontorer er like egnet og ønsker å vinne flere kunder her.

Et stort tema for oss er også internasjonaliseringen av MaraDocs. For øyeblikket har vi allerede kunder i Tyskland, Østerrike, Sveits og Polen, men vi støtter foreløpig ikke noe annet språk ved siden av tysk. Her er det altså fortsatt en del å gjøre for også å lykkes på de øvrige europeiske markedene.

Vi ser i alle fall frem mot fremtiden med mye pågangsmot, friske ideer og freidig mot 😀!

Tusen takk til alle som følger oss på denne veien!

Martin og Raui fra MaraDocs.

MaraDocs lager optimaliserte PDF-er fra klientdokumenter

Den som mottar bilder i stedet for PDF-er fra klienter, trenger ikke lenger konvertere manuelt. MaraDocs overtar hele prosessen – raskt, pålitelig og uten kvalitetstap.

• Importer hele e-poster enkelt
• alle bilder analyseres og ekstrakteres automatisk
• i resultatet får du optimaliserte PDF-er

MaraDocs - som om klienten hadde brukt en skannerapp.

🚀 Test nå: Prøv MaraDocs gratis