---
title: "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"
description: "Vendor lock-in PHP: le quattro forme di prigionia tecnologica nelle PMI e il decalogo anti-lock-in per garantire sovranità su codice, dati, infrastruttura."
canonical: "https://www.mauriziofonte.it/blog/post/evitare-vendor-lock-in-software-php-server-linux.html"
author: "Maurizio Fonte"
date: "2025-06-13T07:12:15+02:00"
modified: "2026-04-14T17:48:55+02:00"
section: "Compliance"
tags: ["Compliance", "Architettura Software"]
license: "Riuso e citazione consentiti con attribuzione e link alla fonte"
---

[Compliance](https://www.mauriziofonte.it/blog/cat/compliance.html) [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html)

# [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](https://www.mauriziofonte.it/blog/post/evitare-vendor-lock-in-software-php-server-linux.html)

Venerdì 13 Giugno 2025, alle 07:12 ![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](https://www.mauriziofonte.it/image/001770200-evitare-vendor-lock-in-software-php-server-linux.jpg)

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](https://boringtechnology.club/) 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](https://www.mauriziofonte.it/blog/post/gestire-debito-tecnico-server-linux-hetzner-ovh-post-subentro.html).

## 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](https://www.mauriziofonte.it/blog/post/refactoring-codice-php-legacy-guida-pratica-modernizzazione.html) è 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](https://eur-lex.europa.eu/eli/reg/2016/679/oj) 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](https://opensource.org/licenses): 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](https://12factor.net/build-release-run): 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:

```bash
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](https://adr.github.io/), 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](https://www.mauriziofonte.it/blog/post/importanza-versionamento-codice-git-azienda.html). 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](https://www.mauriziofonte.it/blog/post/automatizzare-deploy-laravel-server-linux-hetzner-ovh-con-deployer.html). 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](https://www.mauriziofonte.it/pages/about): 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](https://www.mauriziofonte.it/pages/contattami): 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.

Dall'articolo al lavoro vero

Questo problema di sicurezza, sul tuo sistema

Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti.

[Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteMigrare MySQL 5.7 EOL su Hetzner senza fermare il business: la strategia di replicazione che ho usato per spostare 78GB con quattro minuti di downtime12 Giugno 2025](https://www.mauriziofonte.it/blog/post/migrazione-database-mysql-guida-strategica-server-hetzner-ovh.html)[Articolo successivo »Difesa proattiva da bot e DDoS su PHP/Laravel Hetzner e OVH: come ho contenuto un attacco di credential stuffing da 14.000 richieste al minuto in 47 minuti con Nginx, Fail2ban e Cloudflare13 Giugno 2025](https://www.mauriziofonte.it/blog/post/difesa-proattiva-proteggere-php-server-dedicato-ddos-bot.html)

### Articoli correlati a 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

- [Vendor lock-in nei servizi cloud: rischi reali e strategie di uscita per PMI](https://www.mauriziofonte.it/blog/post/vendor-lock-in-cloud-rischi-strategie-uscita-pmi-italiane.html)

  Un cliente aveva tutto su Azure: database managed, storage, CDN, Active Directory. Quando il contratto Enterprise è scaduto e il rinnovo era · 22 Dicembre 2025

  ![Vendor lock-in nei servizi cloud: rischi reali e strategie di uscita per PMI](https://www.mauriziofonte.it/image/003640070-vendor-lock-in-cloud-rischi-strategie-uscita-pmi-italiane.jpg)
- [Open Source in azienda: perché le tecnologie aperte sono la scelta strategica che non puoi più ignorare](https://www.mauriziofonte.it/blog/post/open-source-azienda-scelta-strategica-competitivita.html)

  L'adozione di tecnologie open source non è più una scelta tecnica ma strategica. Questo articolo analizza i benefici concreti per le PMI dal · 19 Mag 2025

  ![Open Source in azienda: perché le tecnologie aperte sono la scelta strategica che non puoi più ignorare](https://www.mauriziofonte.it/image/001180070-open-source-azienda-scelta-strategica-competitivita.jpg)
- [Lock-in tecnologico: quando la scelta sbagliata può intrappolare la tua azienda per anni](https://www.mauriziofonte.it/blog/post/lock-in-tecnologico-rischi-pmi-scelte-strategiche.html)

  Il lock in tecnologico è un rischio reale per le aziende che scelgono soluzioni proprietarie senza valutare le conseguenze a lungo termine. Scopri · 6 Mag 2025

  ![Lock-in tecnologico: quando la scelta sbagliata può intrappolare la tua azienda per anni](https://www.mauriziofonte.it/image/000950070-lock-in-tecnologico-rischi-pmi-scelte-strategiche.jpg)
- [Contratti di manutenzione software: cosa deve contenere per proteggere la PMI](https://www.mauriziofonte.it/blog/post/contratti-manutenzione-software-contenuto-protezione-pmi.html)

  Subentro dopo un fornitore precedente. Il contratto firmato dall'azienda non menzionava la proprietà del codice sorgente, non prevedeva escrow, · 23 Dicembre 2025

  ![Contratti di manutenzione software: cosa deve contenere per proteggere la PMI](https://www.mauriziofonte.it/image/003210070-contratti-manutenzione-software-contenuto-protezione-pmi.jpg)
- [Subentro forzato su un progetto PHP critico: il protocollo che applico nelle prime 72 ore quando lo sviluppatore non risponde più](https://www.mauriziofonte.it/blog/post/guida-subentro-progetto-php-server-hetzner-ovh-aruba-developer-scomparso.html)

  Quando lo sviluppatore sparisce e il business dipende da un'applicazione PHP su Hetzner, OVH o Aruba, le prime 72 ore decidono se il subentro · 9 Giugno 2025

  ![Subentro forzato su un progetto PHP critico: il protocollo che applico nelle prime 72 ore quando lo sviluppatore non risponde più](https://www.mauriziofonte.it/image/001690070-guida-subentro-progetto-php-server-hetzner-ovh-aruba-developer-scomparso.jpg)

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about

---

## Come citare

> Maurizio Fonte, "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", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/evitare-vendor-lock-in-software-php-server-linux.html

Pubblicato: 2025-06-13 · Aggiornato: 2026-04-14.

**Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.