MaraDocs Retrospettiva 2025 - E cosa abbiamo in programma

La nascita di MaraDocs

Dall'idea a un prototipo completamente diverso

I nostri primi bozzetti e piani per quello che in seguito sarebbe diventato MaraDocs sono iniziati nella primavera del 2024.

Avevo questa idea che bisognasse automatizzare questi fastidiosi e dispendiosi processi di elaborazione di foto e file email. Ero semplicemente frustrato dalla mia attività legale per il tempo e la complessità che il formato degli invii digitali dei clienti causava nel nostro studio.

Ho iniziato con schizzi approssimativi del flusso di processo ottimale e parallelamente ho cominciato a occuparmi di machine learning. Ricordo la resistenza interiore: sarei stato in grado, come non-matematico, di sviluppare i miei modelli ML e utilizzarli in un prodotto serio? (Sì - è stato molto lavoro di apprendimento, ma è possibile...)

Abbastanza presto è nato il primo prototipo: MaraMail era nato. Avevamo costruito un'API email conforme alla privacy a cui si poteva inviare una di queste email in questione, e MaraMail avrebbe estratto tutti gli allegati, ritagliato i documenti, eseguito il riconoscimento del testo e poi creato dei PDF puliti. Successivamente inviava un'email con i risultati al mittente.

Abbiamo bisogno di interazione!

È diventato abbastanza chiaro rapidamente che l'invio a un indirizzo email e l'attesa di un risultato fosse un'interfaccia utente relativamente insolita per un programma. E sia Raui che io ci siamo resi conto abbastanza velocemente che un tale prodotto (in cui non c'è nulla da vedere) era difficilmente commercializzabile.

Dovevo quindi sviluppare un'app utilizzabile. Qualcosa di tangibile.

Fino ad allora avevo solo esperienze rudimentali nello sviluppo di user interfaces. Il mio primo progetto frontend hobby era un'app React scritta in plain JavaScript (quindi non TypeScript) con cui potevo controllare vari dispositivi di automazione domestica come ad esempio le luci. Ma non ero né un designer né avevo realmente conoscenze approfondite su WebApp complesse.

Alla fine di ottobre 2024 ho iniziato a scrivere le prime righe della parte oggi visibile di MaraDocs. Sarebbe diventato un viaggio incredibilmente entusiasmante (di apprendimento). E molto più lavoro di quanto avrei potuto immaginare nella mia ingenuità iniziale.

Alcuni dettagli tecnici dello sviluppo...

Lo stack è definito

Dato che avevo già scritto almeno un'app con l'aiuto di React, era ovvio che MaraDocs sarebbe stato scritto anch'esso in React. Mi piaceva il modello generale: i dati fluiscono sempre solo in una direzione del component tree. Si scrive codice dichiarativo e React si occupa di ri-renderizzare l'UI visibile quando i dati vengono aggiornati.

React da solo non basta per un progetto del genere. Hai bisogno di dati persistenti da qualche parte: Chi sono i miei clienti? Chi può effettuare il login? Chi ha acquistato quale licenza? Ecc...

Qui abbiamo optato per NextJs (con ServerActions) e Prisma ORM su un database PostgreSQL self-hosted. NextJs è comunque la scelta più ovvia quando si usa React. Non mi pento di questa decisione ancora oggi. Mi ha permesso di iterare molto velocemente sulle varie idee e approcci ed è stato effettivamente abbastanza veloce da imparare.

State libraries e il potere del middleware

Conoscevo già dal mio precedente progetto hobby la problematica dello "state passato in profondità" e sapevo che per un progetto più complesso come MaraDocs avrei dovuto ricorrere a una state library che mi permettesse una sorta di gestione centralizzata dei dati nel frontend.

È difficile, come principiante assoluto in questo campo, fare la scelta giusta e allo stesso tempo questa decisione molto precoce ma necessaria su una tecnologia è anche molto determinante per l'intero corso successivo dello sviluppo. Dopo alcuni giorni di ricerca ho deciso per Redux RTK. Questa è certamente una decisione controversa: Redux è relativamente vecchio e viene spesso criticato su Internet nei forum degli sviluppatori (Reddit ecc...).

Senza entrare troppo nei dettagli: Redux si basa su un'architettura di dati e processi in cui i componenti visibili dipendono dallo state e si aggiornano quando questo cambia. L'unico modo per modificare questi dati funziona attraverso i cosiddetti dispatcher, che ricevono o eseguono actions e quindi modificano lo state. (state significa qualcosa come dati correnti).

Anche qui non mi pento della decisione. Redux impone un certo pattern architetturale. Strutture di dati e le funzioni che le modificano (actions) vengono definite in un unico posto e in questo modo emerge automaticamente una certa struttura nel progetto. Si potrebbe dire che Redux è relativamente opinionated riguardo alla strutturazione del proprio codice.

Inoltre, l'architettura delle actions offre una potente possibilità di intervento: Middleware.

Attraverso uno o più middleware level possiamo intervenire nelle actions inviate o eseguire ulteriori compiti partendo da esse. Un esempio: Nel frontend l'utente clicca su "Importa immagine" e seleziona un'immagine dal suo disco rigido. Il component nel frontend riceve l'immagine e invia (dispatch) quindi un'addImage action, che contiene informazioni sull'immagine importata. Nel middleware intercettiamo questa action, generiamo un ID univoco, estraiamo l'immagine e la inviamo tramite api call all'API MaraDocs e poi inoltriamo l'action con informazioni arricchite allo store.

Qui il cerchio si chiude: La parte visibile della pagina web vede ora nello store che c'è un'altra immagine e la rappresenta sulla base dei dati memorizzati nello store.

Funziona davvero magnificamente.

Socket.io - quando si pensa che debba essere veloce

Una decisione sbagliata precoce è stata che all'inizio dello sviluppo di MaraDocs avevamo deciso di comunicare con i processi server di elaborazione dei file tramite socket.io.

Come piccola spiegazione di base: Normalmente le pagine web vengono sempre richieste dal browser. Se aprite per esempio Wikipedia, il vostro browser richiede la pagina a Wikipedia. Non viceversa. Ciò significa però anche che Wikipedia non può inviarvi aggiornamenti durante la vostra visita sulla pagina. (Forse non è nemmeno necessario per Wikipedia...)

Con MaraDocs succede essenzialmente quanto segue: Voi o il browser caricate per esempio un file foto (lo inviate quindi al nostro server di elaborazione file) e aspettate che questo abbia elaborato il file. Risultati intermedi, da cui dipende nuovamente la visualizzazione sulla pagina web, sono per esempio:

• La foto contiene uno o più documenti
• le coordinate dei punti angolari dei documenti contenuti
• i nuovi file immagine dei documenti ritagliati
• il risultato PDF con riconoscimento del testo è pronto
• ecc...

Vogliamo naturalmente che questi risultati intermedi vengano rispediti al browser il più velocemente possibile per tutti i file caricati e visualizzati lì per l'utente.

È quindi ovvio ricorrere a una tecnologia adatta a questa iniziazione di comunicazione bidirezionale: Socket.io.

Socket.io costruisce una connessione permanente tra browser e server e consente anche al server di inviare i propri messaggi (events). Il programma nel browser (MaraDocs) deve ora ascoltare su questa connessione i nuovi events e poi fare determinate cose in base al loro contenuto.

Questo funziona fondamentalmente bene - e MaraDocs ha funzionato esattamente secondo questo principio fino al 17 novembre 2025.

Un effetto da me sottovalutato è stato che ci siamo avvicinati architettonicamente al cosiddetto event driven design. Questo è naturalmente un pattern architetturale consolidato nello sviluppo software ma vorrei affermare che per una WebApp classica porta più svantaggi che vantaggi. In particolare la separazione "spaziale" nel codice tra funzioni che inviano eventi e funzioni che elaborano risultati crea una complessità da non sottovalutare. Vantaggi come ad esempio la type safety devono essere acquistati a caro prezzo utilizzando librerie come ad esempio protobuf. Anche il testing è difficile.

Abbiamo finalmente deciso di prendere congedo da socket.io in una grande (davvero molto grande) operazione di ristrutturazione e tornare al paradigma il-browser-richiede, modellando tutti i precedenti events nuovamente come semplici REST api calls, in cui il server trasmette il risultato direttamente sulla call. Maggiori informazioni nella prossima sezione.

MaraDocs API aka MaraDocs 2.0

Per risolvere i problemi che si presentavano nella mia attività legale in primavera con le email e i file inviati dai clienti, dovevamo attingere profondamente alla cassetta degli attrezzi tecnologici in molti aspetti.

L'elaborazione scalabile, sicura e parallela di molti file con l'ausilio di vari modelli di machine learning su server propri è di per sé un'impresa tecnica magistrale (il rispetto va in questo punto a Raui Ghazaleh, il mio co-fondatore).

Ci siamo accorti abbastanza presto nello sviluppo che il potenziale tecnico del nostro software va ben oltre ciò che la MaraDocs WebApp rappresenta.

La MaraDocs WebApp utilizzabile è progettata esattamente per il suo scopo d'uso e funziona magnificamente: Un utente trascina manualmente le email nel browser, ordina i risultati in PDF finiti e li scarica.

Il nostro sistema può però fare molto di più: Attraverso la MaraDocs API che abbiamo sviluppato negli ultimi 4 mesi (agosto-novembre 2025) diventa possibile l'automazione (per esempio con n8n) o integrare MaraDocs direttamente in software di terze parti.

Siamo in trattativa con varie aziende che vogliono integrare funzioni parziali di MaraDocs (per esempio estrazioni email o OCR) nel loro software.

Siamo molto curiosi dello sviluppo futuro di questo ramo commerciale della nostra azienda.

Per noi però era chiaro che volevamo considerare la MaraDocs WebApp stessa come cliente della nostra API. Abbiamo quindi sostituito completamente il precedente modello di processamento con socket.io contro api calls dedicate e ora con MaraDocs serviamo esclusivamente la nostra MaraDocs API disponibile pubblicamente.

Questo sistema funziona ora stabilmente e in production dal 17 novembre 2025.

E il business?

Advotec a Berlino e RAExpo a Monaco

Abbiamo ricevuto un'incredibile risonanza positiva nella scena LegalTech e LegalSoftware. MaraDocs è stato presente alla fiera Advotec (accompagnando la Giornata degli Avvocati Tedeschi) a Berlino e alla RAExpo a Monaco.

Particolarmente interessanti sono state soprattutto le reazioni dei clienti (potenziali): Si mostra nella dimostrazione di MaraDocs molto presto se uno studio ha bisogno di MaraDocs o meno. Per me personalmente è sempre stato incredibilmente appagante quando le colleghe e i colleghi annuivano (e visibilmente provati dall'esperienza):

"Sì, sì, esatto, terribile, queste fotografie scadenti, tutto ruotato male e poi anche i piedi in basso!"

MaraDocs nel mercato LegalSoftware

Ma oltre al contatto con numerose colleghe e colleghi che ci hanno fornito feedback prezioso sia alle fiere che nel successivo contatto con i clienti, lo scambio con altri player nel mercato LegalSoftware ci ha fatto fare enormi progressi.

Abbiamo potuto soprattutto fare rete con le colleghe e i colleghi di stp.one e abbiamo visto una grande sovrapposizione tematica. Questo ha anche senso: Per esperienza personale so che il software dello studio (il software di gestione delle pratiche) è il cuore di ogni studio. Questo è il luogo in cui gli avvocati e i collaboratori praticamente "vivono" quando lavorano.

Nel mio studio utilizziamo con successo da molti anni Advoware di stp.one. Advoware e MaraDocs si completano semplicemente in modo estremamente efficace nella routine quotidiana dello studio. Proprio con le email in cui i clienti hanno incorporato foto nell'email o hanno addirittura inviato le immagini nel formato proprietario Apple (.heic), MaraDocs brilla e converte tutto questo in PDF ottimali, con riconoscimento del testo, ridotti in dimensioni, con cui si può poi continuare a lavorare in Advoware.

A questo punto: Molte grazie alle colleghe e ai colleghi di stp.one. Non vediamo l'ora di un anno 2026 di successo insieme a voi.

Fare rete nella scena

Ma anche oltre alla partnership da sottolineare con stp.one abbiamo stabilito contatti preziosi con molte aziende straordinarie e simpatiche, imprenditori e imprenditrici alle fiere.

Il contatto con gli specialisti SEO e marketing di OMmatic, i fondatori di iurApp o anche l'opportunità di presentare MaraDocs alla RA Expo ad altre aziende software come ad esempio Actaport o ai giganti del settore RA Micro e Wolters Kluwer, ci hanno fatto progredire come imprenditori ma anche come azienda - e molto più importante: Alla fiera o alla successiva visita all'osteria ci hanno fatto passare un momento fantastico!

Sono comunque curioso di vedere cosa ne deriverà per MaraDocs nell'anno prossimo.

Molte grazie! Non vediamo l'ora di rivedervi nel 2026!

Cosa abbiamo in programma per il prossimo anno

Abbiamo raggiunto moltissimo con MaraDocs nel 2024 e 2025. Con molto sudore (almeno in senso cognitivo), perseveranza e tenacia abbiamo sviluppato dal nulla un software meraviglioso che uso volentieri io stesso ogni giorno nella mia attività legale.

Abbiamo una lista molto lunga di funzionalità che vogliamo implementare nel prossimo anno:

• Miglioramento ottico dei risultati di scansione (rimozione dello sfondo)
• Reintroduzione della funzionalità MaraMail con link alla sessione MaraDocs
• Plugin Outlook opzionale o MaraDocs come app nativa (installabile)
• compressione migliorata dei risultati / più opzioni di scelta
• funzione timbro PDF o annotazione di PDF
• e molto altro...

Dal punto di vista commerciale vogliamo naturalmente raggiungere molti più studi legali e convincerli di MaraDocs. Sappiamo anche che il mercato degli studi di consulenza fiscale è altrettanto adatto e vorremmo acquisire qui ulteriori clienti.

Un grande tema per noi è anche l'internazionalizzazione di MaraDocs. Attualmente abbiamo già clienti in Germania, Austria, Svizzera e Polonia, tuttavia non supportiamo ancora nessun'altra lingua oltre al tedesco. C'è quindi ancora molto da fare per avere successo anche negli altri mercati europei.

Guardiamo comunque al futuro con molto dinamismo, idee fresche e buon umore 😀!

Molte grazie a tutti coloro che ci accompagnano in questo percorso!

Martin e Raui di MaraDocs.

MaraDocs crea PDF ottimizzati da documenti dei clienti

Chi riceve immagini invece di PDF dai clienti non deve più convertire manualmente. MaraDocs si occupa dell'intero processo - velocemente, in modo affidabile e senza perdita di qualità.

• Importare semplicemente email complete
• tutte le immagini vengono automaticamente analizzate ed estratte
• come risultato si ottengono PDF ottimizzati

MaraDocs - come se il cliente avesse usato un'app scanner.

🚀 Prova ora: Prova MaraDocs gratuitamente