La checklist di produzione che le app create con l'AI non superano (7 cose che si rompono dopo la demo)

Hai creato un'app con un app builder AI, o l'hai costruita in vibe coding, un prompt alla volta, nel giro di qualche serata. Funziona. Ma guarda le condizioni in cui funziona: il tuo telefono, il tuo Wi-Fi, il tuo account, dati che hai inserito tu stesso, una build generata un'ora fa. Una demo è un'app testata esclusivamente in condizioni favorevoli.

Pronta per la produzione significa l'esatto contrario: l'app continua a funzionare quando le condizioni favorevoli spariscono. Sconosciuti al posto tuo, un revisore al posto di un pubblico, mesi al posto di un pomeriggio.

Del perché esista questo divario abbiamo già scritto: il nostro articolo su i sette muri tra un prototipo e gli store ne mappa la distanza strutturale, e il nostro pezzo su creare un'app e gestirne una dà un nome al lavoro che comincia dopo il lancio. Quegli articoli finiscono con domande che vale la pena farsi. Questo le trasforma in esperimenti: sette test, ciascuno con una procedura concreta e una condizione di superamento inattaccabile, tutti eseguibili questa settimana. Se un test ti sembra noioso, è proprio quello il punto. La produzione è l'habitat naturale dei bug noiosi.

1. Uno sconosciuto può creare un account, andarsene e tornare

La demo non fa mai logout. Hai costruito l'app già autenticato, su un dispositivo che ti riconosce, così tutta la macchina degli account non è mai stata messa alla prova: l'email di conferma che finisce nello spam, il reset della password che non arriva mai, la sessione che muore a ogni riavvio, l'account che esiste sul tuo telefono e da nessun'altra parte. Gli account sono la prima cosa che uno sconosciuto tocca e l'ultima che una demo testa.

Il test: su un dispositivo che non ha mai visto la tua app (il telefono di un parente va benissimo, e per una web app una finestra di navigazione privata), crea un account con un indirizzo email che possiedi ma che non hai mai usato con l'app. Confermalo. Fai logout. Reimposta la password. Rientra. Chiudi l'app e torna il giorno dopo.

Superato quando: ogni passaggio funziona senza che tu debba toccare una dashboard, rispedire qualcosa a mano o spiegare un trucco per aggirare il problema.

2. L'app sopravvive vuota, offline e al doppio tap

La tua demo gira su dati che hai inserito tu, con una buona connessione, guidata dall'unica persona che sa dove non cliccare. Un utente reale parte senza niente di tutto questo: un account nuovo di zecca vede zero contenuti, la metropolitana taglia la connessione nel bel mezzo di un'azione e un pollice impaziente tocca due volte il pulsante di pagamento. Sono gli stati noiosi, e le app generate tendono a non gestirli, perché nessuno li ha chiesti nel prompt. Apple ci arriva prima dei tuoi utenti: nell'esperienza del nostro team di pubblicazione, durante la revisione un'app viene regolarmente aperta offline, e quello che mostra senza rete conta.

Il test: installa da zero, o apri l'app in una finestra privata, e usala in modalità aereo; taglia la connessione anche mentre un'azione è in corso. Poi percorri ogni schermata con un account nuovo che ha zero dati. Poi tocca due volte, veloce, ogni pulsante che crea o paga qualcosa. Tieni la parte dei pagamenti in modalità test del tuo provider, o usa un articolo economico da rimborsare subito dopo: quello che cerchi è se compaiono due ordini, non se i soldi si sono mossi.

Superato quando: nessuna schermata bianca, nessuno spinner infinito, nessun crash e nessun ordine duplicato.

3. L'App Store e Google Play la accetteranno

È qui che il risultato del tuo builder incontra il mondo esterno. Gli store vogliono binari nativi firmati, account sviluppatore (99 USD l'anno per Apple, 25 USD una tantum per Google), metadati per gli store e dichiarazioni sulla privacy che qualche anno fa non esistevano: la sezione Data safety di Google Play è obbligatoria da luglio 2022, i privacy manifest di Apple da maggio 2024. Molti strumenti prompt-to-app generano applicazioni web, perché una web app è ciò che un prompt può mettere online in un solo passaggio, quindi questo muro tende ad arrivare tardi. Una web app è una superficie legittima (GoodBarber pubblica una Progressive Web App accanto al nativo), ma rinuncia alla distribuzione degli store e, per la maggior parte degli utenti iOS, alle push. E poi arriva la revisione: delle prime submission gestite dal nostro team di pubblicazione nei 12 mesi fino ad aprile 2026, circa il 42% è tornato indietro respinto da Apple, ed è la percentuale di partenza per un team preparato, non una punizione per principianti.

Il test: tre domande, con risposte fatte di nomi, non di ipotesi. Il tuo strumento può produrre binari iOS e Android firmati? Hai gli account sviluppatore Apple e Google? Sai dire, oggi, quali dati raccoglie l'app, dove sono conservati e quali servizi di terze parti li toccano?

Superato quando: tre sì, per iscritto, prima di fissare una data di lancio.

4. Una push programmata stasera è sulla schermata di blocco domattina

Le push sono il motivo per cui un'app batte un sito web sulla retention, e sono anche la funzionalità che una demo simula meglio: sembra tutto collegato fino al primo telefono bloccato. La consegna è binaria, ed è per questo che il test è un esperimento notturno, non una domanda. Da iOS 16.4 (marzo 2023), iOS consegna le web push solo alle web app che l'utente ha deliberatamente aggiunto alla schermata Home; nel browser non suona niente. Quindi una web app creata con l'AI può sembrare identica a un'app nativa sul tuo schermo e ammutolire comunque nel momento in cui il telefono si blocca. Se non riesci nemmeno a trovare dove, nel tuo strumento, si programma una notifica push, la risposta ce l'hai già: il test è fallito.

Il test: programma una notifica push verso il tuo telefono per domattina alle 7:00, e stasera blocca il telefono.

Superato quando: al risveglio il messaggio è lì, sulla schermata di blocco.

5. Sai nominare ogni servizio da cui dipende l'app, e ogni fattura

Un'app generata è un'app assemblata. Sotto la demo c'è uno stack che il prompt ha scelto per te: l'hosting qui, un database là, un servizio di invio email, lo storage delle immagini, le analytics, magari un processore di pagamenti. Ognuno ha un login, un piano gratuito che finisce, chiavi che scadono e una fattura che cresce secondo una curva tutta sua. La demo nasconde tutto questo perché, per un utente in un pomeriggio, tutto è gratis e niente si è ancora rotto. La produzione fa una domanda più dura: quando l'app è giù alle 2 di notte, quale di questi servizi controlli per primo, e chi risponde?

Il test: scrivi l'inventario, partendo da dove chi non programma può davvero cominciare: cerca nella tua casella di posta tutti i messaggi “Welcome to” e “Verify your email” ricevuti mentre costruivi l'app, aggiungi ogni login creato lungo la strada, ogni addebito ricorrente sull'estratto conto della carta e tutto quello che elencano le pagine di integrazioni e fatturazione del tuo builder. Per ogni riga: chi è l'intestatario dell'account, quanto costa a 1.000 utenti e se si rinnova in silenzio.

Superato quando: ogni riga ha un responsabile e un prezzo. Se compilare la lista ti ha sorpreso, la sorpresa è il risultato del test.

Quell'inventario ti tornerà utile una seconda volta. I servizi che hai appena elencato sono anche quelli che dovresti sostituire se un giorno lasciassi il tuo builder, ed è lì che si annida il vero lock-in: l'abbiamo smontato in possedere la tua app non significa poterla portare via.

6. Una modifica va online senza trascinarsi dietro il resto

Il primo aggiornamento è il test più duro che un'app creata con l'AI deve affrontare, perché al lancio due orologi cominciano a ticchettare. Il primo è il tuo: gli utenti trovano bug, e correggerli via prompt può riscrivere in silenzio parti che già funzionavano, quello che chiamiamo regeneration drift (deriva da rigenerazione). Su una codebase generata, il ciclo della singola etichetta ha una forma tutta sua: cambi l'etichetta, rigeneri, poi scopri quale delle schermate che non hai toccato è cambiata comunque. Il secondo orologio appartiene ad Apple e Google: ognuno pubblica un nuovo OS principale ogni anno, Google alza ogni anno la versione minima di Android che un'app deve avere come target, e Apple rimuove le app che passano tre anni senza aggiornamenti e con quasi nessun download, dopo un preavviso di 90 giorni. Un'app che non puoi modificare in sicurezza è un'app che non puoi tenere pubblicata; abbiamo raccontato cosa si rompe in silenzio quando un'app smette di aggiornarsi per la versione al rallentatore.

Il test: cambia un dettaglio visibile (un'etichetta, un prezzo, un colore) e mettilo online: come aggiornamento sugli store se sei già pubblicato, o rigenerando e rimettendo online se non lo sei. Poi verifica che tre cose che funzionavano prima funzionino ancora.

Superato quando: la modifica è online, i tre flussi ritestati funzionano ancora e l'intero ciclo ha richiesto un pomeriggio, non una settimana.

7. Qualcuno può gestire l'app senza riaprire il builder

Tra sei mesi, quello che servirà all'app è lavoro operativo, non generativo: pubblicare l'articolo della settimana, cambiare un prezzo, rispondere a un cliente, inviare la push promozionale, leggere i numeri. Se ognuna di queste cose significa riaprire lo strumento che ha generato l'app e ri-promptare con cautela per non toccare quello che non deve rompersi, l'app ha un unico punto di rottura: tu, nel builder, per sempre. Un'app è gestibile quando le sue attività quotidiane vivono in un'interfaccia costruita apposta per loro, o possono essere passate a qualcun altro: un collega, o un agente AI collegato attraverso un protocollo aperto come MCP. Chi fa la metà gestionale del lavoro, e con quali strumenti, decide il futuro della tua app più di qualsiasi schermata tu abbia generato.

Il test: elenca le cinque attività di cui la tua app avrà bisogno ogni settimana. Per ciascuna, scrivi chi la fa e in quale strumento.

Superato quando: nessuna delle cinque risposte è “io, riaprendo il builder a colpi di prompt e sperando che vada bene”.

Fai il conto con onestà. Sette test superati: annuncia il lancio. Uno o due falliti: sai qual è il lavoro di questa settimana. Tre o più: quello che hai è un'idea validata, che è davvero preziosa, e merita fondamenta costruite per la parte che viene dopo.

Ecco perché possiamo pubblicare questa checklist senza battere ciglio: su GoodBarber, la maggior parte non è compito tuo.

I test 1 e 2 sono coperti in partenza. Account, sessioni, comportamento offline e stati vuoti arrivano come componenti nativi, temprati sulle migliaia di app live che la piattaforma ospita invece di essere generati da zero per la tua. Il test 3 è un servizio. GoodBarber compila veri binari nativi, Swift per iOS e Kotlin per Android, più una Progressive Web App dalla stessa configurazione. Le dichiarazioni sulla privacy richieste da Apple e Google condividono la fonte di verità con la build stessa, cioè le funzionalità che hai attivato, quindi dichiarazione e binario non possono divergere. E se preferisci non affrontare la revisione da solo, il team di pubblicazione che può farsi carico della tua submission ha recuperato il 91% dei respingimenti di Apple alla prima submission (tracciamento interno del team di pubblicazione, 12 mesi fino ad aprile 2026).

Il test 4 è infrastruttura: la pipeline delle push gira da un capo all'altro sulla piattaforma e muove diversi milioni di notifiche a settimana. Il test 5 si riduce a una riga sola, perché hosting, database, CMS, push, analytics e gateway di pagamento vivono in un unico abbonamento, con lo 0% di commissioni GoodBarber sulle transazioni e-commerce. Questa consolidazione è gran parte del motivo per cui il costo totale di proprietà si ferma a circa un decimo dello sviluppo su misura. E il test 6 è assorbito a monte: quando Apple o Google sposta un requisito, GoodBarber lo sistema una volta sola, e il tuo prossimo aggiornamento lo porta con sé.

Il test 7 è dove l'AI rientra in scena, questa volta dal lato giusto della demo. Ogni app GoodBarber può essere gestita da un agente AI attraverso il server MCP della piattaforma: dici al tuo assistente cosa ti serve, e l'articolo esce, la push viene programmata, il prezzo cambia e i numeri della settimana scorsa tornano in linguaggio semplice, da Claude, ChatGPT, Cursor o qualsiasi client compatibile con MCP. L'intero test 7 diventa una decisione di delega. E agent ready significa che l'app può essere gestita da un agente, non che si gestisce da sola: le regole e il controllo finale restano a te.

Il perimetro di GoodBarber sono le app di contenuti e il commercio mobile: non crea giochi, e un marketplace costruito su una pesante logica su misura merita una risposta diversa, che preferiamo darti subito. Dentro quel perimetro, questa checklist è esattamente ciò per cui la piattaforma è costruita. Da qualche parte nel mondo, un'app GoodBarber viene scaricata ogni 4 secondi, e i clienti paganti della piattaforma sono distribuiti in 152 paesi. Ecco a cosa porta superare questi test, anno dopo anno.

Cosa significa “pronta per la produzione” per un'app mobile?

Un'app pronta per la produzione sopravvive alle tre cose che una demo non contiene mai: utenti veri, la vera revisione degli store e il tempo reale. In concreto: gli sconosciuti creano account senza assistenza, l'app gestisce gli stati vuoti e offline, gli store accettano i suoi binari firmati e le sue dichiarazioni sulla privacy, le notifiche push vengono consegnate, ogni servizio del suo stack ha un responsabile con nome e cognome, può essere aggiornata senza rompere quello che già funziona e la sua gestione settimanale non dipende da una sola persona.

La mia app creata con l'AI è pronta per la produzione?

Esegui sette test: creazione e recupero dell'account su un dispositivo che non ha mai visto l'app, stati vuoti e offline, invio agli store con un binario nativo firmato, consegna delle push su un telefono bloccato, un inventario con i prezzi di ogni servizio dello stack, un aggiornamento che non cambia nulla oltre a ciò che doveva cambiare e la gestione settimana dopo settimana fuori dal builder. Superali tutti e sette e sei pronto ad annunciare. I fallimenti più probabili sono l'invio agli store, le push e il primo aggiornamento, perché molti app builder AI generano applicazioni web invece di binari nativi firmati, e la generazione non copre la conformità agli store né la manutenzione.

Un'app creata con l'AI può superare la revisione dell'App Store?

Solo come vera app nativa. Apple richiede binari firmati, dichiarazioni sulla privacy complete e un'app che sia più di un sito web reimpacchettato (Guideline 4.2). Il respingimento è la norma, non l'eccezione: Apple ha respinto circa il 42% delle prime submission gestite dal team di pubblicazione di GoodBarber nei 12 mesi fino ad aprile 2026, e il 91% di quei respingimenti è stato poi accettato dopo le correzioni.

Cosa si rompe per primo dopo il lancio di un'app creata con l'AI?

Le cose noiose, più o meno in questo ordine: l'autenticazione (email di conferma, reset della password, sessioni morte), poi gli stati vuoti e offline, poi la consegna delle push, poi il primo aggiornamento, dove correggere un bug via prompt può riscrivere parti che funzionavano. Lo schema dietro tutte è lo stesso: una demo viene testata in condizioni favorevoli, e la produzione le toglie una a una.

Mi serve uno sviluppatore per tenere in vita un'app creata con l'AI?

Se l'app è codice generato su uno stack assemblato, qualcuno deve farsi carico di quel codice e di quello stack, e questo è lavoro da sviluppatore, che tu sappia farlo o no. Su una piattaforma gestita come GoodBarber, il team di ingegneri della piattaforma mantiene codice, hosting, infrastruttura push e conformità agli store; tu gestisci l'app da un back office, o passi le attività quotidiane a un agente AI attraverso il server MCP. A te resta il ruolo dell'operatore, non quello dell'ingegnere.

Prossimo passo: niente di quello che hai costruito è sprecato. La demo ha già risposto alla domanda costosa, cioè se l'idea meriti un'app, e le tue schermate adesso sono la specifica. Inizia una prova gratuita di GoodBarber, ricostruisci l'idea su quella specifica ed esegui questa stessa checklist sul risultato: i primi sei test li copre la piattaforma, e per il settimo basta una frase a un agente.