Hai appena rilasciato il tuo applicativo custom. Funziona, i colleghi lo usano, il progetto è chiuso. Poi passano 18 mesi.
Un aggiornamento del framework rompe tre funzioni. Un bug compare solo con certi dati di input. L'integrazione con il gestionale smette di sincronizzarsi dopo l'aggiornamento del fornitore esterno. E lo sviluppatore che ha scritto il codice non è più disponibile.
Questo è il momento in cui le PMI scoprono che il software custom non è un acquisto: è un impegno continuativo. La manutenzione software non è un optional che puoi posticipare — è ciò che separa un applicativo che cresce con il business da uno che diventa un problema da gestire.
In questo articolo vediamo cosa comprende davvero la manutenzione di un software su misura, perché ignorarla costa di più che investirci, e come strutturare un contratto di supporto che abbia senso per una PMI.
Quando si parla di manutenzione software, si mette nello stesso calderone attività molto diverse. Distinguerle aiuta a capire cosa stai comprando e cosa stai trascurando.
Manutenzione correttiva. Sono i bug fix: qualcosa non funziona come dovrebbe e va riparato. Sembra ovvio, però molte PMI gestiscono i bug in modo reattivo, senza un canale dedicato né tempi di risposta definiti. Il risultato è che un problema bloccante per la produzione aspetta giorni perché non c'è una procedura chiara.
La manutenzione adattiva riguarda invece la compatibilità: il tuo applicativo gira su PHP 8.1, il server viene aggiornato a PHP 8.3, alcune funzioni sono deprecate. Oppure l'API del corriere che usi cambia le specifiche. Questi interventi non aggiungono nulla di visibile all'utente, però senza di essi l'applicativo smette di funzionare.
C'è poi la manutenzione evolutiva: nuove funzionalità, miglioramenti all'interfaccia, ottimizzazioni delle performance. Qui si sovrappone allo sviluppo vero e proprio, quindi va gestita con priorità e budget separati rispetto alla manutenzione ordinaria.
Infine, la manutenzione preventiva: refactoring del codice, aggiornamento delle dipendenze, miglioramento della copertura dei test. È quella che si fa meno perché non produce nulla di visibile nel breve periodo — ed è esattamente per questo che si accumula debito tecnico.
Ogni volta che si rimanda un aggiornamento, si lascia una dipendenza obsoleta, si bypassa un test perché "tanto funziona", si aggiunge un pezzo di codice senza documentarlo — si accumula debito tecnico.
Il termine viene dall'informatica ma il concetto è immediato: è come un mutuo. Puoi non pagarlo per un po', però gli interessi si accumulano. Più aspetti, più costa sistemare.
Un applicativo senza manutenzione per due o tre anni arriva spesso a un punto in cui il costo di un aggiornamento supera quello di una riscrittura parziale. Le dipendenze saltate di tre versioni maggiori, il framework non più supportato, le funzioni deprecate che si sono moltiplicate: tutto questo si traduce in ore di lavoro che non producono feature nuove, solo recupero del terreno perduto.
Per una PMI che dipende da quel software per gestire ordini, clienti o produzione, questo non è un problema astratto.
La risposta onesta è che la manutenzione software è invisibile quando funziona. Nessuno nota che il framework è aggiornato, che le dipendenze sono sicure, che il codice è pulito. Si nota solo quando qualcosa si rompe.
Questo crea un bias cognitivo preciso: il costo della manutenzione è certo e presente, il costo del non farlo è incerto e futuro. Quindi si rimanda.
C'è anche un problema contrattuale. Molte PMI commissionano un software custom con un contratto a progetto chiuso: si paga lo sviluppo, si riceve il software, il rapporto finisce. La manutenzione non è mai stata discussa, non c'è un interlocutore dedicato, non c'è un budget allocato.
Questa è, secondo noi, una delle scelte più rischiose che una PMI possa fare dopo aver investito in un applicativo su misura. Costruire software custom senza pianificare la manutenzione è come comprare un impianto industriale senza prevedere la manutenzione ordinaria: funziona finché funziona, poi il costo del fermo è molto più alto di quello della prevenzione.
Un buon contratto di supporto software su misura non è un foglio generico con "assistenza inclusa". Deve specificare alcune cose concrete.
SLA e tempi di risposta. Distingui tra bug bloccanti (l'applicativo non funziona), bug critici (una funzione importante è compromessa) e bug minori (problema estetico o marginale). Per ognuno deve esserci un tempo di presa in carico e un tempo di risoluzione attesi. Senza questi numeri, "assistenza inclusa" non vuol dire niente.
Cosa rientra nella manutenzione ordinaria e cosa no. Gli aggiornamenti di sicurezza rientrano? Il refactoring preventivo? Le piccole modifiche funzionali? Definirlo a priori evita discussioni su ogni singolo intervento.
Modalità di segnalazione e tracciamento. Un sistema di ticket, anche semplice, è necessario. Segnalare i bug via WhatsApp o email sparsa non funziona: si perdono, non si tracciano, non si misurano.
Reportistica periodica. Ogni trimestre, o almeno ogni semestre, dovresti ricevere un resoconto sullo stato dell'applicativo: dipendenze aggiornate, vulnerabilità risolte, interventi effettuati, ore consumate. Se il tuo contratto non prevede questo, non sai cosa sta succedendo al software su cui gira parte del tuo business.
Se stai valutando come strutturare il supporto per un applicativo esistente o stai per commissionare un nuovo sviluppo, parlaci del tuo caso: possiamo aiutarti a definire un piano di manutenzione che si adatti alla complessità reale del progetto.
Non esiste una risposta universale, però esistono alcune regole pratiche.
Gli aggiornamenti di sicurezza non si programmano: si applicano appena disponibili, spesso entro pochi giorni dalla release. Una vulnerabilità nota è una finestra aperta. Rimandare per comodità è un rischio che non vale mai.
Gli aggiornamenti di framework e dipendenze principali si gestiscono invece con più calma: ogni 3-6 mesi è una frequenza ragionevole per la maggior parte degli applicativi. L'importante è non saltare versioni maggiori, perché recuperare tre versioni in una volta sola è molto più costoso che fare aggiornamenti graduali.
Le evoluzioni funzionali dipendono dal business. Un e-commerce con campagne stagionali ha esigenze diverse da un gestionale interno usato sempre nello stesso modo. Quello che conta è avere un processo: una lista di backlog aggiornata, una prioritizzazione periodica, un budget dedicato separato dalla manutenzione ordinaria.
Con il tempo, le esigenze cambiano. Il software che hai commissionato due anni fa copriva certi processi; adesso ne hai di nuovi, o quelli vecchi funzionano diversamente.
Qui la domanda diventa: adatto l'applicativo esistente o commissiono qualcosa di nuovo?
La risposta dipende dallo stato del codice e dall'entità del cambiamento. Se l'architettura è solida e le modifiche riguardano funzionalità aggiuntive, l'evoluzione dell'applicativo esistente è quasi sempre più economica e rapida. Se invece il codice è degradato, le modifiche richieste stravolgono la logica di base, o le tecnologie usate sono ormai obsolete, può avere senso pianificare una riscrittura parziale o totale.
Questa valutazione richiede un'analisi tecnica del codice esistente, non solo una stima a occhio. Diffida di chi ti dà una risposta senza aver letto il codice.
Mettere insieme tutto quello che abbiamo visto, il quadro è abbastanza chiaro.
Un applicativo custom senza manutenzione programmata accumula debito tecnico, diventa vulnerabile, si irrigidisce e alla fine costa di più da sistemare che da riscrivere. Il bug fix software gestionale fatto in emergenza, senza contesto e senza documentazione, ha un costo orario molto più alto di quello pianificato.
Pianificare la manutenzione dall'inizio — quando si negozia il contratto di sviluppo, non dopo — è l'unico modo per tenere sotto controllo il costo totale di un applicativo nel tempo.
Q: Quanto costa un contratto di manutenzione software per una PMI?
A: Dipende dalla complessità dell'applicativo, dalla frequenza degli aggiornamenti e dal livello di supporto incluso. Non esiste una tariffa standard: un'applicazione con integrazioni esterne e logiche business complesse richiede più ore di un gestionale semplice. Chiedi sempre un preventivo basato sull'analisi del codice esistente.
Q: Cosa include un contratto di manutenzione software su misura?
A: Di solito copre bug fix, aggiornamenti di sicurezza, compatibilità con nuove versioni del framework, monitoraggio e piccole evoluzioni funzionali. I contratti più strutturati includono anche SLA con tempi di risposta garantiti e reportistica periodica sullo stato dell'applicativo.
Q: Ogni quanto va aggiornata un'applicazione web aziendale?
A: Gli aggiornamenti di sicurezza vanno applicati appena disponibili, spesso entro pochi giorni dalla release. Gli aggiornamenti di framework e dipendenze si gestiscono tipicamente ogni 3-6 mesi. Le evoluzioni funzionali dipendono dal business: alcune PMI rilasciano nuove feature ogni mese, altre ogni trimestre.
Q: Cosa succede se non si fa manutenzione su un software custom?
A: L'applicativo invecchia tecnicamente: le dipendenze diventano obsolete, le vulnerabilità si accumulano e il codice diventa difficile da modificare. Dopo qualche anno senza manutenzione, spesso è più economico riscrivere da zero che intervenire sul codice esistente.
Q: Posso fare manutenzione con uno sviluppatore diverso da chi ha scritto il codice originale?
A: Sì, ma richiede una fase di onboarding tecnico. Uno sviluppatore esterno deve leggere il codice, capire le scelte architetturali e ricostruire il contesto. Con documentazione adeguata questa fase si accorcia. Senza documentazione, i tempi e i costi iniziali salgono.
Se il tuo applicativo custom non ha ancora un piano di manutenzione strutturato, in Press Start possiamo analizzare lo stato del codice e aiutarti a definire un contratto di supporto adatto alla complessità del progetto. Raccontaci il tuo caso
