Il problema che nessuno vuole ammettere

Hai appena ricevuto il software custom che aspettavi da mesi. Il fornitore dice che funziona. Il tuo team inizia a usarlo. Dopo tre giorni arriva il primo bug serio: un’operazione che sembrava banale cancella dati nel modo sbagliato.
Questo non è uno scenario raro. È quasi la norma quando il testing viene trattato come un dettaglio dell’ultimo minuto, qualcosa che “si gestisce dopo il lancio”.
Le PMI che commissionano software custom si trovano in una posizione scomoda: non hanno un team QA interno, non sempre sanno cosa chiedere al fornitore in termini di qualità, e spesso scoprono i problemi solo quando il software è già in produzione. Vediamo come uscire da questa trappola con un approccio che non richiede né un budget enorme né competenze specialistiche.

Cosa significa davvero “testare” un software custom

Prima di parlare di strumenti, serve chiarire una cosa: testare non significa cliccare su tutto e sperare che non si rompa niente.
Un test ha senso quando risponde a una domanda precisa. “Se inserisco un ordine con quantità zero, cosa succede?” è un test. “Ho girato l’applicazione per venti minuti e sembra ok” non lo è.
Esistono tre livelli di testing che una PMI dovrebbe conoscere:
I test unitari verificano singole funzioni del codice. Sono responsabilità del team di sviluppo e non richiedono coinvolgimento diretto del cliente. Se il tuo fornitore non li scrive, è un segnale da non ignorare.
I test di integrazione verificano che i pezzi del sistema funzionino insieme. Tipicamente: il modulo ordini comunica correttamente con il magazzino? I dati del CRM si sincronizzano con la piattaforma e-commerce?
I test end-to-end simulano il comportamento reale di un utente. Aprono il browser, navigano, compilano form, verificano i risultati. Sono i più lenti da eseguire ma anche i più vicini all’esperienza reale.
Per una PMI senza QA interno, il punto di partenza più utile sono i test end-to-end sui flussi critici. Non tutto, solo quello che, se si rompe, blocca il business.

Identificare i flussi critici: da dove partire

Ogni applicazione ha un nucleo di operazioni che non possono fallire. Per un e-commerce è il checkout. Per un gestionale di produzione è la registrazione degli ordini di lavoro. Per un CRM custom è la qualificazione dei lead.
Mappa questi flussi prima ancora di parlare con il tuo fornitore di testing. Un metodo pratico: chiedi al tuo team operativo “cosa succederebbe se domani mattina questo non funzionasse?” Le risposte che generano panico immediato sono i tuoi flussi critici.
Tipicamente sono tre o quattro. Raramente di più.
Su questi flussi vale la pena investire in test automatici. Sul resto, un collaudo manuale strutturato prima di ogni release è spesso sufficiente.

Cypress: perché è lo strumento giusto per iniziare

Cypress è un framework di test end-to-end open source. Simula un utente reale nel browser: clicca, compila, naviga, verifica. Lo script che scrivi oggi verrà rieseguito identico ad ogni deploy, ogni volta che il codice cambia.
Perché Cypress e non altro? La documentazione è tra le migliori del settore. La sintassi è leggibile anche per chi non scrive codice tutti i giorni. E il feedback visivo (puoi vedere il browser che esegue i test in tempo reale) abbassa enormemente la curva di apprendimento.
Un test Cypress per verificare il flusso di login di un’applicazione custom somiglia a questo:

describe('Login aziendale', () => {
  it('permette l\'accesso con credenziali valide', () => {
    cy.visit('/login')
    cy.get('[data-cy="email"]').type('utente@azienda.it')
    cy.get('[data-cy="password"]').type('passwordTest123')
    cy.get('[data-cy="submit"]').click()
    cy.url().should('include', '/dashboard')
    cy.contains('Benvenuto').should('be.visible')
  })
})

Non serve un team QA per leggere questo codice e capire cosa fa. Serve però che il tuo fornitore aggiunga gli attributi data-cy agli elementi dell’interfaccia: è una convenzione che rende i test stabili anche quando il CSS cambia. Chiedila esplicitamente nel capitolato.
Opinione netta: chi propone ancora Selenium come primo approccio per un’applicazione moderna sta risolvendo un problema del 2015. Cypress è più veloce da configurare, più stabile in esecuzione e più facile da mantenere. La scelta è semplice.

Bug tracking: il minimo che funziona

Avere i test è metà del lavoro. L’altra metà è sapere cosa fare quando qualcosa va storto.
Senza un sistema di bug tracking condiviso, i problemi vengono segnalati via WhatsApp, persi in thread di email, o peggio, risolti senza che nessuno sappia cosa è stato cambiato. Questo genera regressioni: bug già risolti che tornano perché la correzione non era documentata.
Non serve uno strumento sofisticato. GitHub Issues, Linear o anche una board Notion con un template standard funzionano benissimo per una PMI. Il template minimo per segnalare un bug:

1. Cosa stavo facendo (passo per passo)
2. Cosa mi aspettavo che succedesse
3. Cosa è successo invece
4. Come si riproduce (sempre? solo a volte? solo con certi dati?)

Questa struttura, applicata in modo consistente, dimezza il tempo che il tuo fornitore impiega a capire e risolvere il problema.

Come strutturare il collaudo prima del rilascio

Se non hai test automatici su tutto (ed è normale non averli), il collaudo manuale strutturato è la rete di sicurezza.
Un collaudo efficace non è “gira l’applicazione e vedi se funziona”. È una checklist specifica, aggiornata ad ogni release, che copre:

• i flussi critici identificati in precedenza
• le funzionalità modificate nell’ultima release
• le aree che storicamente hanno generato problemi

Questa checklist va costruita insieme al tuo fornitore e aggiornata dopo ogni bug trovato in produzione. Ogni bug che sfugge al collaudo diventa un nuovo punto di controllo per la volta successiva.
Il collaudo manuale non scala all’infinito. Ogni nuova funzionalità aggiunge superficie da testare, e fare tutto a mano prima di ogni deploy diventa rapidamente insostenibile. Questo è il momento in cui investire in automazione smette di essere opzionale.

Cosa chiedere al tuo fornitore (prima di firmare)

Se stai per commissionare un software custom, queste domande ti aiutano a capire come il fornitore tratta il testing:

• “Scrivete test unitari? Con quale copertura minima?”
• “I test automatici sono inclusi nella consegna o sono un extra?”
• “Come gestite le regressioni tra una release e l’altra?”
• “Usate una pipeline CI/CD? I test girano in automatico prima del deploy?”

Le risposte vaghe o evasive dicono molto. Un fornitore che non ha una risposta chiara sulla copertura dei test probabilmente non ha un processo strutturato di quality assurance.
Se stai valutando come impostare questo processo per un software già in produzione, raccontaci il tuo caso: possiamo aiutarti a capire da dove partire.

Quando i test automatici non bastano

I test automatici verificano che il software faccia quello che gli hai detto di fare. Non verificano che quello che gli hai detto di fare sia la cosa giusta.
Questo è il confine tra quality assurance tecnica e validazione del prodotto. Un test Cypress può confermare che il form di inserimento ordine salva correttamente i dati. Non può dirti se quel form è usabile, se il flusso ha senso per i tuoi operatori, se i campi richiesti sono quelli giusti.
Per questo serve il feedback degli utenti reali, raccolto sistematicamente. Sessioni di test con gli utenti finali prima del rilascio, survey post-lancio, analisi delle segnalazioni dei primi mesi: sono strumenti diversi dai test automatici, ma complementari.
Una PMI che ha entrambi, anche in forma minimale, è in una posizione molto più solida di una che ha solo uno dei due.

FAQ

Q: Quanto tempo richiede impostare un sistema di test automatici per un software custom?
A: Per un’applicazione aziendale di medie dimensioni, configurare un set minimo di test end-to-end con Cypress richiede qualche giorno di lavoro iniziale. L’investimento si recupera già alle prime release successive, quando i bug regressivi smettono di presentarsi in produzione.
Q: Cypress è adatto anche a PMI senza sviluppatori dedicati al QA?
A: Sì. La sintassi è leggibile, la documentazione è solida e i test possono essere eseguiti in autonomia anche da chi non è uno sviluppatore senior. Il vero ostacolo è trovare il tempo per scriverli, non la difficoltà tecnica.
Q: Qual è la differenza pratica tra test manuali e test automatici?
A: I test manuali richiedono che qualcuno esegua le funzioni dell’applicazione e verifichi il comportamento a mano. I test automatici fanno la stessa cosa via script, ogni volta che il codice cambia. Per software che evolve spesso, i test automatici diventano l’unico modo per non perdere il controllo sulla qualità.
Q: Come si gestisce il bug tracking senza un team QA dedicato?
A: Serve uno strumento condiviso tra chi sviluppa e chi usa il software: Linear, GitHub Issues o Notion vanno bene. La chiave è un formato standard per segnalare i bug (cosa è successo, cosa ci si aspettava, come riprodurlo) e una persona che decide le priorità.
Q: Il collaudo finale prima del rilascio è sufficiente senza test automatici?
A: Per una prima release, spesso sì. Per un software aggiornato ogni settimana, no. Il collaudo manuale non scala: ogni nuova funzionalità aggiunge superficie da testare, e farlo tutto a mano prima di ogni deploy diventa rapidamente insostenibile.

Se gestisci un software custom che viene aggiornato spesso e ti accorgi che ogni release porta con sé qualche sorpresa indesiderata, in Press Start possiamo aiutarti a impostare un processo di testing adatto alle tue risorse. Scrivici e vediamo insieme da dove conviene partire.

Il problema che nessuno vuole guardare in faccia

Hai un’applicazione che funziona. Forse è in produzione da tre anni, forse da cinque. Il team la conosce bene, i clienti ci lavorano ogni giorno, i bug gravi sono rari. Eppure ogni volta che si deve aggiungere una feature, il tempo stimato raddoppia. Ogni deploy è una piccola scommessa. E l’ultima volta che avete provato a cambiare il modulo degli ordini, avete rotto il modulo delle notifiche.
Questo è il debito tecnico che si manifesta. E nelle PMI italiane, di solito, si manifesta tardi — quando è già costoso da ignorare.
Il modern application development non è una buzzword da conferenza. È la risposta pratica a questo problema: un insieme di pratiche che permettono di rilasciare software in modo frequente, affidabile e senza dover ogni volta sperare che non vada tutto storto.
Vediamo cosa significa concretamente, e soprattutto cosa è realistico per una PMI con risorse limitate.

Debito tecnico: come si accumula e perché è difficile da vedere

Il debito tecnico si accumula per ragioni comprensibili. Una funzionalità va rilasciata in fretta perché c’è una scadenza. Si sceglie la soluzione più rapida, non quella più pulita. Si rimanda il refactoring. Si aggiunge un workaround sopra un altro workaround.
Il risultato, dopo qualche anno, è un’applicazione che tecnicamente funziona ma che internamente assomiglia a un cassetto pieno di cavi aggrovigliati. Aggiungere qualcosa richiede di capire prima come sono collegati tutti i cavi.
Il punto che spesso sfugge: il debito tecnico non è un problema morale o di bravura del team. È un problema strutturale di incentivi. Chi chiede le feature vuole i tempi brevi. Chi sviluppa è sotto pressione. La qualità del codice non è visibile al cliente. Quindi si accumula, sempre.
Nelle PMI questo meccanismo è amplificato da due fattori. Il primo è il turnover: se chi ha scritto quel codice tre anni fa non lavora più in azienda, la conoscenza implicita svanisce con lui. Il secondo è la mancanza di tempo dedicato: in un team piccolo, chi sviluppa è anche chi fa supporto, chi fa deploy, chi risponde alle urgenze. Il refactoring finisce sempre in fondo alla lista.

Cosa cambia con un approccio moderno allo sviluppo

Il modern application development si basa su alcune pratiche che, prese insieme, cambiano il modo in cui il software viene costruito e rilasciato.
CI/CD (Continuous Integration / Continuous Delivery). Ogni modifica al codice viene testata automaticamente e, se i test passano, può essere rilasciata in produzione senza intervento manuale. Questo riduce il rischio di ogni singolo deploy perché i cambiamenti sono piccoli e frequenti, non grandi e rari.
Una pipeline CI/CD ben configurata con GitHub Actions o GitLab CI non richiede un team DevOps dedicato. Richiede qualche giorno di setup iniziale e disciplina nel mantenerla.
L’architettura modulare è l’altro pilastro. Non significa necessariamente microservizi (ci torniamo). Significa che i diversi pezzi dell’applicazione hanno confini chiari, dipendenze esplicite, e possono essere modificati senza effetti a cascata imprevedibili. Un monolite ben strutturato con Laravel, per esempio, può rispettare questi principi molto meglio di un’architettura a microservizi mal progettata.
L’osservabilità completa il quadro: log strutturati, metriche di performance, alerting. Se non sai cosa sta succedendo in produzione, non puoi migliorarlo.

Cloud native per le PMI: cosa è utile e cosa è overkill

“Cloud native” è una di quelle etichette che include tutto e quindi rischia di non dire niente. Vediamo cosa è effettivamente utile per una PMI e cosa è overkill.

Pratica	Utile per PMI?	Note
Pipeline CI/CD automatizzata	Sì, quasi sempre	GitHub Actions o GitLab CI sono gratuiti per progetti piccoli
Containerizzazione (Docker)	Sì, con riserve	Utile per ambienti consistenti; Kubernetes è quasi sempre overkill
Infrastruttura as Code	Dipende	Ha senso se l’infrastruttura cambia spesso o è complessa
Microservizi	Raramente	Introduce complessità operativa difficile da gestire con team piccoli
Feature flags	Sì, se si fa trunk-based development	Permettono di rilasciare codice disattivato e attivarlo gradualmente
Monitoraggio e alerting	Sì, sempre	Sentry per gli errori, qualcosa come Uptime Robot per la disponibilità

La nostra opinione netta: i microservizi sono sopravvalutati per le PMI, e chi li propone come soluzione universale di solito non è chi poi dovrà mantenerli. Un monolite modulare con buona separazione dei domini regge benissimo carichi che la maggior parte delle PMI non raggiungerà mai, ed è molto più semplice da operare.

Platform engineering nelle piccole imprese: la soglia è più bassa di quanto pensi

Il platform engineering è la disciplina che si occupa di costruire l’infrastruttura interna che permette ai team di sviluppo di lavorare in modo autonomo e veloce. Nelle grandi aziende ci sono team dedicati. Nelle PMI, questa funzione deve essere distribuita o automatizzata.
La buona notizia è che la soglia di ingresso si è abbassata molto. Strumenti come Railway, Render o Fly.io permettono di avere ambienti di staging e produzione configurabili senza gestire direttamente server. Le pipeline CI/CD sono configurabili con file YAML e documentazione pubblica. I template di progetto (scaffolding) possono essere standardizzati una volta e riusati.
Il risultato pratico: un team di tre sviluppatori può avere un ciclo di rilascio software accelerato e affidabile senza un DevOps engineer a tempo pieno. Richiede investimento iniziale, non investimento continuo.

Come ridurre il debito tecnico senza fermare tutto

Questo è il punto dove molti progetti falliscono. Si decide di “riscrivere tutto da zero” e si finisce con due sistemi da mantenere in parallelo per mesi, budget sforato, e spesso un risultato non migliore dell’originale.
La strategia che funziona è diversa: ridurre il debito tecnico per incrementi, mentre si continua a rilasciare valore.

1. Identifica le aree ad alta entropia. Quali parti del codice vengono toccate più spesso e producono più bug? Quelle sono le candidate al refactoring prioritario, non le parti che “sembrano brutte” ma sono stabili.
2. Introduci i test prima di refactorizzare. Senza test di regressione, il refactoring è una scommessa. Scrivi prima i test che descrivono il comportamento attuale, poi modifica il codice.
3. Usa la “regola del boy scout”. Ogni volta che tocchi un file per una feature, lascialo un po’ più pulito di come l’hai trovato. Non serve un sprint dedicato al refactoring: basta disciplina costante.
4. Separa le dipendenze obsolete per priorità. Una libreria con vulnerabilità note è urgente. Una libreria semplicemente vecchia ma funzionante può aspettare.

Se stai valutando come affrontare questo processo per la tua applicazione, parlaci del tuo caso e vediamo insieme da dove ha senso partire.

Ciclo di rilascio accelerato: cosa cambia nella pratica

Un team che rilascia in produzione una volta al mese e un team che rilascia ogni giorno non differiscono solo per velocità. Differiscono per cultura, rischio percepito e capacità di rispondere al mercato.
Quando i rilasci sono rari, ogni deploy diventa un evento ad alto rischio. Si accumulano cambiamenti, si creano branch di lunga durata, i merge diventano conflitti. Il testing manuale prima del rilascio diventa un collo di bottiglia. E il feedback degli utenti arriva settimane dopo che la feature è stata sviluppata.
Quando i rilasci sono frequenti, ogni singolo cambiamento è piccolo. Il rischio è distribuito. Se qualcosa va storto, il rollback è semplice perché si sa esattamente cosa è cambiato. Il feedback arriva prima.
Passare da un modello all’altro richiede tempo e non è indolore. Richiede test automatizzati che diano fiducia, una pipeline CI/CD che funzioni, e un cambio di abitudine nel team. Ma il punto di arrivo è un’organizzazione che può rispondere alle esigenze del mercato in giorni, non in mesi.

Quando l’architettura applicativa moderna non è la risposta giusta

Sarebbe disonesto non dirlo: non ogni PMI ha bisogno di modernizzare la propria architettura applicativa adesso.
Se la tua applicazione è stabile, i rilasci sono prevedibili anche se lenti, e non hai piani di crescita significativi nel breve periodo, investire in platform engineering o CI/CD ha un ritorno basso. Il debito tecnico è un problema quando blocca la crescita o genera costi operativi alti. Se non è il tuo caso, ci sono probabilmente investimenti con ritorno più immediato.
Il modern application development ha senso quando il team sente il peso di ogni deploy, quando le nuove feature richiedono tempi sproporzionati, quando i bug in produzione sono frequenti e difficili da diagnosticare. Questi sono i segnali che il costo del debito tecnico supera il costo di affrontarlo.

FAQ

Q: Cos’è il debito tecnico e perché colpisce le PMI più delle grandi aziende?
A: Il debito tecnico è il costo nascosto delle scorciatoie prese durante lo sviluppo: codice non refactorizzato, dipendenze obsolete, test mancanti. Le PMI ne soffrono di più perché hanno meno risorse per pagarlo nel tempo, e spesso lo ignorano finché non blocca i rilasci o genera bug difficili da diagnosticare.
Q: Cosa si intende con modern application development?
A: È un insieme di pratiche che combinano architettura modulare, automazione del ciclo di rilascio (CI/CD), osservabilità e cultura del feedback rapido. L’obiettivo è rilasciare software in modo frequente e affidabile, senza accumulare debito tecnico a ogni sprint.
Q: Un’azienda con 20 dipendenti può permettersi il platform engineering?
A: Dipende da cosa si intende. Un team DevOps dedicato probabilmente no. Però strumenti come GitHub Actions, Railway o Render abbassano la soglia: puoi avere una pipeline CI/CD funzionante senza un team infrastrutturale interno, con un investimento iniziale contenuto.
Q: Quanto tempo ci vuole per modernizzare un’applicazione legacy?
A: Varia molto. Un refactoring mirato su un modulo specifico può richiedere qualche settimana. Una migrazione completa verso un’architettura cloud native richiede mesi. La strategia più affidabile è procedere per incrementi, non con una riscrittura totale.
Q: I microservizi sono la scelta giusta per una PMI?
A: Quasi mai, almeno all’inizio. I microservizi introducono complessità operativa che un team piccolo fatica a gestire. Un’architettura modulare a monolite ben strutturato è spesso la scelta più sensata, con la possibilità di estrarre servizi separati solo quando un dominio specifico lo richiede davvero.

Se la tua applicazione sta rallentando il team e ogni rilascio è diventato un momento di tensione, in Press Start possiamo fare un’analisi tecnica della situazione e aiutarti a capire da dove conviene partire. Raccontaci il tuo caso.

Il debito tecnico che non vedi nel bilancio

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.

Quattro tipi di manutenzione che spesso si confondono

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.

Il debito tecnico: come si accumula e quanto pesa

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.

Perché le PMI tendono a non manutenere

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.

Cosa deve contenere un contratto di manutenzione software

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.

Aggiornamento applicazione web aziendale: con quale frequenza?

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.

Evoluzione applicativo custom: manutenzione o nuovo sviluppo?

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.

Il vero costo di non avere un piano

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

Il segnale che molti ignorano

Hai un software che funziona. Lentamente, con qualche workaround, con procedure manuali che “si sono sempre fatte così” — ma funziona. Ogni volta che qualcuno propone di toccarlo, la risposta è la stessa: “meglio non rischiare”.
Questo è esattamente il momento in cui dovresti iniziare a preoccuparti.
Il software legacy aziendale non smette di funzionare da un giorno all’altro. Si degrada gradualmente, accumulando costi nascosti: sviluppatori che impiegano tre volte il tempo normale per fare una modifica, integrazioni impossibili con nuovi strumenti, bug che si correggono rompendo qualcos’altro. A un certo punto il costo di mantenere il sistema vecchio supera il costo di riscriverlo — e spesso le aziende se ne accorgono tardi.
In questo articolo vediamo come riconoscere quel punto di svolta, quali opzioni esistono per modernizzare un applicativo legacy, e quando la riscrittura completa è l’unica strada sensata.

Cosa rende “legacy” un software aziendale

La parola legacy non significa vecchio. Significa intrappolato.
Un software diventa legacy quando non riesci più a modificarlo con un costo accettabile. Può avere dieci anni o tre — se è stato scritto male, con dipendenze non documentate e zero test automatici, è già legacy.
I segnali concreti sono questi:

• Ogni modifica richiede settimane perché nessuno capisce più come funziona il codice
• Hai perso il contatto con chi lo ha sviluppato originariamente
• Gira su un server che non puoi aggiornare perché “rompe tutto”
• Non si integra con i nuovi strumenti che usi (CRM, ERP, piattaforme e-commerce)
• Ogni anno paghi qualcuno per “tenerlo in vita” senza aggiungere nulla

Questo ultimo punto è spesso il più sottovalutato. La manutenzione di un software obsoleto non è un costo fisso e prevedibile: tende ad aumentare ogni anno, perché le patch si accumulano e il sistema diventa sempre più fragile.

Le tre opzioni sul tavolo

Quando un’azienda decide di affrontare il problema del software legacy, di solito ha tre strade davanti.
Refactoring incrementale. Si interviene sul codice esistente, modulo per modulo, senza riscrivere tutto. Si migliorano le parti più critiche, si aggiungono test, si aggiorna la struttura interna mantenendo il sistema in produzione. È l’approccio più sicuro, ma funziona solo se l’architettura di base è ancora sensata.
Riscrittura completa. Si costruisce un sistema nuovo in parallelo, si migrano i dati e si spegne il vecchio. Permette scelte tecnologiche radicalmente diverse, ma richiede un investimento importante e un periodo in cui i due sistemi coesistono. Il rischio è reale: ci sono riscritture che durano anni e non arrivano mai in produzione.
Wrap and extend. Si lascia il core vecchio dov’è e si costruisce attorno a lui uno strato di API moderne. Il sistema legacy diventa un servizio interno che parla con il mondo esterno attraverso interfacce nuove. È un compromesso — non risolve il problema strutturale, ma può guadagnare anni di operatività a un costo contenuto.
Nessuna delle tre è universalmente corretta. La scelta dipende da quanto è compromessa l’architettura interna e da quanto tempo hai.

Quando il refactoring non basta

Il refactoring incrementale ha un limite preciso: funziona quando il problema è il codice, non l’architettura.
Se il tuo gestionale è stato costruito con un database monolitico dove tutto dipende da tutto, aggiornare il codice non risolve il problema strutturale. Puoi rendere il codice più leggibile, ma non puoi separare i moduli se il database non lo permette.
Stesso discorso per le tecnologie abbandonate. Un’applicazione scritta in un framework che non riceve più aggiornamenti di sicurezza non può essere “rattoppata” indefinitamente. Prima o poi il rischio diventa inaccettabile.
La riscrittura completa ha senso quando:

1. L’architettura impedisce fisicamente le funzionalità che ti servono
2. La tecnologia sottostante è fuori supporto e non aggiornabile
3. Il costo annuo di manutenzione supera quello che costerebbe riscrivere il sistema in due o tre anni

Su questo terzo punto: molte aziende non fanno mai questo calcolo. Continuano a pagare manutenzione senza chiedersi dove stiano andando quei soldi.

La migrazione software aziendale in pratica

La strategia che funziona meglio, nella maggior parte dei casi, è quella che i team tecnici chiamano “strangler fig”: si costruisce il sistema nuovo attorno a quello vecchio, un pezzo alla volta, fino a quando il vecchio non è più necessario.
Il processo tipico segue questo ordine:

1. Si mappa il sistema esistente: moduli, dipendenze, flussi di dati, integrazioni esterne
2. Si identificano i moduli più critici per il business e quelli più isolati (i secondi si migrano per primi)
3. Si costruisce il nuovo modulo in parallelo, con test che verificano che il comportamento sia identico
4. Si passa il traffico reale sul nuovo modulo, si monitora, si corregge
5. Si ripete per il modulo successivo

Questo approccio riduce il rischio perché non si fa mai un “big bang”: non c’è un giorno in cui si spegne tutto il vecchio e si accende tutto il nuovo. L’operatività aziendale non si interrompe.
Il rovescio della medaglia è il tempo. Una migrazione fatta così richiede mesi, non settimane. E richiede disciplina: bisogna resistere alla tentazione di aggiungere nuove funzionalità mentre si migra, o si finisce per non completare mai la migrazione.
Se stai valutando come affrontare un aggiornamento del codice legacy nella tua azienda, possiamo aiutarti a capire da dove partire — [scrivici.]

Il costo reale di non fare niente

Qui voglio essere diretto, perché è un punto su cui si tende a essere troppo diplomatici.
Rimandare la modernizzazione di un software legacy non è una scelta neutrale. È una scelta che ha un costo, anche se quel costo non appare in nessuna riga di budget.
Ogni sviluppatore che lavora su codice non documentato impiega più tempo del necessario. Ogni integrazione impossibile è una funzionalità che non hai. Ogni bug introdotto da una patch di emergenza è un rischio operativo. Questi costi si accumulano silenziosamente, anno dopo anno.
La nostra opinione su questo punto è netta: il “non tocchiamo niente che funziona” è una delle strategie tecnologiche più costose che una PMI possa adottare. Non perché riscrivere sia sempre la risposta giusta, ma perché non fare mai la valutazione è sempre la risposta sbagliata.

Come scegliere il momento giusto

Non esiste un momento perfetto per iniziare una migrazione software aziendale. Esiste però un momento oltre il quale diventa urgente, e riconoscerlo in anticipo fa la differenza tra una migrazione pianificata e una migrazione di emergenza.

Segnale	Urgenza	Azione consigliata
Modifiche semplici richiedono settimane	Media	Valutazione architetturale, piano di refactoring
Impossibile integrare nuovi strumenti	Media-Alta	Valutare wrap and extend o migrazione modulare
Tecnologia fuori supporto (framework, linguaggio)	Alta	Piano di migrazione con scadenza definita
Nessuno in azienda capisce più il codice	Alta	Audit del codice, documentazione, piano di riscrittura
Costo manutenzione annuo in crescita costante	Media	Analisi costi comparativa tra mantenimento e riscrittura
Downtime frequenti o bug in produzione ricorrenti	Critica	Intervento immediato, almeno su moduli critici

Il criterio più semplice: se i tuoi sviluppatori passano più tempo a capire il codice esistente che a scriverne di nuovo, hai già superato la soglia.

Cosa serve per partire

Prima di avviare qualsiasi progetto di modernizzazione di un applicativo legacy, servono tre cose che spesso mancano.
La prima è una mappatura onesta del sistema attuale. Non “cosa dovrebbe fare” ma “cosa fa davvero, in produzione, ogni giorno”. Questo include i flussi di dati, le integrazioni, le procedure manuali che compensano i limiti del software.
La seconda è un criterio di priorità. Non si migra tutto insieme. Si inizia dai moduli che bloccano di più il business o da quelli più isolati (più facili da separare). Senza un criterio esplicito, si finisce per migrare quello che è più interessante tecnicamente, non quello che serve all’azienda.
La terza è una stima realistica dei tempi. Le migrazioni software tendono a durare più del previsto. Non perché i team siano incompetenti, ma perché i sistemi legacy nascondono sempre sorprese: dipendenze non documentate, dati inconsistenti, logiche di business sepolte nel codice che nessuno ricordava.
Un progetto di aggiornamento del codice legacy ben pianificato parte sempre da un audit tecnico, non da un preventivo.

FAQ

Q: Cos’è il refactoring software legacy aziendale?
A: È il processo di ristrutturazione del codice esistente per renderlo più manutenibile e integrabile, senza cambiarne il comportamento visibile all’utente. Si interviene sull’interno del sistema, non sulle funzionalità. Serve quando il codice è diventato troppo complesso da modificare in modo sicuro.
Q: Quando conviene riscrivere il software aziendale da zero?
A: Quando l’architettura di base è compromessa al punto da rendere impossibile o eccessivamente costoso qualsiasi intervento incrementale. Di solito succede dopo anni di patch accumulate, o quando la tecnologia sottostante non riceve più aggiornamenti di sicurezza.
Q: Quanto tempo richiede una migrazione software aziendale?
A: Un modulo isolato si modernizza in qualche settimana. Una riscrittura completa di un gestionale aziendale richiede diversi mesi, con implementazione graduale per non interrompere l’operatività. I tempi esatti dipendono dalla complessità del sistema e da quanta documentazione esiste.
Q: Qual è la differenza tra refactoring e riscrittura completa?
A: Nel refactoring si interviene sul codice esistente pezzo per pezzo, mantenendo il sistema attivo. Nella riscrittura si costruisce un sistema nuovo in parallelo e si migra. Il refactoring è più sicuro ma non risolve problemi architetturali profondi; la riscrittura permette scelte radicalmente diverse ma richiede un investimento maggiore.
Q: Come si gestisce il rischio durante la migrazione di un software legacy?
A: Con la migrazione incrementale: si isola un modulo, lo si riscrive, si testa in parallelo con il vecchio sistema e si passa in produzione solo quando è stabile. Si evita così il “big bang” — quella giornata in cui si spegne tutto il vecchio e si accende tutto il nuovo, che è la fonte principale di fallimenti nelle migrazioni.
Q: Il software obsoleto PMI è un problema solo tecnico?
A: No. Un software obsoleto limita le decisioni di business: non puoi integrare nuovi strumenti, non puoi automatizzare processi, non puoi raccogliere dati in modo strutturato. Il problema tecnico diventa rapidamente un problema strategico, perché vincola cosa puoi fare come azienda.

Se stai valutando se e come modernizzare un applicativo legacy nella tua azienda, in Press Start partiamo sempre da un audit tecnico prima di qualsiasi proposta. Serve a capire cosa hai davvero, non a vendere una riscrittura che magari non ti serve — raccontaci il tuo caso.