Costruire un MVP nel 2026: il vendor lock-in

Costruire un MVP nel 2026: il vendor lock-in

Il lock-in è una scelta che fai oggi e paghi domani. Non si vede quando lo fai, perché nel momento in cui scegli il servizio gestito il prezzo è zero, coperto dal credito di onboarding o dal free tier. Si vede quando lo paghi e a quel punto cambiarlo è un progetto, non una decisione. Ecco i cinque punti in cui una startup costruisce l'MVP senza accorgersene di costruirsi una gabbia, cosa cambia con EU AI Act e EU Data Act e le scelte che la rendono reversibile.

Costruire un MVP nel 2026 non è mai stato così veloce. I coding agent accelerano la scrittura del codice, i servizi gestiti tolgono il peso dell'infrastruttura, i modelli AI gestiti permettono di aggiungere funzionalità intelligenti in una frazione del tempo che serviva due anni fa. La stessa velocità rende più facile prendere decisioni che sembrano ragionevoli il primo giorno e diventano una gabbia il terzo anno. Il vendor lock-in è esattamente questo: una serie di scelte tecniche e contrattuali che sembrano tutte neutrali al momento e che sommate producono una dipendenza da cui è costoso uscire.

Per una startup che costruisce un MVP nel 2026 il rischio è più alto che in passato. Tre cose lo hanno reso più frequente e più pericoloso: i crediti di onboarding sono più generosi che mai; il regolatore europeo è entrato in scadenze reali; il mercato dell'AI ha separato nettamente chi ha un prodotto difendibile da chi ha un wrapper.

Perché il 2026 è diverso dal 2024

I crediti di onboarding che AWS, Google Cloud, Azure, OpenAI, Anthropic e Databricks offrono oggi a una startup in accelerazione sono enormi: si va dai ventimila ai duecentomila dollari di cloud, dai cinquemila ai cinquantamila dollari di API AI. Sono pensati per togliere il costo dell'infrastruttura dai primi 12-24 mesi di vita, il periodo in cui la startup deve dimostrare di avere un mercato. Funzionano: la prima fattura è zero, il cloud sembra gratis, il lock-in si prende senza che nessuno se ne accorga.

Ma il lock-in si manifesta quando il credito finisce e a quel punto si è già investito tutto il codice sopra quel fornitore. Le architetture più profonde, i servizi gestiti, i database proprietari, gli SDK nudi dei modelli AI, sono anche quelle più economiche da scrivere il primo giorno e più care da migrare dopo. Così la startup sceglie la strada più economica per partire e si ritrova la strada più cara per crescere.

Due novità del 2026 rendono la situazione ancora più stretta. La prima è il mercato: le valutazioni degli AI wrapper, prodotti basati su chiamate API dirette a un singolo vendor senza un data loop o un'integrazione di workflow proprietaria, hanno subito nel 2025-2026 una compressione dei multipli del cinquanta-settanta per cento. Costruire un wrapper sopra un singolo vendor significa scegliere una posizione di mercato sempre più scomoda. La seconda è il regolatore: l'EU AI Act e l'EU Data Act sono entrati in scadenze reali nel corso del 2026 e cambiano il conto della conformità a seconda di dove stanno i dati e i modelli.

I cinque lock-in che si prendono senza accorgersene

Quando una startup costruisce un MVP ci sono cinque punti in cui il lock-in si infila senza che nessuno lo decida. Sono tutti economici il primo giorno e tutti costosi il terzo anno.

Cloud: i servizi gestiti, non il calcolo

Il primo equivoco da chiarire è che il lock-in cloud non vive nel calcolo. I container Linux e Docker sono portabili ovunque: un cluster Kubernetes su AWS, GCP o Azure esegue la stessa immagine senza modifiche. Il lock-in vive nei servizi gestiti che circondano il calcolo: S3 per lo storage, RDS per il database relazionale, Step Functions per orchestrare, Elasticsearch gestito per la ricerca, Lambda per il glue. Sono comodi da utilizzare e sono lì che si creano le dipendenze.

Il caso più citato è quello di 37signals, la società che fa Basecamp e HEY. Nel 2022 spendeva 3,2 milioni di dollari l'anno in cloud AWS. Nel 2023 è uscita, portando i carichi di lavoro su server fisici Dell in colocation. L'investimento in hardware è stato ripagato in meno di diciotto mesi, la spesa annuale è scesa a circa 1,3 milioni di dollari e il risparmio proiettato a cinque anni è di oltre dieci milioni di dollari. Il team infrastruttura non è cresciuto: dieci persone hanno gestito l'uscita e gestiscono oggi l'on premise. Il caso è pubblico e i numeri sono verificabili sui documenti che 37signals ha rilasciato nel tempo.

Cosa vuol dire per una startup? Non che dovete uscire dal cloud. Vuol dire che la spesa cloud che vedi in fattura è gonfiata dai servizi gestiti che puoi sostituire. E che la scelta di usare S3 o RDS oggi è una scelta che paghi domani, se vorrai spostarti.

AI e LLM: l'SDK nudo è già un lock-in

Quando una startup scrive il suo primo MVP basato su un modello AI, la tentazione naturale è prendere l'SDK del vendor più forte al momento (OpenAI e Anthropic) e usarlo direttamente dentro il codice applicativo. È la scelta più veloce: la documentazione è buona, gli esempi funzionano, la latenza è bassa. È anche la scelta che ti lega al vendor per i prossimi cinque anni.

Due problemi pratici. Il primo è il costo delle architetture multi agente: un sistema che orchestra più agenti in catena consuma circa quindici volte i token di una chat singola e a quel volume il conto diventa significativo anche per una startup. Il secondo è il ritmo dei rilasci: ogni vendor cambia modello quasi ogni mese, depreca le versioni, modifica i prezzi. Chi ha cablato il proprio prodotto sull'SDK nudo è costretto a inseguire (forse è meglio spostare al trove queste energie, ndr).

La contromisura è semplice e poco costosa: mettere un gateway API compatibile con OpenAI davanti al modello fin dal giorno uno. LiteLLM, Portkey e OpenRouter sono tre opzioni valide e diffuse. Il tuo codice applicativo parla al gateway come se fosse OpenAI. Cambiare il modello è una riga di configurazione, non una riscrittura. Il gateway aggiunge latenza trascurabile e dà fallback automatico se il vendor è giù.

Dati e vector DB: la trappola più pesante

I dati sono la parte più pesante del lock-in, perché si accumulano nel tempo e sono costosi da spostare. In un MVP che fa RAG o ricerca semantica il punto critico è la scelta del vector database: Pinecone, Weaviate, Qdrant e etc... offrono API comode e indici performanti, ma sono servizi gestiti con il loro formato di file.

I numeri aiutano a capire. Pinecone costa circa 0,33 dollari al gigabyte al mese; un dataset di dieci milioni di vettori a 1536 dimensioni richiede circa 58 GB di dati grezzi, che con indici e metadati diventano facilmente duecento-trecento GB. A quel volume il conto mensile è significativo. E il lock-in è doppio: tecnico, perché i formati sono proprietari e gli indici non sono portabili; contrattuale, perché i dati sono dentro un servizio.

L'alternativa open source che ha reso Pinecone una scelta sempre meno giustificata per un MVP è PostgreSQL con l'estensione pgvector, o meglio ancora pgvectorscale per i casi più grandi. Instacart ha migrato da Elasticsearch e FAISS a PostgreSQL con pgvector e ha riportato un risparmio dell'80% sui costi e una riduzione di dieci volte dell'amplificazione di scrittura. Il benchmark di pgvectorscale mostra costi inferiori di circa il 75% rispetto a Pinecone a parità di prestazioni. Per un MVP che parte, pgvector è quasi sempre la scelta giusta: sta dentro il database che hai già, supporta transazioni ACID, ed è portabile ovunque vada PostgreSQL.

Architettura: i microservizi prematuri

La tentazione di partire con i microservizi è la manifestazione architetturale dello stesso errore: ottimizzare per la scala che non hai. Una startup con tre sviluppatori non ha il problema della scalabilità indipendente dei componenti e un monolite ben scritto si scompone più facilmente di quanto un sistema distribuito male si ricomponga.

Il caso Amazon Prime Video del 2023 è l'argomento più forte di questo decennio. Il team di monitoraggio qualità aveva costruito un'architettura serverless e a microservizi basata su AWS Step Functions, Lambda e storage intermedio S3. Il sistema era elegante sulla carta e ingestibile nella pratica: le commissioni di transizione di stato di Step Functions e i download ripetuti dei dati intermedi da S3 producevano un costo che saliva linearmente con il volume. Già al cinque per cento del carico previsto i colli di bottiglia rendevano il sistema inutilizzabile. La soluzione adottata dal team è stata ricompattare tutto in un monolite distribuito su container, con i tre componenti originali nello stesso processo. Il risultato: novanta per cento di riduzione dei costi infrastrutturali.

La regola pratica: parti con un monolite modulare, scomponi solo quando una parte ha bisogno di scalare in modo indipendente dalle altre. La maggior parte degli MVP non arriva mai a quel punto.

Contratti: il lock-in che non è tecnico

C'è un quinto lock-in che è il più ignorato e spesso il più doloroso. Non è tecnico: è contrattuale. Succede quando una startup affida la costruzione dell'MVP a un'agenzia o a un team di contractor e l'agenzia apre l'account cloud a nome suo, gestisce il repository GitHub sul suo profilo, mantiene la titolarità del codice fino al saldo completo. A quel punto la startup non può cambiare team senza ricostruire da zero l'infrastruttura e ripagare la proprietà intellettuale.

La difesa è semplice e va messa nero su bianco prima del primo sprint. Account cloud intestato alla startup, con la startup come organization owner; repository GitHub o GitLab di proprietà della startup, con l'agenzia come contributor esterno; trasferimento automatico della proprietà intellettuale al saldo delle fatture; nomi di dominio aperti direttamente dalla startup. Sono quattro clausole, non sono negoziabili se la startup vuole restare libera di cambiare software house.

Cosa cambia con la normativa 2026

Due regolamenti europei entrati in scadenza nel 2026 e nel 2027 cambiano il conto del lock-in per chiunque abbia utenti nell'Unione Europea.

Il primo è l'EU AI Act. Dal 2 agosto 2026 sono pienamente applicabili gli obblighi di trasparenza dell'Articolo 50 per qualsiasi sistema AI che interagisca con utenti europei: il sistema deve dichiarare esplicitamente all'utente che sta parlando con un'intelligenza artificiale, i contenuti generati devono avere marcature leggibili da macchina e watermark. Dal 2 dicembre 2027 diventano applicabili gli obblighi stringenti per i sistemi ad alto rischio elencati nell'Allegato III (credit scoring, eKYC, recruitment, decisioni su prestiti) e dal 2 agosto 2028 quelli dell'Allegato I sui prodotti. Le sanzioni arrivano al 7% del fatturato globale annuo per le pratiche vietate, al 3% per gli altri obblighi. Una startup con un chatbot generico ricade nel rischio limitato (disclaimer e watermark), ma se il prodotto tocca uno dei casi ad alto rischio il conto della compliance cambia radicalmente.

Il secondo è l'EU Data Act. Dal 12 gennaio 2027 i fornitori di servizi cloud non potranno più applicare tariffe di cambio provider né costi di egress dei dati. È una buona notizia per chi vuole uscire da un cloud, ma attenzione al falso senso di sicurezza: il regolamento toglie le barriere finanziarie all'uscita, non quelle tecniche. Le API proprietarie, i formati di file chiusi, i dati già strutturati dentro un servizio gestito restano ostacoli reali e il conto per migrare non è solo di costo cloud ma anche di ore di sviluppo. Per una startup l'implicazione pratica è duplice: scegliere provider che dimostrino portabilità concreta dei dati (PostgreSQL invece di database proprietari, container OCI invece di artefatti specifici del vendor) e cominciare fin da subito a esportare i dati in formati aperti.

Le cinque scelte prima della prima riga

Costruire un MVP senza costruirsi una gabbia è una sequenza di cinque decisioni prese prima che il codice esista. Sono tutte a basso costo iniziale e ad alto rendimento futuro.

La prima è il container. Tutto ciò che esegui deve essere un container OCI standard (Docker è la scelta ovvia), con la configurazione esplicita, senza artefatti proprietari del cloud. Un container che gira su AWS gira identico su GCP, Azure, su un cluster on premise, sul laptop di uno sviluppatore. Il container è il primo mattone della portabilità.

La seconda è l'infrastruttura come codice. Tutta l'infrastruttura deve essere descritta in Terraform o OpenTofu (il fork open source nato dal cambio di licenza di Terraform), versionata nel repository, applicabile con un comando. Questo permette di replicare l'ambiente su un altro provider in ore, non in settimane e di tenere sotto controllo il drift tra sviluppo, staging e produzione.

La terza è il gateway per i modelli. Se il prodotto usa AI, metti un gateway API compatibile con OpenAI fin dal primo commit. Il codice applicativo non chiama direttamente il vendor, chiama il gateway. Cambiare modello è una riga di configurazione, non una riscrittura.

La quarta è il database unico. Finché la scala lo permette, tutto va in PostgreSQL: i dati relazionali, i vettori con pgvector, i job con pg_cron o estensioni simili. Il database unico evita di dover mantenere consistenza tra sistemi diversi e ti dà portabilità gratuita su qualsiasi cloud o on premise.

La quinta è la titolarità dal giorno uno. Account cloud, repository, domini, proprietà intellettuale del codice: tutto a nome della startup dal primo sprint. Se stai lavorando con un'agenzia è una clausola del contratto, non una gentile concessione.

In pratica, per chi parte adesso

Se stai per firmare il prossimo contratto cloud o per accettare il prossimo credito di onboarding, il filtro da applicare è uno solo: questa decisione mi renderà più facile o più difficile uscire tra due anni? Se la risposta è più difficile, c'è un'alternativa che mi rende neutrale al riguardo. Per quasi tutte le scelte di un MVP, l'alternativa esiste e non è più costosa della prima versione.

Il punto non è evitare il cloud, o evitare l'AI, o evitare i servizi gestiti. Il punto è sceglierli in modo che, quando arriverà il momento di cambiare (e arriverà, perché il prodotto evolve, perché il mercato si muove, perché un vendor chiude una feature che ti serve), cambiare sia un progetto di settimane e non di trimestri.

Il lock-in che paghi domani è fatto delle scelte che fai oggi senza pensarci. Meglio pensarci.

Fonti

Easter egg

La cifra che fa più male del lock-in: circa il 27% della spesa cloud aziendale è sprecata in risorse sovradimensionate o abbandonate, secondo le stime più recenti del settore. Il primo lock-in di una startup spesso non è nel contratto, ma nelle risorse dimenticate che il contratto ha reso comode accendere.