Lexroom è una piattaforma che usa l’intelligenza artificiale per rivoluzionare la ricerca legale. Invece di far perdere ore agli avvocati in database infiniti di giurisprudenza, il loro sistema analizza documenti, trova precedenti rilevanti e genera risposte precise in tempo reale.

Il loro target? Studi legali e professionisti che vogliono lavorare più velocemente senza compromettere l’accuratezza.

TL;DR - Key Results

• €500K pre-seed → €16M seed round in meno di 2 anni
• Company size: 3 → 15
• Autonomia operativa completa dopo 6 mesi di affiancamento

Quando il problema non è la tecnologia

Mi ricontatta Paolo a fine 2023. Ci eravamo conosciuti mesi prima durante il mio periodo in zerocento, avevamo creato una connessione, e quando mi sono messo in proprio come Fractional CTO siamo tornati a parlare.

Lexroom aveva tutto quello che serve per partire bene: tre co-founder forti, reduci dall’acceleratore Vento di Torino con un MVP già in sviluppo e prime validazioni di mercato.

C’era Andrea, il loro CTO, fortissimo sulla parte AI (il cuore tecnologico), poi Paolo (CEO) che si occupava di prodotto e Martina prontissima sulla parte commerciale.

Ma la cosa che ho capito subito nella prima call è stata questa: non avevano un problema di competenze tecniche, avevano un problema di focus.

Stavano sviluppando feature senza una direzione, non avevano una metodologia chiara per decidere cosa costruire e quando. E soprattutto, avevano risorse limitate (tempo, budget, persone) e rischiavano di bruciarle sulle cose sbagliate.

“Abbiamo bisogno di qualcuno che ci aiuti a capire su cosa concentrarci davvero” mi ha detto Paolo in quella prima riunione.

Non cercavano un CTO sostitutivo. Cercavano qualcuno che portasse disciplina, metodologia e capacità di dire NO quando serviva.

Il NO che ha cambiato la traiettoria

Il primo mese l’ho passato ad analizzare il loro stack, la roadmap (o meglio, la lista infinita di “vorremmo fare”), e a parlare con tutti e tre i founder per capire dove volevano arrivare.

La prima grande decisione è arrivata subito, ed è stata la più difficile.

Andrea e il team volevano rifare completamente il backend e il motore di intelligenza artificiale.

Non erano soddisfatti dell’accuratezza delle risposte, e nel settore legale questo è un problema critico. Gli avvocati non perdonano errori o imprecisioni.

Tecnicamente? Avevano ragione. Il motore poteva essere migliore, l’architettura più pulita, il tutto più scalabile.

Ma strategicamente? Era il momento sbagliato.

Non avevano ancora una base clienti solida per validare che il problema fosse davvero il motore AI o altro.

Non avevano le risorse economiche per permettersi 3-4 mesi di sviluppo senza rilasciare valore.

E soprattutto, c’erano feature che i primi clienti chiedevano a gran voce e che potevano sbloccare nuove vendite.

Il compromesso che abbiamo trovato è stato questo: rimandare il refactoring, concentrarsi sulle funzionalità richieste dai clienti per validare il mercato, e costruire le fondamenta metodologiche che avrebbero reso il futuro refactoring più facile e veloce.

Non è stata una conversazione facile… Dire a un CTO brillante che la sua preoccupazione tecnica legittima deve aspettare richiede tatto, fiducia reciproca e soprattutto dati.

Ma Andrea ha capito la logica, e insieme abbiamo scelto il percorso che avrebbe dato più valore nel breve termine senza compromettere il lungo.

Costruire la macchina, non solo il prodotto

Una volta presa quella decisione strategica, ci siamo concentrati su due fronti paralleli: team building e metodologia di prodotto.

Sul team, ho portato a bordo due sviluppatori e un product designer freelance selezionati dal mio network. Non stavamo costruendo un team permanente in quella fase, ma persone che potessero accelerare lo sviluppo dell’MVP mantenendo qualità e velocità.

Ogni persona è passata attraverso un processo di selezione.

Volevo profili che si integrassero bene con la loro visione tecnica, non che la sostituissero.

Sul fronte metodologia, abbiamo fatto un lavoro più profondo di quanto sembri.

Prima del mio arrivo, Lexroom lavorava senza una roadmap strutturata…

Le feature requests arrivavano da clienti, investitori, founder stessi, e venivano aggiunte a una lista crescente senza prioritization chiara.

Ho introdotto una metodologia Kanban classica ma applicata con disciplina:

• Backlog refinement settimanale dove discutevamo tutte le nuove richieste
• Prioritization basata su impatto business vs effort tecnico, sempre confrontandoci con Martina sulla parte commerciale
• Sprint chiari con obiettivi misurabili e review a fine ciclo
• Retrospettive per migliorare il processo stesso

Abbiamo fatto workshop insieme, sessioni hands-on dove tutti i founder erano coinvolti. Volevo che Paolo e Martina capissero il “perché” dietro le scelte tecniche, e che Andrea capisse i vincoli e le opportunità di business.

Il risultato? In 5 mesi siamo passati da “facciamo tutto” a “facciamo questo, poi questo, poi vediamo”.

E quella chiarezza ha sbloccato tutto il resto.

I risultati parlano da soli

Dopo circa 3-4 mesi dall’inizio della nostra collaborazione, Lexroom ha chiuso un pre-seed da €500K.

Non ho partecipato direttamente al round, ma il lavoro fatto insieme (la roadmap chiara, il team strutturato, la disciplina di prodotto) ha reso il tutto più solido e la due diligence più semplice.

Ma il risultato vero è arrivato dopo.

A settembre 2025, Lexroom ha chiuso un round da €16M.

Oggi hanno clienti paganti, un team in crescita costante e un’operatività che gira senza bisogno del mio intervento continuo.

Mi scrivono ancora, per esempio qualche settimana fa mi hanno chiesto un parere su un profilo tech in fase di colloquio, ma sono completamente autonomi. E questa, per me, è la metrica più importante.

Cosa ho imparato da loro

Lexroom è stata una delle prime startup che ha creduto in me come Fractional CTO.

E per questo ci tengo particolarmente.

Ma quello che mi ha colpito di più è stata la capacità di ascoltare e di fidarsi.

Quando ti dico che dire NO al refactoring non è stata una conversazione facile, parlo di founder che avevano una visione tecnica forte e che dovevano accettare di rimandare qualcosa che ritenevano importante.

Quel livello di fiducia reciproca ha reso possibile tutto il resto.

Ho imparato che il miglior modo per lavorare con founder competenti non è sostituirli o sovrapporsi, ma affiancarli con una prospettiva complementare. Andrea sapeva di AI più di quanto io saprò mai, Paolo aveva una visione di prodotto cristallina e Martina capiva il mercato meglio di chiunque altro.

Il mio ruolo non era insegnare loro a fare il loro lavoro. Era portare una disciplina esterna, un framework di decisione e la capacità di dire “questo sì, questo no, questo dopo”.

E alla fine, è proprio questo che ha fatto la differenza.

I fattori decisivi

• Il focus batte la perfezione, sempre. Dire NO a un refactoring tecnicamente giusto ma strategicamente prematuro ha salvato mesi di sviluppo e sbloccato crescita. La tecnologia segue il business, mai il contrario.
• La metodologia è un vantaggio competitivo sottovalutato. Nelle fasi early-stage, avere una roadmap chiara e una disciplina di prioritization vale quanto avere un buon prodotto. Senza struttura, anche i team brillanti bruciano risorse.
• Il Fractional CTO non sostituisce nessuno, potenzia. Anche con un CTO interno competente, un Fractional può portare capacità complementari (team building, metodologia, decisioni strategiche) che accelerano la crescita senza creare conflitti.

Lexroom oggi ha quello che poche startup raggiungono in così poco tempo: un prodotto validato, clienti paganti, €16M in cassa e un team che sa esattamente dove sta andando.

Per i founder che stanno leggendo

Le risorse limitate sono il vostro vero vantaggio competitivo. Vi obbligano a fare scelte difficili, a dire NO, a concentrarvi solo su quello che conta davvero. Ma questo funziona solo se avete una metodologia per decidere cosa conta.

Avere competenze tecniche interne non significa non aver bisogno di supporto esterno. Se avete un CTO forte ma sentite che manca focus, disciplina o capacità di scalare il team, un Fractional CTO può essere il complemento che sblocca tutto senza creare sovrapposizioni.

Il momento giusto per fare le cose giuste esiste davvero. Rifare il backend può aspettare. Scalare l’infrastruttura può aspettare. Quello che non può aspettare è validare il mercato, acquisire clienti e costruire una macchina di prodotto che gira senza caos.

La domanda non è “cosa dobbiamo costruire?” ma “cosa dobbiamo costruire adesso?”