Comprare un’azienda con software custom dentro: la due diligence tecnica

La conclusione che vale la pena leggere subito

Chi compra un’azienda valuta il fatturato, i margini, i contratti con i clienti. Il software custom che fa girare i processi viene spesso trattato come un dettaglio tecnico da sistemare dopo. È un errore che può trasformare un’acquisizione conveniente in un progetto di risanamento da centinaia di migliaia di euro. Questo articolo spiega quali sono gli errori più frequenti nella due diligence tecnica del software, come si manifestano e quanto costano quando li si scopre troppo tardi.

Ignorare il codice sorgente perché “funziona”

Il software gira, gli utenti lo usano, i dati entrano e escono. Sembra sufficiente per dire che non c’è problema. Non lo è.
Un’applicazione può funzionare perfettamente in condizioni normali e crollare alla prima modifica. Questo succede quando il codice è stato scritto senza una struttura chiara, senza test automatizzati, con dipendenze obsolete o con logica di business sepolta in stored procedure non documentate. Da fuori non si vede niente. Dentro, è un campo minato.

Come si manifesta

La prima richiesta di modifica dopo l’acquisizione impiega tre volte il tempo stimato. Il team di sviluppo che hai ingaggiato torna con una lista di problemi che nessuno aveva segnalato. Si scopre che alcune funzioni critiche dipendono da una libreria abbandonata nel 2019.

Quanto costa

Il costo non è solo il refactoring. È il tempo perso, i ritardi sui progetti pianificati, il rischio operativo mentre il codice viene riscritto. Un’applicazione gestionale di medie dimensioni con debito tecnico accumulato può richiedere mesi di lavoro prima di essere modificabile senza pericolo. L’articolo sul refactoring del software legacy entra nel dettaglio di quando e come affrontare questa situazione.

Come si evita

Prima di chiudere l’acquisizione, fai analizzare il codice sorgente da un team tecnico indipendente. Non basta una demo. Serve accesso al repository, lettura delle dipendenze, verifica della copertura dei test. Se il venditore non concede l’accesso al codice durante la due diligence, è un segnale da prendere sul serio.

Non verificare chi possiede davvero il software

Questa è una delle aree più sottovalutate e anche una delle più pericolose dal punto di vista legale.
Un’azienda può usare un software custom da anni senza possederne il codice sorgente. Lo ha commissionato a un’agenzia esterna, ma nel contratto originale la proprietà intellettuale è rimasta all’agenzia. Oppure il software è stato sviluppato da un ex dipendente che non ha mai firmato una cessione formale dei diritti.

Come si manifesta

Dopo l’acquisizione, quando vuoi aggiornare il software o migrarlo su una nuova infrastruttura, ti accorgi che non hai accesso al codice. O peggio: l’agenzia originale rivendica i diritti e ti chiede un compenso per cederteli.

Quanto costa

Nei casi meno gravi, si tratta di una negoziazione scomoda e di qualche migliaio di euro. Nei casi peggiori, ti ritrovi a dover riscrivere il software da zero perché non puoi usare quello esistente legalmente. La guida sull’exit strategy per evitare il lock-in descrive in dettaglio come questi meccanismi di dipendenza si costruiscono nel tempo.

Come si evita

Nella due diligence, chiedi copia di tutti i contratti di sviluppo software stipulati negli ultimi dieci anni. Falli esaminare da un legale specializzato in proprietà intellettuale. Verifica che la cessione dei diritti sul codice sia esplicita e non ambigua. Se non trovi i contratti, tratta il software come se non fosse di proprietà dell’azienda finché non hai prove del contrario.

Un caso tipico: il software è stato sviluppato da un’agenzia che nel contratto ha inserito una clausola di licenza d’uso, non una cessione. L’azienda target lo usa da anni, paga la manutenzione, si sente proprietaria. Non lo è. Quella distinzione, in sede di acquisizione, vale quanto il software stesso.

Controlla anche i casi in cui il software è stato modificato nel tempo da fornitori diversi. Ogni fornitore che ha messo mano al codice potrebbe avere rivendicazioni su quella parte. Se non ci sono contratti che regolano ogni intervento, la situazione si complica. Un legale che non conosce il settore software tende a sottovalutare questo punto: assicurati che chi esamina i contratti abbia esperienza specifica.

Sottostimare la dipendenza da un singolo fornitore

Molte PMI hanno costruito il loro software custom con un’unica agenzia o, in alcuni casi, con un singolo sviluppatore freelance. Quando acquisti quell’azienda, acquisti anche quella dipendenza.
Se il fornitore è l’unico che conosce il codice, che gestisce il server, che ha le credenziali di accesso all’infrastruttura, ti trovi in una posizione negoziale pessima. Puoi continuare a pagare le sue tariffe qualunque siano, oppure affrontare una migrazione costosa e rischiosa.
Questo non è un problema raro. È la norma nelle PMI che hanno costruito software custom senza pensare a cosa succederebbe se il fornitore sparisse o aumentasse i prezzi. L’articolo su cosa fare quando il fornitore del gestionale chiude mostra quanto può diventare complicata questa situazione.
Nella due diligence, mappa tutte le dipendenze esterne: chi gestisce il server, chi ha accesso al codice, chi può intervenire in caso di emergenza. Poi valuta quanto costerebbe sostituire ognuno di questi attori.

Non capire cosa fa davvero il software

Sembra ovvio, ma durante le acquisizioni capita spesso che nessuno sappia descrivere con precisione cosa fa il software, quali processi supporta e cosa succederebbe se smettesse di funzionare.
Il venditore lo usa da anni e lo dà per scontato. Il compratore si fida della descrizione commerciale. Nessuno si siede a mappare i flussi reali.

Come si manifesta

Dopo l’acquisizione, scopri che il software gestisce un processo critico che non era stato dichiarato, per esempio la generazione automatica dei prezzi o la sincronizzazione con un magazzino esterno. Oppure scopri il contrario: funzionalità che vengono pagate in manutenzione ma che nessuno usa più da anni.

Quanto costa

Nel primo caso, il rischio è operativo: se quel processo si interrompe, l’azienda si ferma. Nel secondo, stai pagando per mantenere codice morto, il che rallenta ogni modifica futura e gonfia i costi di manutenzione.

Come si evita

Prima della firma, organizza sessioni di lavoro con gli utenti reali del software, non solo con il management. Chiedi loro di mostrarti come lo usano, cosa fanno quando non funziona, quali workaround hanno inventato nel tempo. I workaround sono particolarmente rivelatori: segnalano dove il software non copre bene un processo e dove il rischio operativo è più alto.

Un segnale da cercare subito: chiedi quante volte nell’ultimo anno il software ha causato un blocco operativo, anche parziale. Se nessuno sa rispondere, o se la risposta viene minimizzata, significa che i problemi non vengono tracciati. Senza tracciamento, non puoi sapere quanto è stabile quello che stai comprando.

I workaround meritano un approfondimento a parte. Quando un utente esporta dati in Excel per fare un calcolo che il software dovrebbe fare da solo, stai guardando un processo che il software non copre. Quel processo esiste, è reale, e dopo l’acquisizione qualcuno dovrà gestirlo. O lo automatizzi, con un costo, o lo lasci così, con un rischio. Meglio saperlo prima.

Trascurare l’infrastruttura e la sicurezza

Il codice non gira nel vuoto. Gira su server, database, servizi cloud. E quella infrastruttura può nascondere problemi gravi quanto quelli nel codice.
Un software perfettamente scritto su un server non aggiornato da tre anni, con backup configurati male e nessun piano di disaster recovery, è un rischio operativo serio. Nella due diligence tecnica, l’infrastruttura merita la stessa attenzione del codice.
Chiedi: dove gira il software? Chi gestisce gli aggiornamenti del sistema operativo? Con quale frequenza vengono fatti i backup e dove vengono conservati? Quando è stato testato l’ultimo ripristino? Se le risposte sono vaghe o inesistenti, hai trovato un problema.
Sul fronte sicurezza, verifica se il software gestisce dati personali e se è stato fatto un assessment rispetto al GDPR. Un’applicazione che raccoglie dati di clienti senza log degli accessi, senza cifratura adeguata e senza una policy di data retention chiara può portarti responsabilità legali che non hai messo in conto nel prezzo di acquisto.
Se stai valutando un’acquisizione in un settore regolamentato o se il software distribuisce aggiornamenti a terzi, tieni presente che il quadro normativo sul software sta cambiando: vale la pena capire cosa comporta anche solo a livello di obblighi documentali.

Se stai conducendo un’analisi di questo tipo e vuoi un secondo parere tecnico prima di procedere, raccontaci il caso: possiamo aiutarti a capire cosa guardare e cosa pesare.

Comprare senza un piano per il giorno dopo

L’ultimo errore non riguarda la due diligence in sé, ma quello che succede quando finisce.
Anche se l’audit tecnico è stato fatto bene e hai una fotografia chiara del software, serve un piano per i primi sei mesi dopo l’acquisizione. Chi gestirà la manutenzione? Chi interverrà in caso di problemi? Come verranno gestiti gli aggiornamenti?
Senza un piano, il rischio è che il software venga lasciato in stato di stasi mentre l’azienda si integra con la nuova struttura. Ogni mese senza manutenzione è un mese in cui le dipendenze invecchiano, i bug si accumulano e il debito tecnico cresce. La manutenzione evolutiva del software custom non è un optional che si può rimandare: è quello che tiene vivo il software nel tempo.
Un piano realistico include almeno: identificazione del team che prenderà in carico il codice, accordo con un fornitore per la manutenzione ordinaria, priorità sulle prime modifiche da fare e stima del tempo necessario per portare il software a uno stato di manutenibilità accettabile se oggi non lo è.
Comprare un’azienda con software custom dentro non è necessariamente un rischio. È un rischio solo se ci si arriva impreparati.

Un dettaglio che si trascura spesso: il passaggio di consegne con il fornitore attuale. Se l’agenzia che ha sviluppato il software non è coinvolta nel processo di transizione, perdi informazioni che non sono scritte da nessuna parte. Conoscenza su scelte architetturali, su bug noti, su configurazioni particolari. Quella conoscenza sparisce con le persone che la detengono.

Prevedi almeno un periodo di affiancamento formale con chi ha gestito il software fino all’acquisizione. Non deve essere lungo, ma deve essere strutturato: sessioni documentate, non chiamate informali. Quello che viene scritto in quella fase vale più di qualsiasi audit fatto dopo.

CTA finale

Se stai valutando un’acquisizione e vuoi capire in anticipo cosa c’è dentro il software che stai per comprare, in Press Start facciamo audit tecnici del codice pensati esattamente per questo contesto. Raccontaci il tuo caso e vediamo insieme cosa ha senso fare.

“`json
“`