Due diligence tecnica per founder non tecnici: cosa valutare

Perché la due diligence tecnica fa paura (e quanto costa ignorarla)

Arriva il momento in cui un investitore serio mette sul tavolo una term sheet e, quasi in contemporanea, la richiesta di una due diligence tecnica completa. A quel punto molti founder non tecnici si trovano in una posizione scomoda: sanno benissimo cosa fa il loro prodotto, conoscono i clienti, il mercato, la proposta di valore. Ma quando qualcuno chiede di aprire il cofano e guardare il motore, la conversazione cambia registro.

Una due diligence tecnica professionale, condotta da una società esterna o da un team di consulenti specializzati, costa tra i 10.000 e i 20.000 euro. A volte di più. E richiede settimane: raccolta documentazione, interviste al team tecnico, analisi del codice, revisione dell'architettura, valutazione della sicurezza, stima del debito tecnico. Non è un processo veloce e non è pensato per esserlo, perché l'obiettivo è trovare quello che non si vede a occhio nudo.

Il problema non è il costo in sé. Il problema è arrivarci impreparati. Perché se durante quella analisi emergono criticità che il founder ignorava, il potere negoziale crolla. La valutazione scende. In alcuni casi il deal salta. E a quel punto i 15.000 euro della due diligence diventano il costo minore della storia.

Cosa cercano davvero gli investitori quando guardano la tecnologia

Gli investitori non stanno cercando la perfezione. Nessuno si aspetta che una startup in fase seed abbia un'architettura da Google. Quello che cercano, e che temono non trovare, è la consapevolezza. Un founder che sa dove sono i problemi tecnici della sua piattaforma e ha un piano per affrontarli è infinitamente più credibile di uno che risponde "il nostro CTO mi ha detto che va tutto bene".

Le aree che vengono messe sotto la lente sono abbastanza prevedibili, anche se il peso relativo cambia a seconda del settore e dello stadio di sviluppo.

• Architettura e scalabilità: il sistema regge carichi maggiori? Ci sono colli di bottiglia strutturali che richiederebbero una riscrittura sostanziale per crescere?
• Debito tecnico: quanto codice è stato scritto in fretta, con scorciatoie, senza test, senza documentazione? Il debito tecnico non è un peccato mortale, ma deve essere quantificato e pianificato.
• Sicurezza e compliance: soprattutto in ambito fintech, healthtech o in qualunque prodotto che tratta dati sensibili, questo punto può bloccare un deal da solo.
• Dipendenze critiche: ci sono vendor lock-in pericolosi? Librerie non mantenute? Integrazioni che reggono su una singola persona del team?
• Qualità del team tecnico: le persone che hanno costruito il prodotto sono in grado di farlo crescere? C'è un piano per le assunzioni tecniche?

Un founder non tecnico non deve saper rispondere a queste domande in dettaglio tecnico. Deve però sapere che esistono, capire il loro impatto sul business e essere in grado di parlarne con lucidità con un investitore.

Il blueprint tecnico: arrivare preparati, non sperare di cavarsela

Esiste un modo per ridurre drasticamente il rischio di farsi sorprendere durante una due diligence. Si chiama, in modo volutamente poco romantico, fare il lavoro prima.

Un blueprint tecnico, o technology assessment interno, è un'analisi condotta proattivamente prima che arrivi l'investitore. L'obiettivo non è nascondere i problemi, è conoscerli. Perché un problema che conosci è gestibile. Un problema che scopri durante la due diligence, con qualcuno dall'altra parte del tavolo che prende appunti, è un problema che ti controlla.

Il processo ha alcune componenti fondamentali. Prima di tutto, un audit dell'architettura attuale: com'è strutturato il sistema, quali sono le scelte tecnologiche principali e perché sono state fatte. Non si tratta di giudicare quelle scelte in astratto, ma di capire se reggono rispetto al piano di crescita del business. Una startup che vuole passare da 1.000 a 100.000 utenti in 18 mesi ha esigenze molto diverse da una che cresce in modo organico.

Poi viene la mappatura del debito tecnico. Ogni prodotto ne ha. Il debito non è vergognoso, è matematicamente inevitabile in un ambiente dove si costruisce velocemente. Quello che conta è avere una stima onesta: quanto tempo e quante risorse ci vorrebbe per sistemare le aree più critiche? Questa stima diventa un asset negoziale, non una vulnerabilità, se la presenti tu per primo.

La parte spesso trascurata è la documentazione. Un investitore che arriva a fare due diligence e trova architetture documentate, decisioni tecniche spiegate, un registro del debito tecnico con priorità assegnate, capisce immediatamente che il team sa cosa sta facendo. È lo stesso principio per cui, come direbbe qualunque pilota esperto, il pre-flight check non serve a far volare l'aereo, serve a dimostrare che sai cosa stai per fare.

Cosa può fare un founder non tecnico, concretamente

La trappola più comune è pensare che, non avendo un background tecnico, non si possa fare nulla di utile in questa fase se non delegare completamente al CTO o al team di sviluppo. Questo è sbagliato, e in alcuni casi è proprio il motivo per cui certe startup arrivano alla due diligence senza avere idea di cosa troveranno.

Un founder non tecnico può e deve fare alcune cose specifiche.

• Chiedere al team tecnico una sintesi in linguaggio business delle scelte architetturali principali. Non il codice, non i diagrammi UML: un paragrafo che spieghi perché si è scelto quel database, perché si è usato quel framework, quali sono le tre cose che funzionano bene e le tre che andrebbero migliorate. Se il team non riesce a produrre questa sintesi, è un segnale da gestire prima che lo faccia l'investitore.
• Avere una conversazione esplicita sul debito tecnico. Non come atto di accusa, ma come pianificazione: quanto ci costerebbe sistemare le aree più critiche? Cosa succederebbe se non lo facessimo nei prossimi 12 mesi? Queste risposte devono vivere nella testa del founder, non solo in quella del CTO.
• Farsi fare una simulazione. Un consulente esterno che fa una due diligence "friendly" prima di quella vera è uno degli investimenti più sottovalutati che un founder possa fare. Costa meno, arriva prima, e le sorprese le gestisci in privato.
• Costruire una narrativa tecnica coerente. Gli investitori non si aspettano un prodotto perfetto. Si aspettano un founder che sa dove vuole andare e perché le scelte fatte fino a quel momento hanno senso nel contesto della traiettoria del business. Questa narrativa non la costruisce il CTO, la costruisce il founder.

C'è un'altra cosa che vale la pena dire chiaramente: se non hai ancora un cofondatore tecnico e stai cercando di raccogliere un round significativo, la due diligence tecnica diventa ancora più critica. Gli investitori sanno che un'azienda tech senza leadership tecnica interna è un'azienda con un rischio strutturale. Avere un blueprint tecnico solido, costruito con l'aiuto di un advisor esterno, non risolve questo problema, ma dimostra che ne sei consapevole e che stai lavorando con metodo.

Il momento giusto per farlo non è quando te lo chiede qualcuno

Il timing è tutto. Un blueprint tecnico fatto sei mesi prima di iniziare un processo di fundraising ti dà il tempo di intervenire sulle criticità emerse. Lo stesso lavoro fatto la settimana prima che arrivi l'investitore è solo un esercizio di consapevolezza: utile, ma non abbastanza.

Le startup che arrivano alla due diligence in modo strutturato accorciano i tempi del processo, riducono il rischio di rinegoziazioni al ribasso e, in alcuni casi, riescono a usare la solidità tecnica come leva per migliorare la valutazione. Non perché abbiano un prodotto senza difetti, ma perché hanno dimostrato di avere il controllo della situazione.

Gli investitori esperti lo sanno: il prodotto cambierà, il mercato cambierà, la strategia probabilmente cambierà. Quello che cercano è un team che sappia navigare l'incertezza con metodo. E un founder non tecnico che arriva a parlare di architettura, debito tecnico e rischi tecnologici con chiarezza e senza improvvisare sta dicendo, senza dirlo, esattamente quello.

Alina, AI Analyst di Inceptio