Consulenza strategica IT per PMI: quattro scenari concreti in cui uno sviluppatore freelance non basta e serve un consulente senior

Qualche settimana fa il titolare di una PMI italiana che sviluppa una piattaforma SaaS gestionale per studi professionali mi ha posto in videocall una domanda molto diretta: "ho il mio sviluppatore, che è bravo e lavora con noi da quattro anni, a cosa mi serve in più un consulente?". È una domanda legittima e la risposta richiede onestà, perché in molti casi la PMI non ha davvero bisogno di un consulente strategico e il bravo sviluppatore basta. Ma esistono scenari specifici, ricorrenti e misurabili nei loro costi di errore, in cui uno sviluppatore - anche eccellente sul piano tecnico - fallisce per ragioni che non dipendono dalla sua competenza ma dal tipo di decisione che la situazione richiede. In quei scenari, non ingaggiare un consulente senior costa alla PMI molto più di quanto costerebbe la consulenza.

Nei quattro anni in cui ho lavorato come consulente senior per PMI italiane che avevano già sviluppatori interni o freelance di fiducia, ho visto lo stesso pattern ripetersi in forma quasi identica in quattro contesti specifici. Ognuno di questi quattro scenari ha prodotto, nelle PMI dove è stato gestito solo dallo sviluppatore interno, un costo economico documentabile che va da qualche decina di migliaia di euro fino a cifre superiori ai duecentomila, sempre evitabile con una consulenza strategica ingaggiata al momento giusto. In questo articolo ti racconto i quattro scenari con casi anonimizzati del 2025-2026 - settore generico e contesto tecnico astratto per proteggere la privacy dei clienti - e il motivo per cui ciascuno di essi richiede una figura diversa dal puro sviluppatore.

Cosa succede concretamente quando una PMI confonde lo sviluppatore freelance con il consulente strategico?

Succede che decisioni con implicazioni strategiche, legali o di business vengono prese da chi ha un punto di vista esclusivamente tecnico, con due conseguenze tipiche: la prima è che scelte corrette sul piano del codice producono disastri sul piano del business (come nel caso di migrazioni tecnicamente impeccabili ma che ignorano requisiti di compliance); la seconda è che decisioni che avrebbero richiesto un non-intervento disciplinato vengono affrontate con attivismo tecnico che peggiora la situazione. Lo sviluppatore freelance ottimizza per "risolvere il problema tecnico davanti a lui"; il consulente strategico ottimizza per "capire qual è il problema reale di business da risolvere e scegliere la strada con il miglior rapporto rischio/ritorno per l'azienda" - che spesso è una strada tecnicamente meno interessante ma strategicamente più corretta. Dei quattro scenari che ti racconto sotto, in tutti e quattro il costo dell'errore si è materializzato nel tempo che va dai tre ai diciotto mesi dopo la decisione sbagliata, cioè esattamente nel momento in cui diventa molto più costoso correggere la rotta.

Scenario 1 - Adeguamento NIS2 pre-scadenza: quando una PMI del settore servizi digitali rischia l'esclusione dal mercato

Nel giugno 2025 sono stato contattato dal legale rappresentante di un'azienda italiana del settore dei servizi digitali essenziali (uso deliberatamente la terminologia generica introdotta dalla stessa direttiva NIS2, vedi più avanti) che era stata ufficialmente classificata come soggetto essenziale ai sensi della direttiva 2022/2555. La scadenza di adeguamento era fissata dal decreto italiano di recepimento a pochi mesi di distanza e l'azienda aveva ricevuto dal proprio legale una lista di ventisette requisiti tecnici e organizzativi da soddisfare. Lo sviluppatore interno - ingegnere del software bravo, competente, con quindici anni di Laravel e Symfony alle spalle - aveva guardato la lista per due ore e aveva restituito al board una frase che si è rivelata costosa: "è fattibile ma serve un audit serio, io so scrivere codice sicuro ma non so cosa chiede esattamente un auditor NIS2".

Il problema operativo era che l'azienda aveva quattro mesi di tempo reale prima della scadenza, non dodici o ventiquattro come avevano sperato di avere quando avevano rimandato il tema "per occuparci delle cose urgenti di business". Ogni requisito tecnico della NIS2 ha implementazioni plurime e compatibili con la norma, e il lavoro di un consulente in questa fase non è "scrivere il codice di compliance" - quello lo sa fare lo sviluppatore interno - ma scegliere quale delle cinque o sei implementazioni possibili di ciascun requisito è più economica da realizzare nel tempo disponibile, più difendibile in caso di verifica successiva, e più compatibile con l'architettura esistente senza richiedere rewrite massivi. Un esempio concreto: la direttiva richiede controllo degli accessi con autenticazione a più fattori per utenti privilegiati. Esistono almeno sei modi tecnicamente validi di implementarlo, da 2FA TOTP self-hosted fino a WebAuthn con Yubikey, passando per IdP esterni come Zitadel o Keycloak. La scelta corretta per quella specifica azienda non era la più moderna, era la più integrabile con l'applicazione Laravel esistente in otto settimane di lavoro effettivo senza bloccare l'operatività.

I riferimenti normativi che ho usato come base per il progetto sono tutti disponibili gratuitamente: il testo integrale della direttiva è pubblicato su EUR-Lex nella pagina ufficiale della Direttiva UE 2022/2555, le linee guida tecniche pubblicate da ENISA sono il riferimento operativo più dettagliato per capire cosa un auditor si aspetta realmente di vedere (consulta le linee guida ENISA per soggetti essenziali e importanti NIS2 pubblicate sul portale ufficiale dell'agenzia europea), e il decreto legislativo italiano di recepimento definisce le specificità nazionali della scadenza. Ho guidato il progetto per quattro mesi, con lo sviluppatore interno che ha eseguito le implementazioni tecniche e io che ho preso le decisioni di priorità, di trade-off, di interpretazione normativa. L'audit del consulente NIS2 esterno a dicembre 2025 è stato superato senza rilievi maggiori. Il costo della consulenza esterna è stato contenuto in una frazione del valore dei contratti enterprise che l'azienda ha potuto mantenere grazie alla compliance - cosa che ho documentato come pattern sistematico nell'articolo su come la compliance NIS2 e GDPR diventa vantaggio competitivo per conquistare clienti enterprise.

Stai affrontando in azienda un adeguamento normativo con scadenza ravvicinata e il tuo sviluppatore sta dicendo "posso farlo io ma non so esattamente cosa serve"? Nel mio profilo professionale trovi la storia concreta dei progetti NIS2 e GDPR che ho condotto in prima persona come lead tecnico per PMI italiane, con contesti anonimizzati e numeri reali. La differenza fra un adeguamento fatto bene al primo colpo e uno che richiede rilavorazione dopo l'audit è quasi sempre la stessa: avere qualcuno che ha già letto, interpretato e applicato quella specifica normativa su progetti analoghi.

Scenario 2 - Data breach: cosa fare nei primi trenta minuti quando l'azienda scopre di essere stata compromessa

Nell'ottobre 2025 mi ha chiamato d'urgenza un CTO di una PMI italiana operante nell'e-commerce B2B di prodotti professionali. Uno dei loro amministratori aveva notato la mattina presto che la console di amministrazione aveva un comportamento strano: due righe di codice JavaScript non presenti nel repository Git erano apparse in una pagina interna. Lo sviluppatore interno - che aveva scritto personalmente il sistema ed era l'unico che lo conosceva in profondità - aveva fatto la cosa tecnicamente corretta ma strategicamente sbagliata: aveva immediatamente modificato il file compromesso, rimosso lo script iniettato, e aveva chiamato il CTO per informarlo del fatto. Al momento della mia chiamata, mezz'ora dopo il primo intervento, l'evidenza forense era già parzialmente distrutta.

La corretta gestione di una sospetta intrusione nei primi trenta minuti non è "ripulire il sistema". È esattamente l'opposto: congelare lo stato del sistema per permettere un'analisi forense che ricostruisca come l'attaccante è entrato, cosa ha fatto, e cosa potrebbe aver copiato o alterato. Uno sviluppatore bravo ha l'istinto di mettere mano al problema tecnico che vede; un consulente di sicurezza informatica con esperienza di incident response ha la disciplina di non toccare nulla prima di aver prodotto uno snapshot completo del filesystem, della memoria attiva, dei log di sistema e applicativi, e delle connessioni di rete in essere. Senza questa disciplina iniziale, in nove casi su dieci la successiva indagine forense diventa speculativa e non fornisce risposte affidabili sulla portata del danno - che è esattamente l'informazione di cui l'azienda ha bisogno per decidere se notificare il Garante Privacy entro 72 ore ai sensi dell'articolo 33 del GDPR, cosa che le linee guida del Garante italiano disponibili sul portale ufficiale richiedono esplicitamente con stime quantitative dell'impatto.

Nel caso del cliente dell'e-commerce B2B, la ricostruzione post-fatto ha richiesto sei giorni invece dei normali due, proprio perché lo sviluppatore interno aveva alterato l'evidenza forense nel primo intervento. L'attaccante era entrato attraverso una credenziale di un amministratore ex-dipendente che non era stata revocata quando la persona aveva lasciato l'azienda tre mesi prima - un problema di processo aziendale, non di codice. Aveva installato una webshell minimale in un file di configurazione PHP legacy non sotto controllo versione, e aveva esfiltrato le credenziali di API di 340 clienti B2B, tutte oggetto di notifica obbligatoria al Garante Privacy. Il costo totale dell'incidente - incluse le multe potenziali, le notifiche legali ai clienti, le due settimane di downtime del team tecnico, e il danno reputazionale con i clienti enterprise - è stato documentato dall'azienda in una cifra a sei zeri bassi, ma probabilmente sottostima l'impatto reale perché molti effetti indiretti si manifestano solo nei mesi successivi. Se avessero avuto una procedura di incident response scritta e provata prima dell'incidente, come quella che ho documentato operativamente nell'articolo su cosa fare nei primi trenta minuti di una sospetta intrusione per uno sviluppatore PHP, molti di quei costi sarebbero stati evitati.

Scenario 3 - Crescita organizzativa da 10 a 50 dipendenti: quando l'architettura che andava bene a 10 persone strangola il business a 30

Il settembre scorso mi ha contattato il CEO di una PMI italiana che sviluppa software verticale per il settore edilizio. L'azienda era cresciuta in due anni da dodici a trentotto persone sulla spinta di un contratto strategico con un gruppo industriale e aveva davanti una pipeline di vendita che richiedeva di raddoppiare ancora il team nei dodici mesi successivi. Lo sviluppatore che aveva fondato la parte tecnica - ora Chief Technology Officer della società - gli stava dicendo da sei mesi che il sistema funzionava, reggeva il carico, e la velocità di sviluppo era "accettabile". La realtà misurabile raccontava una storia diversa. Il tempo medio di onboarding di un nuovo sviluppatore era salito da tre settimane a sette. Il numero di bug in produzione che richiedevano hotfix d'emergenza era passato da uno al mese a cinque. I deploy si erano diradati da dieci al giorno a tre alla settimana. Il CTO non vedeva nessuno di questi numeri perché non li stava misurando - come tipicamente succede quando il fondatore tecnico diventa responsabile di un'organizzazione che è cresciuta oltre la sua zona di comfort.

Il problema strategico era che l'architettura applicativa, il modello organizzativo del team, e il processo di sviluppo erano ancora quelli ottimizzati per un team di tre-quattro persone che condividevano ogni decisione a voce. Il sistema non era "sbagliato" - era stato ragionevole al momento della sua creazione e aveva sostenuto la fase di prodotto iniziale. Ma le stesse scelte architetturali diventavano un collo di bottiglia strangolante a trentotto persone, e sarebbero diventate un disastro di proporzioni significative a settantacinque. Il CTO non aveva la prospettiva né gli strumenti di misurazione per riconoscere questo shift, perché dalla sua prospettiva "nulla era cambiato" - era la stessa codebase di sempre, lui lavorava nello stesso modo di sempre. Il cambiamento non era tecnico, era di scala.

Il mio intervento in questo tipo di scenario è diverso dagli altri due: non produco deliverable di codice, produco deliverable strategici. In quel caso specifico ho prodotto tre documenti in otto settimane: un assessment scritto delle sette aree di rischio architetturale del sistema, con priorità basata sui numeri di crescita pianificati; un piano di modernizzazione modulare in cinque fasi spalmate su diciotto mesi, con milestone misurabili e metriche di successo definite in anticipo; un piano organizzativo del team tecnico che definiva cinque ruoli con responsabilità chiare, un processo di code review formale, un modello di ownership dei moduli del sistema. Il CEO ha passato i documenti alla board, sono stati approvati, e il CTO è stato affiancato (non sostituito) da un architetto senior esterno per la fase di modernizzazione. Dodici mesi dopo, il tempo di onboarding è sceso a due settimane, i bug critici in produzione sono quasi azzerati, e la velocità di sviluppo misurata in feature rilasciate per settimana è triplicata. Nessuno di questi miglioramenti richiedeva un consulente più bravo dello sviluppatore interno sul piano tecnico - richiedeva una prospettiva esterna che riconoscesse lo shift di scala prima che diventasse una crisi irrimediabile.

Scenario 4 - Subentro dopo uno sviluppatore freelance sparito: recuperare il controllo di un'infrastruttura senza passaggio di consegne

Il pattern più ricorrente fra tutti e quattro gli scenari che gestisco è il subentro dopo la sparizione dello sviluppatore originario - una situazione che ho visto ripetersi almeno sei volte negli ultimi diciotto mesi con variazioni minime. La dinamica è sempre la stessa: PMI italiana con un prodotto software critico per il business, costruito e gestito da anni da un singolo sviluppatore freelance, che improvvisamente smette di rispondere per ragioni che possono essere malattia, cambio di carriera, conflitto economico non risolto, o semplicemente volontà di uscire dal mercato freelance. Il titolare della PMI si ritrova con un'infrastruttura che funziona ma che nessuno in azienda sa come toccare, password amministrative che conosceva solo lo sviluppatore sparito, e ragioni legali che complicano ogni intervento tecnico - perché il server, l'account del provider, il dominio, il repository git sono spesso intestati alla persona sparita e non all'azienda.

In questi scenari, il titolare ha istintivamente bisogno di trovare "un altro sviluppatore che prenda in mano la cosa". È la reazione naturale ed è anche, quasi sempre, la reazione sbagliata nei primi giorni. La corretta gestione di un subentro non documentato nelle prime settantadue ore non è tecnica ma legale e documentale: bisogna mappare la proprietà legale di ogni risorsa infrastrutturale coinvolta, formalizzare tentativi di contatto con lo sviluppatore sparito per mettere in sicurezza le mosse successive, avviare le procedure di change of ownership presso i provider (che tutte le piattaforme serie hanno documentate ma nessuna pubblicizza in prima pagina), e solo dopo aver legalmente legittimato l'intervento iniziare a toccare le macchine. Chi aggira questa disciplina si espone a contestazioni civili o - nel peggiore dei casi - a esposti per accesso abusivo a sistema informatico ex articolo 615-ter del codice penale, come ho visto accadere in almeno due casi in cui lo sviluppatore originario è ricomparso mesi dopo rivendicando la proprietà della macchina.

Il consulente senior in questa fase non sta facendo lavoro tecnico, sta facendo governance del rischio. Mappa chi possiede cosa, quando possono intervenire i provider, in quale ordine si possono toccare i sistemi, quale documentazione produrre per proteggere legalmente le mosse dell'azienda. È un tipo di competenza molto specifica che uno sviluppatore freelance non sviluppa mai perché non ha mai avuto bisogno di svilupparla - un bravo sviluppatore pensa al codice, non al contratto di intestazione del server su Hetzner. Un paio di mesi fa ho documentato in dettaglio un caso particolarmente istruttivo di questo tipo, quello di un'azienda italiana del settore nautico B2B dove la gestione corretta dei primi tre giorni ha permesso di recuperare completamente il controllo dell'infrastruttura in sei giorni invece delle normali tre-sei settimane, e il racconto completo è nell'articolo sul recupero di un server dedicato Hetzner con sviluppatore sparito in sei giorni tra trasferimento di proprietà e audit. La differenza fra i sei giorni del caso corretto e le sei settimane tipiche del caso gestito male è sempre e solo nella disciplina dei primi tre giorni.

Come riconoscere se ti serve un consulente strategico invece di un altro sviluppatore

Se sei il titolare o il responsabile IT di una PMI italiana e stai leggendo questo articolo, probabilmente una delle quattro situazioni che ti ho descritto risuona con qualcosa che hai affrontato o stai affrontando adesso. Il modo più pratico per capire se ti serve un consulente strategico oltre al tuo sviluppatore di fiducia è chiederti quattro domande concrete. La prima: il problema che stiamo per affrontare ha implicazioni legali, normative, o contrattuali che vanno oltre il codice? Se la risposta è sì, il tuo sviluppatore - per quanto bravo - non è la figura giusta per prendere la decisione da solo. La seconda: la scelta che stiamo per fare è reversibile con costo contenuto, oppure è una decisione con conseguenze che si dispiegano su anni? Se è del secondo tipo, la prospettiva di chi ha visto decine di decisioni analoghe in altre aziende è il tipo di valore che una consulenza esterna produce e uno sviluppatore interno non può produrre per definizione.

La terza: la situazione richiede qualcuno che abbia il coraggio di dire al business "stiamo sbagliando strada" anche a costo di impopolarità? Un dipendente o un freelance storico della PMI ha un costo politico interno per dare questo tipo di segnale - il consulente esterno no, ed è parte del suo valore. La quarta: quanto mi costa se sbagliamo questa decisione? Se la risposta è sopra i cinquantamila euro di costo potenziale, il costo di una consulenza strategica che spesso sta nell'ordine dei cinque-quindici mila euro è una polizza di assicurazione razionale, non una spesa elusiva. Le domande che avrebbero salvato decine di PMI italiane dall'ingaggio del consulente sbagliato sono ricorrenti e mirate: quale problema specifico stiamo comprando competenza esterna per risolvere, quali metriche ci dicono fra sei mesi se la consulenza ha prodotto valore, chi in azienda è il proprietario della decisione finale e chi quello dell'esecuzione. Senza risposte chiare a queste tre domande, qualunque consulenza - anche quella tecnicamente eccellente - rischia di produrre output che non incide sulla traiettoria del business, perché la direttiva NIS2 e il regolamento GDPR stanno cambiando significativamente il modo in cui le PMI italiane devono ragionare sulla sicurezza informatica come responsabilità di governance e non solo come problema tecnico, e rispondere a questa complessità crescente richiede un ruolo consulenziale che va oltre la pura implementazione tecnica.

Se la tua PMI sta affrontando uno dei quattro scenari che ho descritto, o se ha davanti una decisione strategica sulla propria infrastruttura IT che coinvolge implicazioni di sicurezza, compliance, architettura o governance del rischio, puoi contattarmi qui per una prima conversazione orientativa. Nelle prime due o tre chiamate - che non sono fatturate perché servono a verificare reciprocamente il fit del progetto - riusciamo quasi sempre a capire se il problema rientra nel mio perimetro di competenza e quale sarebbe l'intervento corretto. Se non rientra, te lo dico esplicitamente e ti indirizzo a figure più adatte quando le conosco - perché il peggior servizio che un consulente senior può fare alla PMI che lo contatta è accettare un progetto che sa di non poter eseguire al livello necessario, e questo vale in particolare per gli interventi su infrastrutture critiche dove l'errore non si paga in ore di rilavoro ma in danni economici significativi e in compromissioni di compliance che possono mettere a rischio l'intero business.