Developer Mode vs Store

1. Introduzione

Nelle lezioni precedenti abbiamo già parlato di cosa sia una ChatGPT App, di quali strati sia composta e in cosa differisca dai vecchi plugin e dai semplici bot su OpenAI API. Ora passiamo al secondo tema importante: il ciclo di vita di una tale applicazione.

Se sviluppi servizi web da almeno qualche anno, la parola «lifecycle» non ti spaventa. Ogni prodotto ha un percorso basilare: «si è scritto in locale → si è rilasciato su staging → si è rilasciato su production → a volte si è rotto tutto → si è sistemato». Nell’ecosistema di ChatGPT con le App vale lo stesso, ma con alcune sfumature: compare il Dev Mode all’interno di ChatGPT e un’entità separata — lo Store.

È importante distinguere chiaramente due piani:

1. Dove vive fisicamente il tuo codice: server Next.js locale, Vercel, qualche cluster Kubernetes e così via. È il tuo mondo, lì sei tu il sovrano.
2. Come ChatGPT vede la tua App: come un insieme di metadati, URL e autorizzazioni, che si possono collegare in Developer Mode oppure confezionare come prodotto finito nello Store. Questo è già il mondo di OpenAI, con le sue regole, la revisione e gli utenti.

Questa lezione riguarda proprio il secondo piano. Ci appoggeremo sul tuo modello abituale di ambienti (dev / staging / prod), ma li osserveremo con gli occhi di ChatGPT. Il nostro obiettivo è che tu possa, in ogni momento, rispondere a qualche domanda. Quale codice sta eseguendo adesso la mia App? Chi la vede? Come fare esperimenti in sicurezza? E cosa significa davvero «aggiornare la App» nello Store?

2. Developer Mode: sandbox personale all’interno di ChatGPT

Cominciamo dalla cosa più piacevole per uno sviluppatore: una sandbox in cui si può rompere tutto senza far male quasi a nessuno.

Developer Mode è una modalità speciale in ChatGPT, nella quale puoi collegare le tue ChatGPT Apps direttamente via URL, senza passare per la revisione, senza pubblicare la App nello Store e senza mostrarla al mondo intero. Per spirito, è simile a localhost:3000 nel browser, solo che nel mondo di ChatGPT.

Come appare concettualmente

È più semplice immaginare lo schema così:

flowchart TD
    User("Interfaccia ChatGPT (Dev Mode)")
    AppConfig["Config Dev dell'App (URL + metadati)"]
    AppServer["Il tuo server dell'App (Next.js + Apps SDK)"]

    User -->|richiesta in chat| ChatGPTCore[GPT]
    ChatGPTCore -->|serve l'App| AppConfig
    AppConfig --> AppServer
    AppServer -->|UI/strumenti| ChatGPTCore
    ChatGPTCore --> User

Tu, come sviluppatore, nelle impostazioni del Developer Mode dici a ChatGPT: «Ecco la mia App, ecco il suo URL, ecco come si chiama e cosa sa fare». ChatGPT inizia a considerare quell’URL come la fonte della tua applicazione. Finché non invii la App allo Store, la vedrai solo tu (e, eventualmente, altri membri del tuo team, se li aggiungi come sviluppatori).

I dettagli tecnici del collegamento (tunnel HTTPS, Vercel e altre gioie) li analizzeremo più avanti. Qui è importante capire l’idea: il Dev Mode è come un «collegamento dinamico» al tuo server di sviluppo, che ChatGPT sa invocare.

Come abilitare il Developer Mode

Per avere la possibilità di "collegare" il tuo server locale all'interfaccia di ChatGPT, devi attivare l'interruttore corrispondente nelle impostazioni.

• Segui il link https://chatgpt.com/#settings/Connectors/Advanced o vai su Settings -> Connected apps -> Advanced.
• Developer Mode - ON

Non appena lo farai, apparirà il pulsante Create App.

In cosa Dev Mode differisce dal production

La differenza assomiglia molto a quella tra l’ambiente di sviluppo e il production nel web tradizionale, ma ci sono alcuni aspetti specifici.

In primo luogo, visibilità. La tua App in Dev Mode, di norma, non è accessibile agli utenti comuni di ChatGPT. La vedono solo tu e, eventualmente, i membri della tua organizzazione con i diritti appropriati. Puoi sperimentare senza temere che una persona a caso si imbatta in una UX semirotta.

In secondo luogo, stabilità ed esperimenti. In Dev Mode puoi cambiare il codice anche ogni due minuti, avviare un server locale, interromperlo, riavviare il tunnel. ChatGPT cercherà di raggiungere l’URL indicato, ma non si offenderà se a volte restituisci 500 o non rispondi affatto — è per questo che esiste il dev.

In terzo luogo, autorizzazioni e politiche. In Dev Mode è più semplice provare diverse configurazioni. Ma è importante ricordare che le politiche sui contenuti e la sicurezza di base non si disattivano nemmeno in modalità dev: ChatGPT non ti permetterà di trasformarti all’improvviso in «un’App da hacker per tutto». Tuttavia, qui non si applicano ancora i vincoli della revisione dello Store: non è necessario avere una scheda perfetta, un bel logo, ecc.

Infine, in Dev Mode di solito è più semplice diagnosticare i punti problematici. Puoi modificare rapidamente la logica, osservare quali richieste vanno da ChatGPT al tuo server e correggere il comportamento senza pensare a «migrazioni degli utenti».

Abbiamo già visto il Dev Mode come una sandbox personale per le applicazioni e abbiamo dato una rapida occhiata allo Store. Mettiamo ora tutto in una «macchina a stati» comprensibile del ciclo di vita della App.

3. Stati di ChatGPT App: dalla bozza al ritiro dalla pubblicazione

Mettiamo questo in una «macchina a stati» comprensibile per la tua App. Parleremo, in modo approssimativo, di quattro stati principali: Draft / Dev-only, Under review, Published e Paused/Removed.

Macchina a stati del ciclo di vita

Proviamo a disegnarla come diagramma:

stateDiagram-v2
    [*] --> Draft

    Draft: Dev Mode / bozza
    Review: Under review (Store)
    Published: In Store, disponibile agli utenti
    Paused: Paused / Removed

    Draft --> Review: Inviare a revisione
    Review --> Draft: Rifiutato / da rivedere
    Review --> Published: Approvato
    Published --> Paused: Mettere in pausa / rimuovere
    Paused --> Draft: Riprendere il lavoro in modalità dev
    Draft --> Published: Rollout interno senza Store (per l'organizzazione)

Nello stato Draft la tua App esiste solo come risorsa di sviluppo. Puoi collegarla nel Developer Mode, provare funzionalità diverse, ma senza mostrarla nello Store.

Quando decidi che è ora di mostrare la App alle persone, la invii «in revisione» — è lo stato Under review. In esso OpenAI (o un sistema di revisione interno alla tua organizzazione) verifica la conformità alle politiche, la stabilità, la sicurezza di base e l’adeguatezza della UX.

Se va tutto bene, la App passa a Published: appare nello Store o diventa disponibile per gli utenti della tua azienda (se è uno scenario aziendale). Da questo momento arrivano utenti reali e tutto ciò che fai con codice e configurazione va pianificato con più attenzione.

Se invece non vuoi temporaneamente che la App sia disponibile, puoi portarla nello stato Paused/Removed. In stato Paused è nascosta ai nuovi utenti, ma può continuare a funzionare per le sessioni già iniziate oppure essere disattivata del tutto — i dettagli dipendono dall’implementazione della piattaforma e dalle impostazioni.

4. Store: quando la tua App diventa un prodotto

Il Developer Mode è il tuo garage personale. Lo Store è il concessionario ufficiale. Qui entrano in gioco utenti, valutazioni, regole di listing e revisione.

Cosa cambia quando vai nello Store

La prima e più importante: la tua App diventa «un prodotto». Ottiene una scheda: nome, descrizione, icona, categorie, talvolta prompt iniziali per il dialogo. In base a questi metadati lo Store di ChatGPT cercherà e raccomanderà la tua applicazione agli utenti, e il modello stesso capirà in quali scenari l’App è rilevante.

La seconda cosa importante — revisione e politiche. Prima che la App compaia nello Store, verrà verificata rispetto ai requisiti di sicurezza, contenuti e UX. Questo significa che:

• non si possono raccogliere di nascosto dati personali in eccesso;
• non si possono promettere cose che la App non fa;
• non si può uscire dalle categorie di contenuto consentite.

Parleremo ancora in dettaglio di politiche e sandbox nelle prossime lezioni, ma già ora conviene percepire lo Store come il luogo in cui portare solo versioni relativamente «educate» della tua App.

La terza cosa — responsabilità per la stabilità. Finché giochi in Dev Mode, i crash sono un tuo problema. Nello Store ci si aspetta dalla tua App un’adeguata disponibilità, una latenza ragionevole e l’assenza di «schermate rosse della morte» nel widget. Nei moduli successivi parleremo di SLO, metriche e revisione dello Store proprio in questo contesto.

Versioni: dev contro production

Domanda tipica: «Se aggiorno il codice, cosa vedrà l’utente?». Nel mondo delle ChatGPT Apps è utile pensare a due «rami» contemporaneamente:

• ramo dev, collegato al Developer Mode e che può puntare a un server di sviluppo accanto al tuo IDE;
• ramo production, associato alla configurazione pubblicata nello Store e puntato a un URL stabile.

Dal punto di vista dell’architettura, lo si può esprimere anche con un piccolo tipo TypeScript nel tuo progetto:

type AppStage = 'dev' | 'production';

interface ChatGPTAppConfig {
  id: string;
  stage: AppStage;
  endpointUrl: string;
}

const giftGeniusDev: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'dev',
  endpointUrl: 'https://dev.giftgenius.example.com',
};

const giftGeniusProd: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'production',
  endpointUrl: 'https://app.giftgenius.example.com',
};

Nella vita reale, la configurazione non la mantiene il tuo codice, ma la piattaforma ChatGPT; tuttavia, strutture simili aiutano a tenere a mente che sono due «immagini» diverse della stessa App.

Il rilascio di una ChatGPT App assomiglia più al release di un’applicazione su Apple App Store che a un aggiornamento di un sito. I tuoi widget e gli mcp-tools vengono ogni volta messi in cache al momento del rilascio dell’app. E la revisione può richiedere 2 settimane. Quindi niente «facciamo il deploy in production e testeremo lì». Dovete inviare in revisione un’app completamente testata e stabile.

5. Contesto organizzativo: account personale vs azienda

Abbiamo già separato la App in rami dev e production e visto come questo si rifletta nello Store. Un’altra dimensione importante del ciclo di vita è «dove» vive a livello organizzativo.

Nel caso più semplice, realizzi una App come privato nel tuo ChatGPT Plus personale. Allora il Dev Mode è solo tuo e lo Store è anch’esso sotto il tuo account. Tutto relativamente semplice: l’hai fatto per te, l’hai pubblicato, hai reso felice il mondo.

Molto spesso però le ChatGPT Apps vivono in un contesto aziendale. Allora compaiono alcuni ruoli aggiuntivi. Ci sono gli admin dell’organizzazione che decidono quali App sono disponibili ai dipendenti, quali bloccare, quali consentire solo a un gruppo pilota. La tua App può essere pubblicata non per tutto il mondo, ma solo per un’azienda specifica, o addirittura per reparti specifici al suo interno.

In uno scenario del genere, il ciclo di vita può apparire così: inizialmente la App esiste solo come progetto di sviluppo all’interno del team, poi appare una «production interna» — disponibile, ad esempio, solo al reparto vendite per un pilota. Solo dopo, se tutto va bene, decidi di inviare la App nello Store globale, per renderla un prodotto esterno.

Per l’architettura questo è importante perché devi progettare la App in modo che funzioni adeguatamente sia come strumento interno sia come prodotto pubblico. Talvolta ciò implica la presenza di feature flag, modalità «solo per i nostri» e impostazioni di autenticazione separate.

6. Scenario pratico: ciclo di vita di GiftGenius

Per evitare che quanto detto rimanga astratto, guardiamo alla App ipotetica GiftGenius — un assistente per la selezione di regali che ci accompagnerà lungo il corso.

Fase 1. Idea e prototipo grezzo in Dev Mode

Decidi di creare GiftGenius: una App che chiede all’utente a chi serve il regalo, qual è il budget previsto e quali sono gli interessi del destinatario, quindi propone opzioni usando il tuo catalogo prodotti.

Al primo passo:

1. Avvii un semplice progetto Next.js con un widget minimo.
2. Attivi il Developer Mode in ChatGPT e aggiungi l’URL del tuo server di sviluppo.
3. Conduci alcuni dialoghi di test: chiedi a GPT «Aiutami a scegliere un regalo per un amico gamer fino a 50 $» e osservi come richiama la tua App, come renderizza il widget e come appare la UX.

In questa fase non pensi allo Store, alla revisione o alle icone belle. Il tuo compito è dimostrare a te stesso e al team che l’idea funziona e che la piattaforma ChatGPT consente di realizzare lo scenario desiderato.

Fase 2. Rafforzare il prototipo e «alpha» interna

Quando ti sei convinto che lo scenario di base funziona, inizia la fase di «rafforzamento». Tu:

• porti la logica a una struttura più o meno chiara;
• cominci a pensare a quali autorizzazioni e dati servono davvero alla App;
• verifichi come l’App si comporta in caso di errori (ad esempio, quando il catalogo prodotti non risponde).

Sempre in Dev Mode, ma non più da solo: aggiungi colleghi come sviluppatori o tester, in modo che anche loro possano collegare la App al proprio ChatGPT. Il ciclo di vita in questa fase ruota ancora intorno allo stato Draft: aggiorni rapidamente il codice, provi diversi pattern UX, discuti i feedback all’interno del team.

Fase 3. Preparazione allo Store e revisione

A questo punto decidi: «Sì, GiftGenius è già abbastanza presentabile per mostrarlo agli utenti esterni». Ora il focus si sposta dal codice al confezionamento del prodotto:

• scrivi una descrizione onesta e chiara della App;
• configuri le autorizzazioni: spieghi a quali dati la App accede e perché;
• ti assicuri che la UX non sia fuorviante e che la App non prometta l’impossibile.

È il momento del passaggio da Draft a Under review. Invi la App alla revisione, e per un po’ vivrà in questo stato intermedio. È possibile che arrivino osservazioni: chiarire l’informativa sulla privacy, correggere formulazioni, ridurre le autorizzazioni. Torni in Draft, migliori e invii di nuovo.

Fase 4. Pubblicazione e «vita reale»

Dopo l’approvazione, la tua GiftGenius si trova nello stato Published. Ora gli utenti possono trovarla nello Store, ChatGPT può suggerirla per richieste pertinenti e tu inizi a raccogliere feedback reale, osservare l’utilizzo e pensare alla scalabilità.

Ora ogni modifica al codice non è più «oh, adesso aggiusto velocemente la funzione». È un mini‑rilascio. Devi pensare alla compatibilità all’indietro, pianificare migrazioni, ove possibile cambiare prima la versione dev, verificarla e solo dopo aggiornare la configurazione di production.

Se necessario, puoi mettere temporaneamente la App in Paused, ad esempio se hai trovato una vulnerabilità critica o il tuo backend non regge il carico. Ma l’ideale è sviluppare gradualmente il ramo Published senza dimenticare l’ambiente dev per gli esperimenti.

7. Come uno sviluppatore dovrebbe pensare agli ambienti: dev, staging, production + Dev Mode

Con l’esempio di GiftGenius abbiamo percorso la strada dall’idea in Dev Mode alla App pubblicata. Ora inquadriamo il tutto nello schema familiare degli ambienti — dev/staging/production — e vediamo come si relaziona con il Dev Mode e lo Store.

Più spesso è utile tenere a mente una matrice come questa:

Il Developer Mode, in sostanza, si aggancia alla tua infrastruttura di dev o staging: pubblichi un URL temporaneo che ChatGPT usa per i test. La configurazione dello Store invece punta a un URL di production già maturo.

In futuro, quando parleremo del deploy su Vercel e dei tunnel, questa matrice si trasformerà in una serie di passi concreti. Ma già ora è utile tenere una semplice idea: sii sempre consapevole di dove si trova la richiesta attuale di ChatGPT — nella tua sandbox di dev o nell’ambiente di produzione visitato dagli utenti.

8. Un piccolo «pezzo di codice» sul ciclo di vita

Per collegare il tutto a un approccio a te familiare in TypeScript, scriviamo un semplice tipo che rifletta il ciclo di vita della App non a livello di piattaforma, ma del tuo tooling. Lo si può mettere nel repository per non dimenticare i vari stati.

type AppLifecycleState = 'draft' | 'under_review' | 'published' | 'paused';

interface LifecycleSnapshot {
  id: string;
  name: string;
  state: AppLifecycleState;
  lastDeployedAt: Date | null;
  devUrl?: string;
  prodUrl?: string;
}

const giftGeniusLifecycle: LifecycleSnapshot = {
  id: 'giftgenius',
  name: 'GiftGenius – selezione di regali',
  state: 'draft',
  lastDeployedAt: null,
  devUrl: 'https://dev.giftgenius.example.com',
};

Un oggetto del genere non lo invierai mai a ChatGPT, ma aiuta il team a restare allineato. Puoi persino creare una piccola CLI che mostri lo stato di tutte le tue App, per non confondere ciò che è una bozza con ciò che è già nello Store.

Nei moduli successivi torneremo spesso a questo modello di ciclo di vita: quando imposteremo tunnel e deploy su Vercel, quando progetteremo il server MCP e gli scenari agent, quando penseremo ai flussi di commerce e alla preparazione per la revisione nello Store. Pensa al Dev Mode e allo Store come ai due poli dello stesso sistema: una sandbox per esperimenti e una vetrina per un prodotto maturo.

9. Errori tipici nel lavorare con Dev Mode e Store

Errore n. 1: «Subito nello Store, poi vediamo».
A volte si ha voglia di «conquistare il mercato» il più in fretta possibile e pubblicare la App nello Store già a livello di prototipo semi‑funzionante. Questo porta quasi certamente a recensioni negative degli utenti, a statistiche d’uso scarse e a ulteriori domande in revisione. È molto più sano vivere prima alcune iterazioni nel Developer Mode, raccogliere feedback da colleghi e amici, stabilizzare la UX di base e solo poi andare nello Store.

Errore n. 2: Mescolare ambienti dev e production.
Scenario tipico: configuri il Dev Mode sullo stesso URL del production e poi ti sorprendi del perché «alcune modifiche di debug» siano state viste all’improvviso dagli utenti reali. Tenere separati gli URL di dev e prod è necessario con la stessa cura con cui lo fai per i normali servizi web. Se nella configurazione della ChatGPT App c’è un URL di production, non usarlo per «esperimenti veloci serali».

Errore n. 3: Mancanza di una chiara idea degli stati.
Quando gli sviluppatori non sono consapevoli dello stato in cui vive la App (Draft, Under review, Published, Paused), sorgono situazioni strane: qualcuno nel team pensa che la App sia già nello Store, un altro la considera ancora un prototipo locale. Conviene descrivere almeno nel README del progetto dove si trova la App e cosa serve per passare allo step successivo.

Errore n. 4: Ignorare politiche e revisione fino all’ultimo momento.
Alcuni team sviluppano una App «come se fosse solo un sito» e si ricordano di politiche, autorizzazioni e requisiti dello Store il giorno prima dell’invio in revisione. Il risultato è che bisogna rifare seriamente la raccolta e l’archiviazione dei dati, riscrivere descrizioni e ridurre i permessi. Meglio tenere i vincoli a mente fin dall’inizio e, nel Dev Mode, sperimentare subito con autorizzazioni minime e trasparenti.

Errore n. 5: Mancanza di una strategia separata per uso interno ed esterno.
Se la App nasce come strumento aziendale interno e poi si vuole farne un prodotto pubblico, è facile confondere il pubblico di riferimento. All’interno dell’azienda ci si può permettere una UX meno «lucidata» e scenari più complessi; nello Store esterno gli utenti si aspettano un altro livello di comodità. Non capire in quale modalità ti trovi adesso porta a una App pubblica che sembra un tool amministrativo interno, mentre il pilota interno si blocca perché si pensa troppo presto allo Store globale.

Errore n. 6: Mancanza di collegamento tra Dev Mode e osservabilità.
Il Developer Mode è perfetto per il debug, ma bisogna sfruttare questo vantaggio. Se non guardi i log e non registri quali richieste ChatGPT invia alla tua App in ambiente di sviluppo, più tardi, in production, potresti avere brutte sorprese. Meglio usare il Dev Mode come piattaforma per studiare il comportamento reale del modello e degli utenti, non solo per verificare che «il widget compila».