Audit del codice prima dell'investimento: cosa si verifica e come prepararsi

Un audit del codice prima dell'investimento è una verifica indipendente del software di un'azienda, svolta prima che il denaro cambi mani. Controlla se il codice funziona, se è sicuro e manutenibile, e se l'azienda possiede davvero quello che ha costruito e può utilizzarlo. Investitori e acquirenti lo commissionano per dare un prezzo al rischio. I fondatori lo commissionano prima, così che nulla nel rapporto li colga di sorpresa.

Questa guida copre entrambi i lati. Spiega cosa guarda chi esamina il codice, come si svolge il lavoro, cosa devono preparare i fondatori, quanto tempo richiede e cosa fare con i rilievi. Tocca anche l'aspetto giuridico svizzero, dove la titolarità e le licenze contano quanto la qualità del codice.

In breve

• Un audit del codice prima dell'investimento verifica quattro cose: architettura, qualità del codice, sicurezza e diritto legale di utilizzare il software (titolarità e licenze open source).
• In Svizzera, legal due diligence on software focuses on ownership and licences, mentre l'analisi più approfondita del codice rientra di norma nella verifica tecnica.
• I fondatori che si sottopongono prima a un audit proprio controllano il racconto: sistemano i problemi poco costosi e spiegano quelli costosi prima che li scopra un investitore.
• Prepara l'accesso ai repository, una panoramica dell'architettura, un elenco di dipendenze e licenze e la prova che ogni persona che ha contribuito ha ceduto i propri diritti.
• Suddividi i rilievi in tre gruppi: da sistemare subito, da sistemare con i soldi dell'investitore e da accettare con un piano.

Perché gli investitori chiedono un audit del codice

Il software raramente è solo codice. Il suo valore è legato ai diritti: chi lo possiede, chi può copiarlo e quali terzi potrebbero rivendicarne una parte. Walder Wyss, studio legale svizzero, descrive questo legame nella sua legal due diligence on software focuses on ownership and licences. Capire la tecnologia ti dice quali diritti dovrebbero esistere. Esaminare licenze, titolarità, contenziosi e regolamentazione verifica poi se quei diritti sono utilizzabili e solidi.

Per questo un audit è molto più di un controllo di qualità. Un investitore vuole sapere tre cose:

1. Funziona come dichiarato? Una demo può nascondere parecchio. Il codice mostra cosa c'è davvero.
2. Reggerà la crescita? Un prodotto che gestisce 200 utenti può crollare con 20'000, e ricostruirlo costa soldi che dovrà mettere l'investitore.
3. È davvero dell'azienda? Codice scritto da un freelance senza cessione dei diritti, o costruito su una libreria con licenza restrittiva, può ridurre ciò che l'azienda possiede.

Per un fondatore, lo stesso audit risponde a una domanda più silenziosa: quanta parte del finanziamento servirà a sistemare il passato invece che a costruire il futuro?

Cosa esamina un audit del codice

Un buon audit è una valutazione dello stato di salute, non una caccia ai bug. Chi lo svolge guarda il sistema da più angolazioni, e ognuna corrisponde a un rischio che interessa all'investitore.

Architettura e scalabilità

Chi esamina il codice legge come è messo insieme il sistema: servizi, basi di dati, hosting, code, API di terzi. Si chiede se il progetto sia adatto alla fase in cui si trova il prodotto. Un prodotto in fase seed non ha bisogno di microservizi, e un monolite non è un difetto. I campanelli d'allarme sono altri: un singolo server che nessuno sa ricostruire, una base di dati con backup mai testati, o una logica sparpagliata al punto che ogni modifica tocca dieci punti diversi.

Qualità del codice e manutenibilità

Qui chi esamina il codice ne analizza dei campioni. È leggibile? Ci sono test automatici e passano? Quanto ci mette uno sviluppatore nuovo ad avviare il progetto in locale? Codice che capisce solo chi l'ha scritto è un rischio aziendale, perché lega l'azienda a una sola persona.

Sicurezza

La verifica della sicurezza copre autenticazione, controllo degli accessi, gestione dei segreti, validazione degli input e componenti obsoleti con vulnerabilità note. Guarda anche come vengono conservati i dati personali. Se tratti dati di clienti in Svizzera, chi esamina il codice vorrà vedere che hai tenuto conto della Legge federale sulla protezione dei dati, anche se l'audit in sé non è un parere legale. Un rilievo sulla sicurezza raramente fa saltare un'operazione. Quelli nascosti e scoperti tardi spesso sì.

Dipendenze e licenze open source

I prodotti moderni sono in gran parte codice di altri. Ogni libreria porta con sé una licenza, e alcune licenze, dette copyleft, possono obbligarti a pubblicare il tuo codice se lo combini in certi modi. Secondo Walder Wyss, le aziende svizzere oggetto di operazioni forniscono abitualmente un elenco preciso del software open source e delle licenze applicabili, così che legal due diligence on software focuses on ownership and licences. Avere quell'elenco pronto è uno dei modi più semplici per dimostrarti preparato.

Titolarità e proprietà intellettuale

Chi esamina il codice, o gli avvocati che lavorano al suo fianco, verifica che l'azienda possieda ciò che dichiara. La stessa guida di Walder Wyss afferma che la due diligence sul software individua il software che l'azienda possiede e utilizza, conferma la titolarità, esamina le licenze e valuta se può essere commercializzato legalmente. In pratica, devi mostrare chi ha scritto il codice: dipendenti, collaboratori esterni, agenzie o un cofondatore che se n'è andato. Per ciascuno serve un accordo scritto che trasferisca o conceda in licenza i diritti all'azienda.

Team e rischio legato alle persone chiave

Gli audit del codice includono spesso una breve conversazione con l'ingegnere responsabile. La domanda di fondo è semplice: se questa persona se ne va domani, qualcun altro può andare avanti? Documentazione, script di rilascio e una seconda persona in grado di pubblicare una versione rispondono bene.

Codice generato dall'IA

Sempre più team usano assistenti di programmazione. Va benissimo, ma chi esamina il codice chiede sempre più spesso quanta parte sia stata generata, se sia stata rivista da una persona e se i test la coprano. Il codice generato e non rivisto tende ad apparire ordinato e a nascondere logica duplicata o gestione degli errori debole. Preparati a spiegare come il tuo team usa questi strumenti.

Cosa l'audit non copre

Chiarisci le aspettative fin da subito, perché a volte i fondatori credono che l'audit sia un verdetto sull'attività.

• Non è un parere legale. Walder Wyss osserva che le aziende svizzere oggetto di operazioni non forniscono abitualmente scansioni del codice per la due diligence legale, anche se la due diligence tecnica può comportare una legal due diligence on software focuses on ownership and licences. Gli avvocati leggono contratti e licenze; gli ingegneri leggono il codice. Un'operazione fatta bene usa entrambi.
• Non è un test di penetrazione. Una revisione del codice legge il sorgente. Un test di penetrazione attacca il sistema in funzione. Alcuni investitori chiedono entrambi, e il secondo è un lavoro a sé.
• Non è un'analisi di mercato. Dietro un codice bellissimo può esserci un prodotto che non vuole nessuno.
• Non può dimostrare l'assenza di problemi. Chi esamina il codice procede per campioni. Riferisce cosa ha visto, quanto a fondo ha guardato e cosa non ha raggiunto.

Come si svolge un audit del codice

Il metodo preciso varia da fornitore a fornitore, ma quasi tutti seguono lo stesso percorso.

1. Definizione del perimetro. Si concordano l'obiettivo (un round seed, una Serie A, un'acquisizione), i repository inclusi e il livello di profondità. Un prodotto pre-seed con un solo repository richiede un impegno diverso da una piattaforma con una dozzina di servizi.
2. Accessi e preparazione. Chi esamina il codice riceve accesso in sola lettura ai repository, al sistema di ticket, alla configurazione di rilascio e, idealmente, a un ambiente di staging. Con un accordo di riservatezza, non dovrebbe mai servirgli l'accesso ai sistemi di produzione.
3. Analisi automatica. Gli strumenti cercano vulnerabilità note nelle dipendenze, segreti esposti, tipi di licenza, copertura dei test e complessità del codice. Questo dà una base di partenza rapida e ampia.
4. Revisione manuale. Un ingegnere esperto legge i percorsi critici: accesso, pagamenti, accesso ai dati, la logica di business centrale. Gli strumenti non possono giudicare se un progetto ha senso, ed è qui che nasce la maggior parte dei rilievi davvero utili.
5. Colloqui. Una conversazione con il responsabile tecnico colma le lacune: perché sono state prese certe decisioni, cosa il team sa già essere rotto e cosa è in programma.
6. Rapporto e presentazione. Il risultato è un rapporto scritto con i rilievi ordinati per gravità e impegno, seguito da una chiamata in cui puoi contestare e chiedere chiarimenti.

Un rapporto utile distingue cosa non va da quanto costa sistemarlo. Senza stime di impegno, un investitore tirerà a indovinare, e le ipotesi tendono a essere pessimistiche.

Come prepararsi prima dell'audit

La preparazione accorcia la verifica e migliora l'impressione che dai. Dedica una settimana a quanto segue.

Materiale tecnico

• Accesso in sola lettura a tutti i repository, ciascuno con un README chiaro.
• Uno schema dell'architettura su una pagina: componenti, hosting, servizi di terzi, flussi di dati.
• Un elenco di tutte le dipendenze e delle relative licenze, strumenti di build inclusi.
• Prove dei backup e di un ripristino testato.
• Risultati recenti di test e rilasci, e un elenco dei bug noti e del debito tecnico.
• Un elenco di chi ha accesso ai sistemi di produzione e di come l'accesso viene revocato quando qualcuno se ne va.

Materiale giuridico e sulla titolarità

• Contratti di lavoro e di collaborazione che dimostrino che i diritti sul codice appartengono all'azienda.
• Accordi con eventuali agenzie o freelance che hanno costruito una parte del prodotto.
• Documentazione di eventuale codice preso da un altro progetto o da un precedente datore di lavoro. Risolvi queste situazioni prima che qualcuno te lo chieda.
• Le condizioni dei servizi di terzi da cui dipende il tuo prodotto.

Persone

• Decidi chi risponde alle domande tecniche e assicurati che conosca i punti deboli del sistema. Gli investitori perdonano i problemi noti. Non perdonano quelli negati.

Se ti serve una visione più ampia di ciò che acquirenti e investitori esaminano oltre al codice, questa due diligence checklist for brand owners copre l'aspetto operativo e finanziario della preparazione all'investimento.

Cosa può emergere dall'audit: i rilievi più frequenti

Questi sono gli schemi che ricorrono di continuo nei prodotti in fase iniziale.

Ambito	Rilievo tipico	Perché interessa all'investitore
Titolarità	Un collaboratore esterno ha costruito la prima versione senza cessione dei diritti	L'azienda potrebbe non possedere del tutto il proprio prodotto principale
Licenze	Una libreria copyleft è integrata nel codice proprietario	Possibile obbligo di divulgare il codice sorgente
Sicurezza	Segreti salvati nel repository, pacchetti obsoleti	Rischio di violazioni e possibile esposizione sulla protezione dei dati
Architettura	Un solo server, nessun sistema di emergenza, rilasci manuali	Interruzioni di servizio e consegne lente man mano che il team cresce
Manutenibilità	Nessun test, un solo autore, nessuna documentazione	Dipendenza da una persona chiave e inserimenti costosi
Dipendenza dal fornitore	Logica centrale legata a una sola agenzia o a una sola piattaforma proprietaria	Costi di cambiamento e trappole di dipendenza

Quasi tutti questi punti si possono sistemare. Ciò che cambia il prezzo di un'operazione è se il fondatore ne era a conoscenza e aveva un piano.

Quanto dura un audit del codice e cosa ne determina il costo

Non esiste un prezzo standard, e le cifre indicate variano molto tra fornitori e paesi, quindi prendi ogni singolo numero con cautela. Quattro fattori determinano durata e costo:

• Dimensione del codice. Più repository e più linguaggi significano più materiale da leggere.
• Profondità. Una scansione automatica veloce costa poco. Una revisione manuale dei percorsi critici più i colloqui richiede più tempo.
• Regolamentazione. Se tratti pagamenti, dati sanitari o altre informazioni regolamentate, aspettati una verifica più approfondita su sicurezza e conformità.
• La tua preparazione. Accessi in ordine, documentazione e un elenco delle dipendenze fanno risparmiare giorni. Rincorrere credenziali e spiegazioni li aggiunge.

Come indicazione di massima, una revisione mirata di un prodotto piccolo può richiedere giorni, mentre una revisione completa di una piattaforma più grande richiede diverse settimane. Chiedi a qualsiasi fornitore un perimetro definito e un preventivo scritto prima di iniziare, e chiedi cosa conterrà il rapporto. Se i tempi dell'operazione sono stretti, dillo già alla prima chiamata, così il perimetro può essere definito di conseguenza.

Chi dovrebbe svolgere l'audit

Chi svolge l'audit cambia il peso che questo avrà.

• Un revisore nominato dall'investitore. Indipendente da te, ma non controlli né il perimetro né l'impostazione.
• Un tuo audit preliminare. Svolto da un ingegnere o da uno studio che scegli tu, prima che arrivi il team dell'investitore. Ti dà il tempo di sistemare le cose e preparare le risposte.
• Il tuo stesso team. Meglio di niente, ma gli investitori lo considerano meno affidabile perché manca di indipendenza.

Per la maggior parte dei fondatori, l'approccio più forte è un audit preliminare indipendente seguito dalla verifica dell'investitore. Quando la seconda verifica trova quello che la prima aveva già riportato, la fiducia cresce.

Scegli un revisore che abbia costruito e messo in produzione software, non solo che li abbia verificati. Sa quali scorciatoie sono ragionevoli nella tua fase e quali sono pericolose. Verifica anche che non abbia interessi nel risultato, per esempio uno studio che guadagna ricostruendo tutto ciò che critica.

Sistemare i rilievi prima dei colloqui con gli investitori

Un rapporto con trenta rilievi fa paura. La definizione delle priorità lo trasforma in un piano.

1. Sistema subito: poco costoso e ben visibile. Sostituisci i segreti esposti, aggiorna i pacchetti vulnerabili, aggiungi le cessioni dei diritti mancanti, scrivi l'elenco di dipendenze e licenze, aggiungi un README. Richiedono giorni e tolgono di mezzo le obiezioni più facili.
2. Sistema con il finanziamento: costoso ma spiegabile. Riscrivere un'architettura, aggiungere copertura dei test su tutto il prodotto o migrare l'hosting. Assegna a ciascuna voce un costo e una tempistica e includile nel piano di utilizzo dei fondi. Un investitore che vede un piano con i costi vede un fondatore che ha il controllo.
3. Accetta con un piano: rischio basso o valore basso. Un po' di debito è razionale nella tua fase. Metti per iscritto perché lo lasci così e quando lo riprenderai in mano.

Due abitudini aiutano durante l'incontro. Primo: condividi tu stesso i rilievi principali del rapporto prima che te li chieda l'investitore. Secondo: non discutere mai la classificazione di gravità durante la riunione; porta una risposta scritta in un secondo momento.

Se un rilievo riguarda la titolarità, per esempio una cessione mancante da parte di un ex collaboratore, coinvolgi un avvocato prima di contattare quella persona. È una questione legale, e la soluzione è un documento firmato, non una modifica al codice.

Come può aiutarti Ampersand

Ampersand è un piccolo studio di Zurigo dove ingegneri senior seguono il lavoro dalla prima conversazione fino alla consegna. Offriamo audit e due diligence tecnica, oltre a consulenza guidata da figure senior per fondatori che hanno bisogno di uno sguardo indipendente sul proprio software prima di un round o di una vendita. Se i rilievi richiedono interventi, possiamo aiutarti anche con migrazioni, integrazioni e assistenza continuativa. Dai un'occhiata ai nostri prezzi e alle modalità di collaborazione oppure ai lavori che abbiamo realizzato. Per riferimento, il nostro piano Guidance costa 799 CHF al mese e il nostro piano di assistenza Run & monitor costa 750 CHF al mese.

Domande frequenti

Quando dovrei fare un audit del codice prima dell'investimento?

Fallo due o tre mesi prima di iniziare la raccolta di capitali o le trattative di vendita. Così hai il tempo di sistemare i rilievi poco costosi e di scrivere un piano con i costi per tutto il resto. Se sei l'investitore, programmalo dopo un term sheet o una lettera di intenti e prima dell'impegno definitivo.

Chi paga l'audit?

Dipende da chi lo commissiona. Un audit preliminare commissionato dal fondatore lo paga l'azienda. Un investitore o un acquirente di solito paga la propria verifica, anche se in alcune operazioni il costo viene diviso o inserito nella trattativa. Mettetevi d'accordo all'inizio, insieme a chi è il titolare del rapporto.

Devo dare all'investitore pieno accesso al mio codice?

Non necessariamente. Un approccio diffuso è l'accesso in sola lettura con un accordo di riservatezza, spesso limitato a una persona indicata per nome e a volte in un ambiente controllato. Walder Wyss osserva che legal due diligence on software focuses on ownership and licences per la due diligence legale, quindi limitare l'accesso al codice grezzo non è insolito. Un riepilogo scritto e un elenco delle licenze sono spesso il primo passo.

Un esito negativo dell'audit può far saltare un'operazione?

Può succedere, ma di solito solo quando i problemi sono nascosti, non dichiarati o irrisolvibili. I problemi noti, con un costo e una tempistica chiari, si negoziano normalmente: un aggiustamento del prezzo, una condizione o fondi accantonati per la sistemazione. Le lacune sulla titolarità e i conflitti gravi sulle licenze sono i rilievi che più spesso bloccano una chiusura.

Un audit del codice è la stessa cosa della due diligence tecnica?

No. L'audit del codice è una parte della due diligence tecnica. La verifica più ampia riguarda anche team, processi, infrastruttura, roadmap e a volte i contratti con i fornitori. L'audit fornisce le prove che stanno dietro alle conclusioni tecniche.

Fonti

• legal due diligence on software focuses on ownership and licences
• due diligence checklist for brand owners