600 milioni di dollari di ricavi annualizzati: è il dato dichiarato da Lovable il 24 settembre 2026. A giugno erano 500 milioni. Il numero misura quanto velocemente il vibe coding sta entrando nei budget aziendali, ma non dice se le applicazioni prodotte resteranno sicure, manutenibili e utili dopo il primo mese. Per una PMI, il rischio non è generare codice mediocre. È confondere la velocità del prototipo con la maturità della produzione.

La conseguenza pratica è semplice: uno strumento AI può accorciare molto la fase che porta dall’idea a una demo. Non elimina però proprietà del codice, revisione, test, controllo degli accessi, gestione dei segreti, rollback e responsabilità sul dato. Questa guida propone una pipeline minima per usare Lovable e strumenti simili senza trasformare un esperimento riuscito in un servizio fragile.

Il caso Lovable: il segnale dietro il numero

Secondo TechCrunch, il cofondatore Fabian Hedin ha dichiarato al summit HumanX di Amsterdam che Lovable ha superato 600 milioni di dollari di annual run-rate revenue. Ha inoltre affermato che due terzi delle aziende Fortune 500 usano il prodotto e che le app create sulla piattaforma ricevono complessivamente quasi un miliardo di visite al mese. Sono dati comunicati dall’azienda, non una verifica indipendente della qualità dei progetti.

È proprio questa distinzione a interessare una PMI. L’adozione dimostra che il modello «descrivo il prodotto e ottengo un’app» ha trovato un mercato. Il traffico aggregato dimostra che una parte dei progetti supera la demo privata. Nessuno dei due dati garantisce che il singolo progetto abbia permessi corretti, test ripetibili, costi sotto controllo o una persona capace di intervenire quando cambia una dipendenza.

Già a giugno, parlando dei 500 milioni di ricavi annualizzati dichiarati allora, TechCrunch osservava che il problema difficile non è costruire il software, ma mantenerlo mentre cambiano librerie, servizi esterni e infrastruttura. È il punto da cui partire: il vibe coding riduce il costo del primo rilascio. Il costo operativo arriva dopo.

Prima regola: definire cosa significa «pronto»

Un prototipo è pronto quando dimostra un flusso. Un prodotto è pronto quando quel flusso regge dati reali, errori, utenti con ruoli diversi e modifiche future. Se il team non scrive questa differenza prima di iniziare, il prototipo diventa produzione per inerzia: qualcuno condivide il link, arrivano i primi record reali e una prova temporanea diventa un sistema aziendale.

Per evitare il passaggio silenzioso, conviene stabilire due definizioni di completamento. La prima riguarda la demo: dati fittizi, accesso limitato, nessuna integrazione con sistemi critici, durata definita. La seconda riguarda la produzione: proprietario nominato, repository sotto il controllo dell’azienda, ambienti separati, test sui flussi principali, backup verificato, log consultabili, piano di rollback e revisione dei permessi.

Non serve un comitato. Per un portale interno di dieci utenti può bastare una pagina firmata dal responsabile del processo e dal referente tecnico. Serve però una decisione esplicita. «Funziona sul mio browser» non è un criterio di rilascio.

Una pipeline in sette gate, non sette prompt

La pipeline utile non misura quanti prompt sono stati necessari. Misura quali rischi sono stati chiusi prima di esporre l’app. Ogni gate produce una prova osservabile; se manca, il rilascio si ferma.

1. Perimetro e classificazione dei dati

Prima di generare una schermata, elenca dati, utenti e azioni. Un configuratore pubblico che calcola un preventivo indicativo ha un profilo diverso da un portale che legge fatture, indirizzi o note sanitarie. Per ogni campo chiedi: è necessario, chi può leggerlo, quanto resta memorizzato, dove viene inviato?

Nella fase di prototipo usa record sintetici. Non copiare un export del CRM «solo per provare». Se l’app deve parlare con WordPress, limita il primo collegamento alla lettura di contenuti pubblici o alla creazione di bozze. La pubblicazione, la cancellazione e la lettura di dati riservati arrivano solo dopo aver definito ruoli e audit.

2. Proprietà del codice e cronologia

Il codice deve uscire dal solo perimetro del builder. La documentazione Lovable sul Git sync descrive una sincronizzazione bidirezionale con repository GitHub, GitLab o Bitbucket: le modifiche fatte nella piattaforma diventano commit e quelle inviate al branch sincronizzato rientrano nel progetto.

Per una PMI questa funzione non è un accessorio per sviluppatori. È il punto in cui il progetto acquisisce una cronologia indipendente, può essere revisionato con strumenti standard e non dipende da una sola interfaccia. Il repository deve appartenere all’organizzazione, non all’account personale del fornitore. Almeno due persone devono sapere dove si trova e come recuperarlo.

Il branch collegato al builder non dovrebbe coincidere automaticamente con il percorso di produzione. La stessa documentazione consiglia di lavorare su branch separati quando il team richiede pull request per ogni modifica. Su GitHub, le protected branches possono imporre review e status check prima del merge. Questo trasforma la revisione da buona intenzione a regola tecnica.

3. Segreti fuori dal browser

Una chiave API incollata nel frontend non è nascosta. Il browser deve ricevere quel codice per eseguirlo, quindi un utente può leggerlo. La documentazione sui Secrets di Lovable distingue i valori server-side, cifrati e iniettati nelle Edge Functions, dalle variabili VITE_, che finiscono nel bundle pubblico.

La regola operativa è netta: chiavi di pagamento, token AI, credenziali email e password di servizi esterni vivono solo lato server. Il frontend chiama un endpoint controllato; l’endpoint valida l’utente, applica limiti e poi usa il segreto. Se una chiave è già comparsa nel codice o nella cronologia Git, spostarla non basta: va revocata e rigenerata.

Attiva anche un controllo prima del push. La push protection di GitHub può bloccare credenziali riconosciute prima che entrino nel repository. Non copre ogni possibile stringa sensibile, ma intercetta un errore comune nel momento meno costoso.

4. Autorizzazione provata con utenti diversi

Il login risponde alla domanda «chi sei?». L’autorizzazione risponde a «quali record e azioni puoi usare?». Molti prototipi superano la prima domanda e saltano la seconda. Il risultato è un’app in cui un utente autenticato può leggere il record di un altro cambiando un identificatore nella richiesta.

Se il backend usa Row Level Security, ogni tabella con dati utente deve avere policy esplicite e testate. Lovable include controlli sulle policy RLS nelle sue scansioni, ma la sua stessa documentazione di sicurezza precisa che gli scanner non sostituiscono una revisione adeguata al rischio.

Prepara almeno tre identità: amministratore, utente standard e utente non autenticato. Prova lettura, modifica, esportazione e cancellazione con ciascuna. Un test utile tenta intenzionalmente l’azione vietata e pretende un rifiuto dal server. Nascondere un pulsante nell’interfaccia non è un controllo di accesso.

5. Test sui flussi che fanno perdere soldi o fiducia

Non serve inseguire una copertura percentuale astratta. Parti dai flussi che, se rotti, bloccano un cliente o alterano un dato: accesso, invio del form, creazione del preventivo, cambio di stato, notifica e pagamento. Per ciascuno scrivi un caso normale, un input errato e un tentativo non autorizzato.

Lovable offre browser testing, test frontend con Vitest e React Testing Library, oltre a chiamate e test diretti delle Edge Functions, come documentato nella pagina Test and verify your app. La parte importante non è il nome dello strumento: è conservare i test nel progetto e rieseguirli dopo le modifiche.

Per le automazioni vale lo stesso criterio. La generazione AI può interpretare testo libero, ma importi, stati e permessi devono restare deterministici. Ho approfondito questa separazione in Automazioni AI: LLM o modello tipizzato. Se una risposta probabilistica decide direttamente un rimborso o un cambio di stato irreversibile, manca un confine.

6. Revisione umana e scansioni prima del rilascio

La review deve guardare la modifica, non soltanto l’app in esecuzione. Almeno una persona diversa da chi ha costruito il flusso controlla autorizzazione, gestione degli errori, dipendenze, dati inviati a terzi e comportamento in caso di timeout. Per codice o pacchetti non affidabili, conviene anche separare l’ambiente di analisi dalla macchina operativa: il principio è spiegato in Codice di terzi: VM o macchina di lavoro?.

La scansione automatica viene dopo, come rete aggiuntiva. Lovable dichiara un Quick scan su database, dipendenze ed esposizione MCP al momento della pubblicazione, oltre a un Deep scan su codice, accessi, input, segreti e dati sensibili. Un esito verde riduce il rischio noto; non certifica il processo né la correttezza delle regole aziendali.

7. Pubblicazione reversibile e osservabilità

Un rilascio è governato se puoi rispondere a tre domande: quale versione è online, come torno alla precedente, come scopro che qualcosa non funziona? Prima del go-live registra il commit o la versione, verifica il rollback e prepara un controllo sintetico sul flusso principale.

Log e alert devono distinguere errori tecnici da rifiuti corretti. Un tentativo senza permesso può produrre un 403 previsto; un timeout del servizio di pagamento richiede un alert. Non registrare nei log password, token, prompt completi con dati personali o payload di pagamento. Per i fornitori esterni, salva identificatore della richiesta, durata, esito e costo quando disponibile.

Definisci infine un responsabile operativo. La persona che ha scritto il primo prompt potrebbe non essere quella che gestirà incidenti e aggiornamenti fra sei mesi. Senza ownership, ogni piccola rottura torna al fornitore originale e il risparmio iniziale diventa dipendenza.

Caso pratico: un portale preventivi collegato a WordPress

Immaginiamo una PMI che usa WordPress per il sito e vuole un portale per raccogliere richieste, qualificare il lead e preparare una bozza di preventivo. Con un builder AI, la demo può nascere rapidamente: form, area riservata, tabella richieste e generazione assistita del testo.

Nella corsia prototipo si usano nomi inventati, un catalogo ridotto e nessuna credenziale del sito live. Il risultato atteso è verificare se le domande raccolgono abbastanza informazioni e se il team commerciale usa davvero la bozza. Dopo una settimana, la PMI può scartare il progetto senza migrare dati o revocare accessi critici.

Se il test dimostra valore, il passaggio alla produzione avviene per gate. Il codice viene sincronizzato nel repository aziendale. Il branch di produzione richiede una pull request e test verdi. Il collegamento a WordPress usa un account tecnico con permessi minimi e crea soltanto bozze. Le chiavi restano in funzioni server-side. Ogni venditore vede solo le richieste assegnate; il responsabile può riassegnarle; nessun utente del portale può pubblicare contenuti sul sito.

I test coprono login, creazione richiesta, doppio invio, allegato non valido, generazione fallita e tentativo di aprire il record di un collega. Il rilascio parte con due utenti, poi si estende. Vengono misurati tempo medio per preparare il preventivo, percentuale di bozze riscritte e numero di errori manuali. Se il tempo non cala o le correzioni restano alte, il progetto non scala. Questa è una decisione di prodotto, non una sconfitta tecnica.

Le metriche che contano dopo trenta giorni

I minuti necessari a generare la prima versione sono una metrica di demo. Dopo il rilascio servono numeri diversi: utenti attivi sul totale, completamento del flusso, errori per cento operazioni, tempo medio di ripristino, costo dei servizi esterni e ore spese in correzioni.

Aggiungerei una metrica spesso ignorata: quante modifiche possono essere consegnate da una persona diversa dall’autore iniziale. Se ogni intervento richiede ricostruire il contesto da una conversazione privata, il progetto non è mantenibile anche se il codice funziona.

La mia posizione è questa: il vibe coding è adatto alla produzione quando entra in una pipeline software normale. Non merita un processo più debole perché il codice è stato generato più velocemente. Merita controlli anticipati, perché la facilità di creare nuove funzioni aumenta il numero di modifiche e quindi la superficie di errore.

Chiusura operativa

Per una PMI, la sequenza minima è: prototipo con dati sintetici, repository aziendale, segreti lato server, permessi testati, controlli automatici, review indipendente, rilascio reversibile e metriche a trenta giorni. Se manca uno di questi passaggi, l’app può restare una demo utile. Non deve diventare produzione per abitudine.

Il dato di Lovable indica che questi strumenti non sono più una curiosità. Proprio per questo conviene smettere di valutarli dalla qualità della prima schermata. Il vantaggio competitivo non è generare più software. È riuscire a mantenere soltanto quello che produce valore senza trasferire il rischio su clienti, dipendenti e dati.

Fonti