Il giorno in cui il software va in produzione, inizia una fase diversa di costi. I costi di manutenzione software sono spesso sottovalutati: la maggior parte dei business plan prevede una voce "sviluppo" con un importo e una data di fine, come se dopo quella data il problema economico fosse risolto.
Si trasformano. E spesso, nel tempo, quello che spendi dopo il lancio supera quello che hai speso per costruire.
Se non lo sai prima di iniziare, ti ritrovi con un prodotto che funziona ma che non hai previsto di mantenere.
Perché il software non è mai davvero “finito”
Un edificio, una volta costruito, sta in piedi da solo. Il software no. Vive in un ecosistema che cambia continuamente, e se non cambia insieme a quell’ecosistema, inizia a degradarsi.
Gli aggiornamenti di sicurezza sono il primo fattore da considerare. Framework, linguaggi, sistemi operativi e database ricevono patch continue; ignorarle significa accumulare vulnerabilità nel tempo. Come ho scritto parlando di sicurezza nel backend, un sistema non aggiornato diventa progressivamente più esposto.
Poi ci sono dipendenze e librerie. Il tuo codice si appoggia a decine di componenti esterni: alcuni si evolvono, altri vengono deprecati, altri ancora vengono abbandonati. Quando una dipendenza cambia o smette di essere supportata, qualcuno deve intervenire. Ed è qui che emerge il costo nascosto delle dipendenze open source.
Lo stesso vale per l’infrastruttura. Certificati che scadono, database che crescono, costi cloud che cambiano, monitoraggio da mantenere attivo: nulla resta fermo da solo. Infine arrivano i bug e i comportamenti inattesi, che emergono con l’uso reale, con utenti veri, volumi veri e casi d’uso che nessuno aveva previsto in fase di sviluppo.
Il numero che spesso sorprende: la maggior parte del costo è dopo
In molti studi sul ciclo di vita del software, si osserva che la parte più consistente del costo totale non è nello sviluppo iniziale ma negli anni successivi, tra manutenzione, aggiornamenti e adeguamenti.
Tradotto in pratica: un software che è costato 100.000 euro per essere sviluppato può richiedere, nei cinque anni successivi, un investimento simile o superiore solo per rimanere sicuro, compatibile e funzionante.
Solo per mantenere ciò che esiste, senza aggiungere nulla di nuovo.
Se nel business plan la voce “software” è considerata una spesa una tantum, quel piano è incompleto.
Il paragone con gli asset fisici
Quando compri un immobile, prevedi manutenzione, rifacimenti, adeguamenti. Con il software spesso questo non succede perché è invisibile: non vedi il degrado finché qualcosa non smette di funzionare.
La differenza è che un immobile si degrada lentamente. Un software può rompersi all’improvviso: un aggiornamento del browser, una vulnerabilità, un’API esterna che cambia comportamento.
Il costo di non mantenere
Ignorare la manutenzione non elimina il costo. Lo rimanda, moltiplicandolo.
Il debito tecnico cresce con il tempo. Dopo anni senza aggiornamenti, un upgrade diventa complesso e rischioso. A volte si arriva alla tentazione di riscrivere tutto da zero, che raramente è la scelta più economica.
Le vulnerabilità restano aperte. I problemi di compatibilità aumentano. E il giorno in cui qualcosa si rompe, l’intervento d’emergenza costa molto più di una manutenzione costante.
Come pianificare in modo realistico
Prevedere un budget annuo di manutenzione è il primo passo. Una regola pratica diffusa è considerare ogni anno una cifra nell’ordine del 15–20% del costo iniziale di sviluppo. Non è un numero esatto, ma è un riferimento utile per evitare sorprese.
Aiuta molto anche distinguere manutenzione da evoluzione. Bug fix, sicurezza, aggiornamenti e compatibilità appartengono alla prima categoria; nuove funzionalità appartengono alla seconda. Mescolare le due voci porta quasi sempre a piani confusi, perché finisci per trattare come “novità” anche il semplice costo di tenere in piedi ciò che già esiste.
Dove possibile conviene automatizzare. Test automatici, deploy automatici e monitoraggio riducono il costo delle attività ripetitive nel tempo. Anche l’uso dell’AI nello sviluppo può velocizzare una parte della manutenzione ordinaria, ma solo se il progetto ha fondamenta abbastanza sane da permetterlo.
Conta anche la scelta delle tecnologie. Framework maturi e con cicli di rilascio prevedibili tendono a costare meno nel tempo rispetto a tecnologie emergenti con un futuro incerto. Infine, ogni piattaforma ha il suo ciclo di vita: pianificare gli aggiornamenti importanti con anticipo riduce drasticamente il rischio e il costo degli interventi urgenti.
Il cambio di mentalità
Il software funziona più come un servizio continuo che come un acquisto una tantum.
Puoi ottimizzare i costi con scelte architetturali corrette e buone pratiche, ma non puoi eliminarli. Ignorarli è il modo più rapido per trasformare un investimento in un problema.
Vale la pena chiedersi: stiamo spendendo abbastanza per proteggere l’investimento che abbiamo già fatto?
Simone Giusti
Consulente software strategico
