Vendor lock-in nei progetti PHP delle PMI italiane: come ho liberato un cliente padovano da trentunmila euro l'anno di AWS e dall'unico sviluppatore che capiva il suo gestionale

A gennaio 2025 ho ricevuto la chiamata di un imprenditore padovano del settore distribuzione tecnica B2B. Mi hanno contattato dopo aver letto un mio articolo, e la prima domanda al telefono è stata: "secondo te è normale pagare trentunmila euro l'anno solo di bolletta cloud per un gestionale che gestisce ottocento ordini al mese?" Quando mi hanno mandato la fattura AWS dell'ultimo trimestre, ho contato le voci: Lambda, API Gateway, DynamoDB, Cognito, Step Functions, S3, CloudWatch, EventBridge, SES, KMS, Secrets Manager, e una decina di altre voci minori. Il loro gestionale di ordini era stato scritto due anni prima da un'agenzia cloud-native milanese, in modalità "serverless first," distribuito su circa 40 funzioni Lambda con la business logic frammentata in microservizi, dati su DynamoDB con schema NoSQL custom, autenticazione su Cognito con flussi OAuth specifici. La fattura AWS era pesante ma quasi tollerabile; il problema vero era che l'agenzia originale aveva appena triplicato il prezzo del retainer di manutenzione (da 1500 a 4500 euro al mese), e qualunque modifica veniva quotata a giornate uomo che non potevano essere validate da nessun altro fornitore, perché la conoscenza dell'architettura serverless custom era esclusiva dell'agenzia. Erano in trappola da entrambi i lati: prigionieri della piattaforma cloud e prigionieri del fornitore.

Il mio intervento è durato sei mesi e ha trasferito tutto il sistema su un singolo server dedicato Hetzner AX52 con uno stack Laravel + MySQL + Redis tradizionale. Il costo dell'infrastruttura è sceso da 31.000 euro l'anno a 1.080 euro l'anno (90 euro al mese, server + backup + monitoring). Il costo della manutenzione è sceso da 54.000 euro l'anno a un retainer mio di 12.000, quasi cinque volte più economico. E soprattutto, alla fine del progetto il cliente aveva un sistema documentato in italiano, con sorgenti su GitHub di sua proprietà, sviluppato in uno stack standard di mercato dove qualunque sviluppatore PHP può essere produttivo entro tre giorni. Ha ripreso il controllo della sua infrastruttura e dei suoi dati, e ha smesso di sentirsi un ostaggio. Questo articolo descrive le quattro forme di vendor lock-in che ho identificato sul campo nelle PMI italiane negli ultimi dieci anni di consulenza, e il decalogo anti-lock-in che applico in ogni nuovo progetto per garantire al cliente la sovranità tecnologica fin dal primo giorno.

Quanto costa, in euro veri, una decisione di lock-in presa due anni fa

Il vendor lock-in non è un concetto astratto da articolo di filosofia tecnologica: è una voce di costo concreta nel conto economico di una PMI, e il problema è che diventa visibile solo dopo, quando ormai la decisione architetturale di partenza è stata presa e cambiarla costa più di accettarla. La definizione operativa che uso con i clienti è semplice: il vendor lock-in è la differenza fra il costo annuale che stai pagando oggi per un sistema, e il costo annuale che pagheresti per lo stesso sistema su un'architettura "neutra" - più il costo una tantum della migrazione necessaria per passare da uno all'altro. Sul cliente padovano del 2025, questa differenza era 31.000 + 54.000 = 85.000 euro l'anno di costi sostenuti, contro una baseline neutra di 1.000 + 12.000 = 13.000 euro l'anno. La differenza era di 72.000 euro l'anno, ovvero circa 6.000 euro al mese di "tassa di lock-in" che il cliente stava pagando senza saperlo.

La domanda ovvia è: perché il cliente non se ne era accorto prima? La risposta è che le decisioni di lock-in vengono prese nei primi mesi di un progetto, quando il fornitore propone un'architettura "moderna" e "scalabile," e il cliente non ha gli strumenti per valutare quanto quella scelta lo legherà a vita. Sul cliente padovano, la proposta originale dell'agenzia milanese del 2023 era basata su un argomento attraente: "non dovrai gestire server, paghi solo quello che usi, scali automaticamente." Tutto vero in teoria. In pratica, per un gestionale B2B con carico prevedibile e ottocento ordini al mese (~30/giorno feriale), il modello "paghi solo quello che usi" si è tradotto in 31.000 euro l'anno di servizi cloud che un singolo server da 60 euro al mese avrebbe gestito senza sforzo. Il caso è esattamente la categoria di "decisione architetturale presa per ragioni di marketing tecnologico più che di business" che Dan McKinley ha analizzato nel suo influente articolo Choose Boring Technology e che è diventata negli anni un riferimento per chiunque progetti software per PMI: la regola dei "tre innovation token" che un progetto può permettersi di spendere su tecnologie nuove non testate, oltre i quali la complessità soverchia il valore.

Il pattern che vedo ripetersi è: agenzia cloud-native propone architettura serverless (innovation token #1), database NoSQL proprietario (innovation token #2), framework custom o BFF microservizi (innovation token #3), provider di autenticazione esterno (innovation token #4 - già fuori budget), e a quel punto il debito architetturale è già scritto nel destino del progetto. Il primo segnale d'allarme che insegno ai clienti a riconoscere è quando il fornitore parla solo di tecnologie e mai di costi totali a 5 anni: la domanda da fare è sempre "se fra tre anni decido di cambiare fornitore, quanto mi costa staccarmi da quello che state proponendo oggi?" La risposta a quella domanda è la migliore misura del lock-in che il fornitore ti sta vendendo, ed è esattamente la categoria di valutazione che dovrebbe far parte di un piano di consolidamento del debito tecnico nei 90 giorni successivi a un audit infrastrutturale.

Le quattro forme di lock-in che vedo nelle PMI italiane

Il lock-in non è una sola cosa: è una famiglia di patologie distinte, ognuna con cause, sintomi e cure diverse. Le quattro forme che incontro più spesso nelle PMI italiane sono lock-in di piattaforma, lock-in di architettura, lock-in di conoscenza, lock-in di dati. Nessuna è meno grave delle altre, e quasi sempre coesistono.

Il lock-in di piattaforma è quello del cliente padovano del 2025: il software è scritto in modo tale da essere portabile solo all'interno di un singolo provider cloud o di un singolo stack proprietario. Sintomo tipico: la fattura mensile cresce del 15-30% l'anno e il fornitore non riesce a spiegare perché. Il lock-in di architettura è quello del cliente che ha un sistema scritto in tecnologie open source (PHP, MySQL, Apache) ma in modo talmente "creativo" che nessun altro sviluppatore riesce a capirlo: framework custom dentro un framework, pattern di design "geniali" che violano ogni convenzione standard, file di configurazione XML generati da script bash che vengono inclusi da PHP. È il sintomo del "framework nel framework" che è probabilmente la causa numero uno per cui un cliente mi chiama dopo che il developer originale è scomparso. Il refactoring incrementale di codice PHP legacy che ho descritto in un articolo dedicato è quasi sempre la cura corretta per questa forma di lock-in, ma richiede mesi di lavoro pianificato.

Il lock-in di conoscenza è la forma più subdola e più frequente nelle micro-PMI italiane. Il codice può anche essere scritto bene, ma nessun documento spiega perché è stato scritto così, come si deploya, dove sono i backup, con quali credenziali si accede al server di produzione. Tutta questa conoscenza vive nella testa di una sola persona - quasi sempre lo sviluppatore originale, talvolta un dipendente IT interno - e quando quella persona se ne va, il sistema diventa di colpo ingestibile, anche se tecnicamente non è cambiato nulla. La quarta forma, il lock-in di dati, è quella per cui il sistema è stato progettato in modo tale che esportare i dati in un formato standard è impossibile o talmente costoso da risultare equivalente a una riscrittura. Il diritto alla portabilità dei dati è in realtà sancito esplicitamente dall'articolo 20 del GDPR consultabile su EUR-Lex per i dati personali, e nessun fornitore serio può oggi proporre un'architettura che renda l'export dei dati strutturalmente impossibile. Eppure capita. Sul cliente padovano del 2025, l'export degli ordini storici da DynamoDB è stato la fase più lunga del progetto: tre settimane di lavoro per ricostruire le relazioni fra entità che il modello NoSQL aveva volutamente denormalizzato.

Il mio decalogo anti-lock-in: open source di default, standard di fatto, niente over-engineering

La mia filosofia di sviluppo per i progetti PHP è strutturata in dieci principi non negoziabili che applico fin dal primo briefing tecnico con un nuovo cliente. Li chiamo "decalogo" per comodità, ma sono in realtà dei vincoli di progettazione che servono a garantire che il sistema che costruisco non possa, per costruzione, generare lock-in significativo. Il primo principio è la scelta di tecnologie open source con licenze standard riconosciute dalla Open Source Initiative come elenco ufficiale delle licenze approvate: PHP (licenza PHP), Laravel (MIT), MySQL/MariaDB (GPL/LGPL), Linux (GPL), Apache/Nginx (Apache 2.0/BSD). Nessuna licenza commerciale, nessuna licenza proprietaria, nessuna licenza con clausole "open core" che limitano l'uso commerciale.

Il secondo principio è l'aderenza stretta alle convenzioni del framework. Se uso Laravel, scrivo Laravel "vanilla" - controller, modelli Eloquent, route, middleware come la documentazione raccomanda - non un sotto-framework custom dentro Laravel. Il terzo principio è la separazione netta fra build, release e run secondo la metodologia 12factor.net che codifica le best practice per applicazioni cloud-portabili: nessuna scelta architetturale che leghi il codice a uno specifico provider di hosting. Concretamente, nel .env.example di un progetto Laravel anti-lock-in inserisco solo driver standard intercambiabili - niente SDK proprietari, niente endpoint hardcoded:

APP_ENV=production
APP_KEY=
APP_URL=https://app.cliente.it

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=app_cliente
DB_USERNAME=app_cliente
DB_PASSWORD=

CACHE_DRIVER=redis
QUEUE_CONNECTION=redis
SESSION_DRIVER=redis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379

MAIL_MAILER=smtp
MAIL_HOST=smtp.cliente.it
MAIL_PORT=587

FILESYSTEM_DISK=local

Ogni voce di questo file è un driver standard di Laravel che si può cambiare senza riscrivere una riga di codice applicativo. Il quarto principio è l'uso di formati di dati standard (JSON, CSV, SQL) per ogni interfaccia esterna, mai formati binari proprietari. Il quinto principio è la documentazione delle decisioni architetturali significative tramite Architecture Decision Records nel formato pubblico mantenuto da Michael Nygard sul sito ADR, in modo che qualunque sviluppatore futuro possa capire perché è stata presa una scelta e non solo cosa è stato implementato.

Gli altri cinque principi del decalogo sono operativi: il sesto è "git first" - repository del codice sempre intestato al cliente, mai al consulente, secondo i criteri che ho descritto nel mio articolo sull'importanza del versionamento del codice come prerequisito non negoziabile per la sopravvivenza tecnica di una PMI. Il settimo è "deploy automatizzato e documentato" - pipeline di deploy che funge da documentazione esecutiva, esattamente come ho descritto nel protocollo di deploy automatizzato con Deployer e GitHub Actions su server Linux Hetzner e OVH. L'ottavo è "infrastruttura agnostica" - il sistema deve poter girare su qualunque server Linux con stack LAMP/LEMP, non solo su un provider specifico. Il nono è "credenziali sempre del cliente" - il dominio è registrato dal cliente, l'account Hetzner/OVH è del cliente, l'account GitHub è del cliente, io sono un collaboratore con accessi limitati e revocabili. Il decimo è "trasferimento di conoscenza esplicito" - alla fine del progetto il cliente riceve un runbook operativo e una sessione di handover registrata.

Documentazione come prodotto finale, non come opzione

Il principio che insisto di più con i clienti è quello relativo alla documentazione, perché è quello che fa la differenza pratica fra un sistema "tecnicamente sano" e un sistema che il cliente può effettivamente governare. La regola che applico è: la documentazione fa parte del prodotto consegnato. Non è un extra opzionale, non è "lo facciamo se avanza tempo," non è "tanto il codice si auto-documenta." È un deliverable a tutti gli effetti, fatturato come tale, e senza il quale il progetto non è considerato concluso.

I quattro documenti che produco sempre alla fine di un progetto sono: il README operativo del repository, che descrive la struttura del progetto e come avviare l'ambiente di sviluppo locale; il runbook di produzione, che descrive l'architettura del server, le credenziali (in formato cifrato o riferimenti a un password manager del cliente), le procedure di deploy, di backup, di restore, di rollback; il documento delle Architecture Decision Records, che spiega le 5-10 decisioni di progettazione più importanti e perché sono state prese; il piano di manutenzione mensile, che elenca le verifiche da fare ogni mese (controllo log, verifica backup, test restore, monitoraggio metriche). Tutti questi documenti sono in italiano, scritti per essere leggibili da un imprenditore non tecnico, e versionati nel repository Git insieme al codice.

L'errore che vedo fare più spesso è considerare la documentazione come un'attività "in più" rispetto allo sviluppo, quando in realtà è la differenza fra consegnare un asset e consegnare un mistero. Sul cliente padovano del 2025, la documentazione finale è stata di 47 pagine totali distribuite fra runbook, ADR, e README. Tre pagine descrivevano la procedura di backup e restore, con il comando esatto da eseguire e l'output atteso, in modo che chiunque - io, un suo dipendente, un altro consulente - potesse testare il backup senza chiedere a nessuno. Il giorno della consegna ho fatto eseguire personalmente la procedura di restore al titolare dell'azienda dal terminale del server, in 8 minuti, senza il mio intervento. Quel singolo gesto ha dimostrato meglio di qualunque argomentazione che il sistema era veramente suo, non mio.

Proprietà di account, dati, IP: il contratto come strumento di sovranità

L'ultimo elemento del mio approccio anti-lock-in è di natura contrattuale, non tecnica. Tutti i miei contratti di sviluppo software contengono tre clausole non negoziabili che servono a garantire che il cliente sia, dal punto di vista legale, il proprietario al 100% di tutto ciò che produco per lui. La prima clausola riguarda la proprietà intellettuale del codice: il cliente acquisisce la titolarità completa di tutto il codice sorgente custom sviluppato per lui, a pagamento avvenuto del corrispettivo concordato. Nessuna licenza d'uso, nessuna royalty, nessuna clausola "ritorno al fornitore in caso di." Il codice è suo come se l'avesse scritto un suo dipendente.

La seconda clausola riguarda la proprietà degli account infrastrutturali. Tutti gli account necessari per il funzionamento del sistema (server Hetzner/OVH, registro dominio, account GitHub/GitLab del repository, account email transazionale, account servizi terzi come Stripe/PayPal, account di monitoring) sono intestati al cliente, con email del cliente e fatturazione al cliente. Io ricevo solo accessi delegati, sempre con il mio account personale, sempre revocabili in qualunque momento dal cliente senza il mio consenso. La terza clausola riguarda la documentazione e i runbook: tutta la documentazione prodotta è proprietà del cliente, in formato editabile (Markdown o documento Office), e versionata nel repository del cliente.

Queste tre clausole sembrano ovvie ma quasi nessun fornitore italiano le applica con questo livello di chiarezza, e il risultato è che la maggior parte delle PMI italiane scopre solo nel momento della crisi (fornitore scomparso, contenzioso, cambio di consulente) di non essere il vero proprietario del sistema che sta usando per fatturare. Il mio scopo è invertire questa dinamica fin dal primo giorno: il cliente deve sapere che potrebbe sostituirmi domani senza traumi tecnici né legali. Questa è la differenza fra un fornitore e un partner, ed è anche la migliore garanzia di qualità che posso offrire - perché sapendo di essere sostituibile in qualunque momento, l'unico modo che ho di conservare un cliente è continuare a generare per lui valore reale, non dipendenza. Se la tua PMI ha un sistema custom in produzione e non sei sicuro di essere il vero proprietario di codice, dati, account e documentazione, scopri come lavoro con i clienti sui principi di sovranità tecnologica: in dieci anni di consulenza ho visto che il fattore decisivo per la libertà operativa di un imprenditore è quasi sempre la qualità delle decisioni architetturali e contrattuali prese all'inizio del progetto, non la bravura tecnica del fornitore. Se invece sei già nella situazione descritta - sistema critico, fornitore unico, costi crescenti, sensazione di prigionia - e vuoi una valutazione operativa del tuo grado di lock-in con un piano d'azione concreto per riprendere il controllo, contattami per una consulenza: in due settimane ti consegno l'audit completo delle quattro forme di lock-in sul tuo sistema, la stima del costo di liberazione, e una proposta di piano di migrazione calibrata sui tempi e sul budget realistico della tua azienda.