Il team che costruisce Quido

Dietro Quido ci sono persone che vengono da finanza e da tecnologia, con un'idea precisa: il lavoro ripetitivo si automatizza, il giudizio no.

Nella foto ci sono Francesco Calia, Lorenzo Bergadano, Ilaria Bolla, Gianluca Maiorino, Emilio Crespi, Mattia Cossa e Andrea Losavio. Non è il team al completo: quel giorno mancava Julian Pichler, Founder Associate, e mancava chi non era disponibile. Il gruppo, oltretutto, si sta allargando: la fotografia racconta un momento, non il perimetro dell'azienda.

Chi c'è, e di che cosa si occupa

Francesco Calia, CEO, guida strategia, prodotto e clienti. Lorenzo Bergadano, CTO, è responsabile della tecnologia e dell'architettura della piattaforma. Sono i due fondatori di Quido.

Ilaria Bolla, Lead Data Scientist, guida i modelli AI e la qualità del dato dietro le analisi.

Gianluca Maiorino, Founder Engineer, sviluppa il motore di analisi, dal dato grezzo al report.

Emilio Crespi, Founder Engineer, costruisce le pipeline dati e le integrazioni della piattaforma.

Mattia Cossa, Customer Success Engineer, affianca i clienti dall'onboarding all'operatività quotidiana.

Andrea Losavio, Frontend Developer, cura interfaccia ed esperienza utente della piattaforma.

Julian Pichler, Founder Associate, supporta CEO e team su operations e sviluppo del business. Non era presente il giorno della fotografia.

L'idea che tiene insieme il gruppo

La missione dichiarata dall'azienda è liberare analisti e partner dal lavoro ripetitivo, e riportare il tempo dove crea valore: la tesi di investimento, la relazione sul deal, la decisione.

Detta così suona come una frase da sito. Nella pratica è un criterio operativo, e si applica ogni volta che si decide che cosa costruire.

Il lavoro di chi opera nel private capital si divide in due categorie. La prima è raccolta e normalizzazione: trovare l'azienda, recuperare i bilanci depositati, riclassificarli, ricostruire l'assetto proprietario, mettere in fila le notizie, impaginare tutto in un documento leggibile. È lavoro necessario, richiede attenzione e non contiene giudizio. La seconda è interpretazione: capire se il margine tiene, se il confronto con i comparabili regge, se la struttura societaria nasconde una complicazione, se vale la pena procedere.

Ogni funzionalità della piattaforma viene misurata su questa distinzione. Se assorbe lavoro della prima categoria, ha senso costruirla. Se prova a sostituire la seconda, non si costruisce — non per prudenza, ma perché sarebbe un prodotto che nessun professionista serio userebbe per il lavoro che porta la propria firma.

Come è diviso il lavoro, dal dato grezzo al report

I ruoli elencati sopra sembrano generici finché non li si mette in fila. Messi in fila, descrivono un percorso: quello che un'informazione compie da quando è un documento depositato a quando è una riga in un report che qualcuno discute in riunione.

All'inizio ci sono le pipeline dati e le integrazioni. È la parte meno visibile e la più determinante: portare dentro il materiale, tenerlo aggiornato, collegarlo agli strumenti che i clienti già usano. Se questa parte è fragile, tutto ciò che sta a valle eredita la fragilità, e nessuna interfaccia elegante la compensa.

Poi c'è il motore di analisi, che trasforma il dato grezzo in report. È il punto in cui le voci di bilancio vengono ricondotte a uno schema comune, i confronti diventano possibili e il materiale assume la forma in cui verrà effettivamente usato.

Accanto ci sono i modelli e la qualità del dato. Sono due facce dello stesso problema, ed è la ragione per cui stanno insieme in un unico ruolo: un modello applicato a un dato sporco produce un errore convincente, che è la categoria di errore peggiore. La qualità del dato non è una fase di controllo alla fine, è un vincolo che precede il modello.

Poi c'è l'interfaccia. Un'analisi corretta che richiede sei clic e una ricerca nella pagina per essere trovata, in pratica non esiste. Il lavoro sull'esperienza d'uso, su un prodotto professionale, non è cosmetico: decide quante volte al giorno lo strumento viene aperto.

Alla fine c'è il customer success. È il ruolo che chiude il ciclo: accompagna il cliente dall'onboarding all'operatività quotidiana e riporta dentro l'azienda ciò che nella realtà d'uso non funziona. È anche la ragione per cui setup, formazione e supporto sono inclusi nel canone invece di essere fatturati a parte: se l'adozione è un costo aggiuntivo, chi ha comprato lo strumento smette di estenderlo.

Sopra tutto questo stanno le due responsabilità dei fondatori — strategia, prodotto e clienti da un lato, tecnologia e architettura dall'altro — che esistono per tenere quel percorso coerente da un capo all'altro. È una coerenza che non si mantiene da sola: ogni anello della catena, lasciato a sé, tende a ottimizzare il proprio pezzo, e la somma di cinque ottimizzazioni locali non è un prodotto coerente.

Finanza e tecnologia nella stessa stanza

La composizione del team non è casuale, ed è probabilmente il fattore che più incide sul prodotto.

Un gruppo esclusivamente tecnico, per quanto bravo, costruisce ciò che è elegante da costruire. Su un prodotto verticale l'eleganza non è il criterio: il criterio è se una cosa toglie mezz'ora al giorno a una persona che oggi la spende a ricopiare numeri. Riconoscere quella mezz'ora richiede di conoscere il mestiere dall'interno.

Un gruppo esclusivamente di dominio, all'opposto, tende a chiedere la digitalizzazione del processo esistente: lo stesso lavoro di prima, con qualche schermata in mezzo. È il modo più affidabile per costruire software che nessuno usa, perché non cambia il costo di nulla.

Il valore sta nell'attrito fra le due prospettive. È un attrito produttivo e va mantenuto, non risolto: nel momento in cui una delle due parti smette di obiettare, il prodotto comincia a somigliare a chi lo costruisce invece che a chi lo usa.

Che cosa significa "Founder Engineer"

È un titolo che ricorre nel team e che vale la pena spiegare, perché fuori dall'ambiente non dice molto.

Non indica una quota societaria né un'anzianità. Indica un modo di lavorare: la persona non riceve una specifica da implementare, riceve un problema da risolvere, e la definizione di che cosa vada costruito fa parte del suo lavoro.

Ha senso in un contesto preciso — un gruppo piccolo su un dominio complesso, dove la distanza fra chi decide e chi costruisce sarebbe il collo di bottiglia principale. Ha molto meno senso in un'organizzazione grande, dove la stessa autonomia produrrebbe divergenza.

Il rovescio della medaglia è che richiede alle persone di capire il mestiere del cliente, non solo la tecnologia. Un ingegnere che non sa perché la riclassificazione di un bilancio conta prenderà decisioni ragionevoli e sbagliate.

Il percorso fino a qui

A febbraio Quido ha chiuso un aumento di capitale da 1,6 milioni di euro, guidato da Vertis Sgr con la partecipazione di Cdp Venture Capital Sgr tramite il programma Frontech, di SevenData, di Edrom e di un pool di business angel e partner attivi nella consulenza strategica e nel private equity italiano. Il racconto dell'operazione è nell'articolo dedicato all'aumento di capitale.

Un round serve a molte cose, e la più immediata è questa: permette di costruire il gruppo che il prodotto richiede, invece del gruppo che si riesce a permettersi. Su un verticale è una differenza sostanziale, perché le competenze che servono — dominio finanziario, ingegneria dei dati, modelli, prodotto — non si trovano concentrate in poche persone e non si comprano una alla volta.

Che cosa fa la piattaforma su cui il team lavora

Per collocare i ruoli descritti sopra, vale la pena ricordare che cosa il team costruisce.

Quido automatizza analisi finanziarie per private equity, investment banking e advisory. Concretamente:

• Ricerca multicriterio su milioni di aziende italiane, per settore, dimensione, geografia e segnali finanziari, con filtri e risultati ordinati per rilevanza.
• Scheda azienda con bilanci riclassificati, KPI, confronto con i peer, notizie e struttura societaria, generata automaticamente e aggiornata.
• Agente AI che ragiona sui dati della piattaforma e restituisce analisi di settore, shortlist di target o memo di sintesi, con le fonti.
• Deal flow condiviso, con stati personalizzati, filtri, assegnazione e follow-up.
• Report automatici — one-pager, riclassificati e memo — nel formato dello studio.

I dati arrivano da fonti pubbliche italiane — Camera di Commercio e bilanci depositati — e da dati proprietari aggiornati in tempo reale, con ogni informazione tracciabile alla fonte.

Tre vincoli che il team si è dato

Ci sono decisioni che non si rinegoziano a ogni funzionalità, e che spiegano buona parte di come il prodotto è fatto.

La tracciabilità viene prima della sintesi. Ogni informazione deve poter essere ricondotta alla fonte da cui proviene. Non è una scelta di conformità: è la condizione perché il materiale prodotto possa entrare in un documento discusso in un investment committee. Un numero non riconducibile a una fonte non è un'approssimazione accettabile — è materiale inutilizzabile, e costringe qualcuno a rifare la verifica a mano.

L'output nasce nel formato in cui verrà usato. Uno strumento che produce ottime analisi da cui poi bisogna ricopiare dentro il template dello studio sposta il lavoro invece di eliminarlo. È il motivo per cui i report escono già nel formato dello studio e non in un formato proprietario da convertire.

Il dato dei clienti non alimenta i modelli. L'infrastruttura è europea, i dati sono cifrati at rest e in transit, il trattamento è conforme al GDPR, e il materiale dei clienti non viene usato per addestrare i modelli. È il primo argomento su cui arrivano domande da chi lavora su operazioni riservate, ed è giusto che sia una risposta ferma e non una configurazione.

Come un'osservazione di un cliente diventa una modifica

Il percorso descritto sopra vale nella direzione del dato. Ce n'è un secondo, che corre nella direzione opposta, e su un prodotto verticale conta altrettanto.

Comincia da un'osservazione raccolta durante l'uso: un passaggio che richiede tre clic di troppo, un confronto che manca, un report che qualcuno esporta e poi sistema a mano prima di mandarlo. Sono segnali piccoli e disomogenei, e quasi mai arrivano formulati come richieste: arrivano come commenti a margine di tutt'altro.

Il ruolo che sta più vicino a quel flusso è il customer success, perché è la persona che vede lo strumento in mano a chi lo usa davvero, nell'operatività quotidiana e non in una sessione di prova. Da lì l'osservazione deve arrivare a chi può agire: l'interfaccia se il problema è di percorso, il motore di analisi se il problema è nel contenuto del report, le pipeline se il problema è a monte, nel dato.

Il punto delicato è la traduzione. Un cliente descrive il sintomo, non la causa — "questo report lo devo sistemare ogni volta" può voler dire che manca una voce, che l'ordine è sbagliato, che il formato non corrisponde allo standard del suo studio o che quel documento serve a una cosa diversa da quella per cui è stato pensato. Sono quattro problemi diversi con quattro soluzioni diverse, e sbagliare la traduzione produce una modifica che non risolve nulla.

È anche la ragione pratica per cui conta tenere corta la catena: quella traduzione la fanno persone che si parlano, non tre passaggi di documenti — ed è la prima cosa da difendere man mano che il gruppo si allarga.

La qualità del dato è un ruolo, non un controllo finale

Vale la pena tornare su un punto, perché è il più controintuitivo per chi guarda il prodotto da fuori.

L'istinto suggerisce che la qualità del dato sia una verifica: si costruisce la pipeline, si calcola l'analisi, e alla fine qualcuno controlla che i numeri tornino. In un prodotto che lavora su bilanci depositati di migliaia di società questo approccio non regge, per un motivo semplice: gli errori che contano non sono quelli evidenti.

Un dato mancante si vede. Un dato palesemente assurdo si vede. Quello che non si vede è il dato plausibile e sbagliato: una voce ricondotta allo schema comune in modo ragionevole ma non corretto per quel particolare tipo di società, una classificazione settoriale formale che non corrisponde all'attività reale, una catena di controllo ricostruita bene per il 95% dei casi e male per una configurazione societaria meno frequente.

Nessuno di questi errori fa scattare un allarme. Producono un'analisi che sembra giusta, e vengono scoperti — se vengono scoperti — da un professionista che conosce quella società e si accorge che qualcosa non torna. È il momento peggiore in cui scoprirli, perché il danno non è il numero sbagliato: è la fiducia nello strumento.

Da qui discende che la qualità del dato deve stare all'inizio del percorso e non alla fine, dentro il ruolo che governa i modelli e non accanto ad esso. Ed è la ragione per cui la tracciabilità non è solo una garanzia per il cliente: è anche lo strumento con cui, internamente, un dato sospetto si risale fino alla fonte invece di essere corretto a mano.

Che cosa richiede questo lavoro alle persone

Non è un elenco di requisiti per candidarsi — non è quello lo scopo di questo articolo. È l'osservazione di che cosa il lavoro chiede, ricavata da come è strutturato.

Capire il mestiere del cliente. Vale per tutti i ruoli, anche per quelli più lontani dal cliente. Chi costruisce una pipeline dati e non sa perché la riclassificazione di un bilancio conta prenderà decisioni ragionevoli e sbagliate, e le prenderà in un punto del percorso in cui nessuno le rivedrà.

Tollerare il lavoro poco spettacolare. La parte del prodotto che genera più valore per il cliente è anche quella meno visibile: normalizzare, riconciliare, tenere aggiornato. È lavoro lento, difficile da raccontare e impossibile da saltare.

Accettare che il giudizio resti fuori. C'è una tentazione ricorrente, in chiunque costruisca strumenti di analisi, di fare un passo in più e suggerire la conclusione. È esattamente il passo che rende il prodotto inutilizzabile per un professionista che deve firmare quella conclusione. Fermarsi un passo prima è una disciplina, non un limite tecnico.

Un gruppo che cresce, e che cosa va protetto mentre cresce

Il team si sta allargando. È la conseguenza naturale di quello che il prodotto richiede: le competenze necessarie — dominio finanziario, ingegneria dei dati, modelli, prodotto, relazione con i clienti — non stanno in poche persone.

La domanda interessante non è quindi quanto si diventa grandi, ma che cosa si rischia di perdere per strada. Perché un gruppo piccolo ha vantaggi reali, e quasi tutti sono fragili.

Il primo è che tutti sanno che cosa stanno facendo gli altri, e nessuno deve chiedere il permesso per parlare con un cliente. La distanza fra un'osservazione raccolta durante un onboarding e una modifica al prodotto si misura in giorni, non in trimestri. È un vantaggio che non si perde di colpo: si consuma un passaggio alla volta, quasi sempre per ragioni sensate.

Il secondo è la sovrapposizione fra i ruoli. I confini descritti sopra sono meno rigidi di quanto l'elenco faccia pensare — chi costruisce le pipeline capisce il motore di analisi, chi cura l'interfaccia sa che cosa succede a monte. In un gruppo piccolo questa sovrapposizione nasce da sola, semplicemente perché non c'è abbastanza gente per specializzarsi del tutto. Più avanti va coltivata apposta.

Crescere serve, e serve presto. Ma vale la pena essere espliciti su che cosa si sta cercando di non perdere mentre succede: la vicinanza fra chi usa lo strumento e chi lo costruisce, che è la ragione per cui il prodotto assomiglia al mestiere invece che a sé stesso.

Chi non c'è nella foto

Il team è più grande di quello che si vede, e sta continuando a crescere. Alla fotografia manca Julian Pichler, Founder Associate, e mancano le altre persone che quel giorno non erano disponibili: è giusto dirlo invece di lasciare che l'immagine parli per l'intera azienda.

L'elenco completo, aggiornato, con nomi e ruoli, è pubblicato sulla pagina Chi siamo. È la fonte da guardare per sapere chi c'è oggi in Quido: questa pagina cambia quando cambia il team, un articolo no.

Che cosa questo articolo non è

Qualche delimitazione, come sempre.

Non è un annuncio di assunzioni né di posizioni aperte.

Non è un annuncio di prodotto: le funzionalità citate sono quelle già disponibili alle organizzazioni clienti.

Non è un organigramma: i ruoli descritti raccontano come è diviso il lavoro, non una struttura gerarchica formale.

Non è la fotografia definitiva del team: per la composizione aggiornata vale la pagina Chi siamo, non questo testo.

Domande frequenti

Chi ha fondato Quido?

Francesco Calia e Lorenzo Bergadano. Francesco Calia è CEO e guida strategia, prodotto e clienti; Lorenzo Bergadano è CTO ed è responsabile della tecnologia e dell'architettura della piattaforma.

Chi sono le persone nella foto?

Francesco Calia, Lorenzo Bergadano, Ilaria Bolla, Gianluca Maiorino, Emilio Crespi, Mattia Cossa e Andrea Losavio. Non è il team al completo: quel giorno mancava Julian Pichler, Founder Associate, insieme alle altre persone non disponibili.

Il team sta crescendo?

Sì. Il gruppo si sta allargando su tutte le competenze che il prodotto richiede. Questo articolo non elenca posizioni aperte: per sapere chi c'è oggi in Quido, la fonte aggiornata è la pagina Chi siamo.

Dove si trova l'elenco aggiornato del team?

Sulla pagina Chi siamo, che riporta nomi, ruoli e responsabilità di tutte le persone che lavorano in Quido.

Che cosa significa "Founder Engineer"?

È un modo di lavorare più che un titolo: la persona riceve un problema da risolvere invece di una specifica da implementare, e la definizione di che cosa costruire fa parte del suo lavoro.

Di che cosa si occupa Quido?

Automatizza analisi finanziarie per private equity, investment banking e advisory: ricerca sulle aziende, analisi, reportistica e dati aggiornati in un'unica piattaforma, con ogni informazione tracciabile alla fonte.

Da dove vengono i dati?

Da fonti pubbliche italiane — Camera di Commercio e bilanci depositati — e da dati proprietari aggiornati in tempo reale, con ogni informazione tracciabile alla fonte.

I dati dei clienti vengono usati per addestrare i modelli?

No. L'infrastruttura è europea, i dati sono cifrati at rest e in transit, il trattamento è conforme al GDPR e i dati dei clienti non alimentano l'addestramento dei modelli.

Quanto tempo serve a un nuovo cliente per partire?

In genere un team è operativo in meno di una settimana. Setup, formazione e supporto sono inclusi nel canone, ed è la parte seguita dal customer success.

Quido si integra con gli strumenti già in uso in uno studio?

Sì: CRM, sistemi di dealflow e suite Office, con export in PDF, Word ed Excel e un'API REST per le integrazioni su misura. È la parte del prodotto che vive nelle pipeline e nelle integrazioni.

Chi può accedere alla piattaforma?

L'accesso è riservato alle organizzazioni clienti. Chi volesse valutarla può richiedere una demo dal sito.

In sintesi

Il gruppo che costruisce Quido mette insieme finanza e tecnologia attorno a una divisione del lavoro che segue il percorso del dato: pipeline e integrazioni, motore di analisi, modelli e qualità del dato, interfaccia, customer success — con le due responsabilità dei fondatori a tenere il percorso coerente.

Il criterio che orienta le scelte è sempre lo stesso: automatizzare il lavoro ripetitivo e lasciare intatto il giudizio, perché è lì che il mestiere di chi usa la piattaforma continua a esistere.

L'elenco aggiornato delle persone è sulla pagina Chi siamo. Il contesto sull'azienda e sugli investitori è nell'articolo sull'aumento di capitale da 1,6 milioni di euro, e le domande su fonti, sicurezza, prezzi e integrazioni hanno risposta nella pagina FAQ.