Hai creato la tua app con l'AI: cosa manca per metterla in produzione davvero
Funziona sul tuo schermo, e per arrivare fin qui non hai scritto una riga di codice. Il salto verso qualcosa che regge utenti veri, dati veri e una notte di guasti non è un altro prompt: sono sei cose che nessuno strumento genera da solo.
Hai descritto quello che ti serviva a Lovable, a Bolt, a v0, a Replit — o a ChatGPT, riga per riga — e in qualche ora è comparso. Funziona: le schermate ci sono, i dati si salvano, l'hai fatto vedere a qualcuno e ha funzionato anche lì. La domanda adesso è una sola — lo posso far usare davvero? Questo articolo non serve a dirti che hai sbagliato. Serve a dirti cosa separa quello che hai da qualcosa che regge.
Prima: quello che hai fatto vale
C'è un riflesso, tra gli sviluppatori, di liquidare queste cose come giocattoli. È una reazione sbagliata, e per un motivo pratico: hai prodotto in poche ore la cosa che nei progetti veri costa mesi e quasi sempre viene male — una specifica funzionante. Non un documento di requisiti, non una riunione: un oggetto che si usa e che dimostra cosa deve fare il prodotto.
Quando entro in un progetto così, quel prototipo è la prima cosa che leggo, ed è più utile di qualsiasi capitolato. Sapere cosacostruire è metà del lavoro, e quella metà è fatta.
Il salto che nessuno strumento fa al posto tuo
Gli strumenti che generano applicazioni sono bravissimi a produrre ciò che si vede: schermate, campi, pulsanti, un flusso che fila. Sono strutturalmente deboli su ciò che non si vede, ed è esattamente lì che vive la differenza tra una demo e un prodotto. Sono sei cose, e nessuna nasce da un prompt.
1. Chi vede cosa
Se la tua app ha più utenti, la domanda decisiva è: cosa succede se uno cambia un numero nell'indirizzo del browser? In una demo, spesso, vede i dati di un altro. È il difetto più diffuso e il più grave, perché non si manifesta mai per sbaglio: si manifesta il giorno in cui un cliente prova per curiosità. La regola «ognuno vede solo i suoi dati» va scritta nel codice e verificata, non lasciata all'interfaccia che non mostra il link.
2. Chi ha le chiavi
Dove sta il codice? Chi possiede l'account su cui gira? E se quel servizio domani cambia prezzi o chiude, tu che cosa hai in mano? È la stessa domanda che faccio a chi arriva da un progetto lasciato a metà da un fornitore — e la risposta pesa più del codice: senza accessi non si manutiene niente.
La verifica è banale e va fatta subito, non quando serve: scarica il progetto. Quasi tutte queste piattaforme lo permettono, o si collegano a un repository Git. Se il file arriva, sei in una posizione di forza qualunque cosa succeda dopo. Se scopri che non si può, quella è già l'informazione più importante che avrai oggi.
3. Cosa succede quando qualcuno sbaglia
Prima o poi qualcuno cancella la cosa sbagliata. Non è un'ipotesi pessimista, è statistica. La domanda non è se, è da dove la recuperi. Un backup che nessuno ha mai provato a ripristinare non è un backup: è una speranza con un nome rassicurante.
In concreto: sai fare un export del database, sai dove finisce il file e hai provato almeno una volta a rimetterlo dentro? Molte di queste piattaforme il backup ce l'hanno — spesso nel piano a pagamento, spesso attivo ma mai verificato. La differenza tra averlo e saperlo usare si scopre sempre nel giorno sbagliato.
4. I costi che crescono da soli
Le piattaforme che generano app fanno pagare a consumo. Finché siete in tre non si nota; quando arrivano utenti veri, il conto cresce con una curva che nessuno ha deciso. Va guardato prima, non quando arriva la fattura: a volte conviene restare, a volte il calcolo si ribalta in fretta.
5. Le modifiche che rompono quello che funzionava
Il segnale che qualcosa non va non è che l'app abbia un bug: è che aggiungere una funzione ne rompa un'altra, e che ve ne accorgiate solo perché ve lo dice un utente. Servono controlli automatici sulle poche cose che non devono mai smettere di funzionare — non su tutto, solo su quelle.
6. Chi risponde alle tre di notte
Finché è un esperimento, non risponde nessuno ed è giusto così. Dal momento in cui qualcuno ci lavora sopra, «non funziona» diventa un problema con un orario. Non serve un presidio h24: serve sapere in anticipo chi guarda, dove guarda e quanto tempo può passare.
Le tre domande che ti dicono a che punto sei
Se vuoi una diagnosi in trenta secondi, sono queste:
- Se il servizio che hai usato chiudesse domani, avresti il codice?
- Se un utente cambiasse un numero nell'indirizzo, vedrebbe i dati di un altro?
- Se qualcuno cancellasse una tabella per sbaglio, da dove la recupereresti?
Una sola risposta «non lo so» significa che il problema c'è già. Semplicemente non si è ancora visto — e queste cose si vedono sempre nel momento peggiore.
Cosa non ti serve
Non ti serve ricominciare da zero, e diffida di chi te lo propone senza aver letto quello che hai: nella mia esperienza è più spesso la risposta comoda per chi preventiva che la scelta giusta per chi paga. Non ti serve nemmeno smettere di usare l'AI — la uso anch'io ogni giorno, e ne parlo apertamente in AI in azienda.
Ti serve che qualcuno decida cosa può generare da sola e cosa no. Le funzionalità nuove sì. Le regole su chi accede a quali dati, no — quelle si scrivono e si verificano, perché sono le uniche che se sbagliate non danno errore: danno solo un danno, più tardi.
Domande frequenti
Devo buttare via quello che ho fatto con l'AI?
Quasi mai. Quello che hai costruito è la cosa più preziosa che potevi produrre in quella fase: un prototipo che dimostra cosa deve fare il prodotto, deciso provando invece che riunendo. Di solito si tiene il modello dei dati e il flusso, si rifà la parte che tocca autenticazione, permessi e pagamenti. Buttare tutto è raro, e quando lo dico lo argomento.
Quanto costa portare in produzione un'app fatta con l'AI?
Dipende quasi solo da una cosa: se ci sono utenti diversi con permessi diversi. Un'app usata da te e da due colleghi è un lavoro breve. Un'app dove ogni cliente deve vedere i suoi dati e nessun altro è un lavoro serio, perché quella regola va garantita da codice e verificata, non sperata. Prima di un preventivo guardo cosa hai: mezz'ora, e serve prima di tutto a dirti se il gioco vale la candela.
Posso continuare a usare l'AI dopo?
Sì, e la uso anch'io tutti i giorni. Il punto non è smettere: è avere qualcuno che decide cosa può generare da sola e cosa no. Le funzionalità nuove sì, le regole di accesso ai dati no. È la stessa distinzione che applico nei progetti che consegno.
L'app ha smesso di funzionare e l'AI non riesce più a sistemarla. Cosa faccio?
È il momento più comune in cui mi chiamano, e ha una causa precisa: il progetto è cresciuto oltre quello che sta in una singola richiesta, quindi ogni correzione ne rompe un'altra e si gira in tondo. La via d'uscita non è un prompt migliore. Si scarica il progetto, si guarda cosa c'è dentro davvero, si isola la parte che si rompe e si stabilizza quella. Di solito è meno lavoro di quanto sembri da dentro il loop.
Come faccio a sapere se è già in pericolo?
Tre domande secche. Se domani il servizio che hai usato chiudesse, avresti il codice? Se un utente cambiasse un numero nell'indirizzo del browser, vedrebbe i dati di un altro? Se qualcuno cancellasse per sbaglio una tabella, da dove la recupereresti? Se anche una sola risposta è «non lo so», il problema esiste già — semplicemente non si è ancora visto.