Developer Mode vs Store

1. Introdução

Em aulas anteriores, já falamos sobre o que é o ChatGPT App, de quais camadas ele é composto e em que difere dos plugins antigos e de simples bots no OpenAI API. Agora vamos ao segundo tema importante — o ciclo de vida desse tipo de aplicativo.

Se você desenvolve web services há pelo menos alguns anos, a palavra “lifecycle” não assusta. Todo produto tem um caminho básico: “codamos localmente → subimos no staging → subimos no production → às vezes quebramos tudo → consertamos”. No ecossistema do ChatGPT com App é a mesma coisa, mas com nuances: existe o Dev Mode dentro do próprio ChatGPT e uma entidade separada — o Store.

É importante separar claramente dois planos:

1. Onde seu código “mora” fisicamente: servidor Next.js local, Vercel, algum cluster Kubernetes e por aí vai. Esse é o seu mundo, onde você é quem manda.
2. Como o ChatGPT enxerga seu App: como um conjunto de metadados, URL e permissões que podem ser conectados no Developer Mode ou embalados como um produto pronto no Store. Esse já é o mundo da OpenAI, com suas regras, revisão e usuários.

Esta aula trata justamente do segundo plano. Vamos nos apoiar no seu modelo usual de ambientes (dev / staging / prod), mas olhando por meio do ChatGPT. Nosso objetivo é que você, a qualquer momento, consiga responder a algumas perguntas: Qual código exatamente meu App está executando agora? Quem o vê? Como experimentar com segurança? E o que significa “atualizar o App” no Store?

2. Developer Mode: sua sandbox pessoal dentro do ChatGPT

Vamos começar pelo que é mais agradável para o desenvolvedor: a sandbox onde dá para quebrar tudo sem quase machucar ninguém.

Developer Mode é um modo especial no ChatGPT em que você pode conectar seus ChatGPT Apps diretamente por URL, sem passar por revisão, sem publicar o App no Store e sem mostrá-lo ao mundo. Em espírito, é parecido com localhost:3000 no navegador, só que no mundo do ChatGPT.

Como isso se parece conceitualmente

O jeito mais simples é imaginar o seguinte esquema:

flowchart TD
    User("ChatGPT UI (Dev Mode)")
    AppConfig["Config do App em Dev (URL + metadados)"]
    AppServer["Seu servidor do App (Next.js + Apps SDK)"]

    User -->|requisição no chat| ChatGPTCore[GPT]
    ChatGPTCore -->|precisa de App| AppConfig
    AppConfig --> AppServer
    AppServer -->|UI/ferramentas| ChatGPTCore
    ChatGPTCore --> User

Você, como desenvolvedor, nas configurações do Developer Mode diz ao ChatGPT: “Aqui está meu App, aqui está o URL dele, aqui está o nome e o que ele faz”. O ChatGPT passa a considerar esse URL como a fonte do seu aplicativo. Enquanto você não enviar o App ao Store, só você o verá (e, possivelmente, outros membros da sua equipe, se os adicionar como desenvolvedores).

Os detalhes técnicos de conexão (túnel HTTPS, Vercel e outras alegrias) veremos adiante. Aqui o importante é entender a ideia: o Dev Mode é um “atalho dinâmico” para o seu servidor de desenvolvimento, que o ChatGPT sabe chamar.

Como ativar o Developer Mode

Para que você tenha a possibilidade de "conectar" seu servidor local à interface do ChatGPT, é necessário ativar o interruptor correspondente nas configurações.

• Siga o link https://chatgpt.com/#settings/Connectors/Advanced ou vá para Settings -> Connected apps -> Advanced.
• Developer Mode - ON

Assim que você fizer isso, o botão Create App aparecerá.

Como o Dev Mode difere do production

A diferença lembra o contraste entre o ambiente de desenvolvimento e o de produção na web tradicional, mas com alguns pontos específicos.

Em primeiro lugar, a visibilidade. Seu App no Dev Mode, em regra, não está disponível para usuários comuns do ChatGPT. Quem o vê é você e, talvez, membros da sua organização com permissões adequadas. Dá para experimentar sem medo de alguém esbarrar num UX meio quebrado.

Em segundo lugar, a estabilidade e os experimentos. No Dev Mode você pode mudar o código a cada dois minutos, subir servidor local, derrubá-lo, reiniciar o túnel. O ChatGPT tentará acessar o URL indicado, mas não “ficará chateado” se você às vezes responder 500 ou nem responder — é para isso que existe o ambiente de dev.

Em terceiro lugar, permissões e políticas. No Dev Mode é mais simples experimentar diferentes configurações. Mas é importante lembrar que políticas de conteúdo e segurança básica não são desativadas nem no modo de dev: o ChatGPT não permitirá que você vire de repente um “App hacker para todos”. Contudo, o escopo de revisão do Store ainda não entra em cena: você não precisa ter listagem perfeita, logotipo bonito etc.

Por fim, no Dev Mode geralmente é mais fácil diagnosticar pontos problemáticos. Você pode alterar a lógica rapidamente, ver que requisições o ChatGPT faz ao seu servidor e ajustar o comportamento sem pensar em “migração de usuários”.

Já vimos o Dev Mode como uma sandbox pessoal para aplicativos e demos uma olhada no Store. Agora vamos organizar tudo isso numa “máquina de estados” clara do ciclo de vida de um App.

3. Estados do ChatGPT App: do rascunho à retirada da publicação

Vamos organizar isso em uma “máquina de estados” para o seu App. Vamos falar, de forma geral, sobre quatro estados principais: Draft / Dev-only, Under review, Published e Paused/Removed.

Máquina de estados do ciclo de vida

Vamos desenhar isso como um diagrama:

stateDiagram-v2
    [*] --> Draft

    Draft: Dev Mode / rascunho
    Review: Under review (Store)
    Published: No Store, disponível para usuários
    Paused: Paused / Removed

    Draft --> Review: Enviar para revisão
    Review --> Draft: Rejeitado / devolver para ajustes
    Review --> Published: Aprovado
    Published --> Paused: Colocar em pausa / remover
    Paused --> Draft: Retomar trabalho no modo dev
    Draft --> Published: Rollout interno sem Store (para a organização)

No estado Draft, seu App existe apenas como um recurso de dev. Você pode conectá-lo no Developer Mode, experimentar features diferentes, mas sem expô-lo no Store.

Quando você decide que o App já está pronto para ser mostrado às pessoas, você o envia “para revisão” — esse é o estado Under review. Nele, a OpenAI (ou o sistema interno de revisão da sua organização) verifica a conformidade com as políticas, a estabilidade, a segurança básica e a adequação do UX.

Se tudo estiver bem, o App vai para Published: ele aparece no Store ou fica disponível para os usuários da sua empresa (em cenário corporativo). A partir desse momento, usuários reais começam a chegar, e tudo o que você faz com código e configuração precisa ser planejado com mais cuidado.

Se você não quiser temporariamente que o App fique disponível, pode colocá-lo no estado Paused/Removed. Em Paused ele fica oculto de novos usuários, mas pode continuar funcionando para sessões já iniciadas, ou pode ser totalmente desativado — os detalhes dependem da implementação da plataforma e das configurações.

4. Store: quando seu App se torna um produto

O Developer Mode é a sua garagem particular. O Store é o concessionário oficial. Aqui entram em jogo usuários, avaliação, regras de listagem e revisão.

O que muda quando você vai para o Store

Primeiro e mais importante: seu App vira “produto”. Ele ganha uma listagem: nome, descrição, ícone, categorias e, às vezes, prompts iniciais para a conversa. Com base nessas metainformações, o ChatGPT Store buscará e recomendará seu aplicativo aos usuários, e o próprio modelo entenderá em quais cenários o App é relevante.

A segunda coisa importante — revisão e políticas. Antes de o App aparecer no Store, ele será verificado quanto à conformidade com requisitos de segurança, conteúdo e UX. Isso significa que:

• não é permitido coletar silenciosamente dados pessoais desnecessários;
• não é permitido prometer o que o App não faz;
• não é permitido ultrapassar os limites das categorias de conteúdo aceitáveis.

Falaremos em detalhes sobre políticas e sandbox nas próximas aulas, mas já agora é útil enxergar o Store como o lugar para onde você leva versões relativamente “disciplinadas” do seu App.

A terceira coisa — responsabilidade pela estabilidade. Enquanto você brinca no Dev Mode, suas quedas são problema seu. No Store, espera-se do seu App disponibilidade adequada, latência razoável e ausência de “telões vermelhos da morte” no widget. Em módulos posteriores, falaremos sobre SLO, métricas e revisão do Store justamente nesse contexto.

Versões: dev versus production

Pergunta típica: “Se eu atualizar o código, o que o usuário verá?”. No mundo dos ChatGPT Apps, é útil pensar em duas “ramificações” ao mesmo tempo:

• ramo de dev, conectado ao Developer Mode e que pode apontar para um servidor de desenvolvimento, lado a lado com sua IDE;
• ramo de produção, associado à configuração publicada no Store e apontando para um URL estável.

Do ponto de vista da arquitetura, isso pode ser expresso até com um pequeno tipo TypeScript no seu projeto:

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',
};

Na vida real, a configuração é armazenada não pelo seu código, mas pela plataforma ChatGPT, mas estruturas como essa ajudam a manter em mente que são dois “retratos” diferentes do mesmo App.

O lançamento de um ChatGPT App se parece mais com a publicação de um aplicativo na Apple App Store do que com a atualização de um site. Seus widgets e mcp-tools são cacheados a cada release do aplicativo. E a revisão pode levar 2 semanas. Portanto, nada de “subimos em produção e testamos lá”. Você deve enviar para revisão um aplicativo já totalmente testado e estável.

5. Contexto organizacional: conta pessoal vs empresa

Já separamos o App em ramos de dev e de produção e vimos como isso se reflete no Store. Outra dimensão importante do ciclo de vida é “onde” ele vive organizacionalmente.

No caso mais simples, você cria um App como pessoa física na sua conta pessoal do ChatGPT Plus. Nesse caso, o Dev Mode é só seu, e o Store também está sob sua conta. Tudo relativamente simples: fez para si, publicou, alegrou o mundo.

Mas, com muita frequência, os ChatGPT Apps vivem em contexto corporativo. Aí surgem alguns papéis adicionais. Existem administradores da organização que decidem quais Apps estão disponíveis para os funcionários, quais bloquear, quais liberar apenas para um grupo piloto. Seu App pode ser publicado não para o mundo inteiro, mas apenas para uma empresa específica ou mesmo para departamentos específicos dentro dela.

Nesse cenário, o ciclo de vida pode ser assim: primeiro o App existe apenas como projeto de dev dentro da equipe, depois surge um “production interno” — disponível, por exemplo, apenas para o departamento de vendas em um piloto. Só então, se tudo correr bem, você decide enviar o App ao Store global para torná-lo um produto externo.

Isso é importante para a arquitetura porque você precisa projetar o App para funcionar adequadamente tanto como ferramenta interna quanto como produto público. Às vezes isso significa ter feature flags, modos “somente para a casa” e configurações de autenticação separadas.

6. Cenário prático: ciclo de vida do GiftGenius

Para que tudo isso não fique abstrato, vamos olhar para um App hipotético, o GiftGenius — um assistente de escolha de presentes que nos acompanhará ao longo do curso.

Etapa 1. Ideia e protótipo inicial no Dev Mode

Você decide criar o GiftGenius: um App que pergunta ao usuário para quem é o presente, qual o orçamento e quais os interesses do presenteado, e então sugere opções usando seu catálogo de produtos.

No primeiro passo, você:

1. Sobe um projeto simples em Next.js com um widget mínimo.
2. Ativa o Developer Mode no ChatGPT e adiciona o URL do seu servidor de dev.
3. Conduz alguns diálogos de teste: pede ao GPT “Ajude a escolher um presente para um amigo gamer de até US$ 50” e observa como ele chama seu App, renderiza o widget e como fica o UX.

Nesta etapa você não pensa no Store, revisão, ícones bonitos. Sua tarefa é provar para si e para a equipe que a ideia funciona e que a plataforma ChatGPT permite implementar o cenário desejado.

Etapa 2. Fortalecendo o protótipo e “alfa” interna

Quando você se convence de que o cenário básico funciona, começa a etapa de “fortalecimento”. Você:

• organiza a lógica numa estrutura razoavelmente clara;
• passa a pensar em quais permissões e dados o App realmente precisa;
• verifica como o App se comporta em caso de erros (por exemplo, quando o catálogo de produtos não responde).

Ainda no Dev Mode, mas já não sozinho: você adiciona colegas como desenvolvedores ou testadores para que eles também possam conectar o App ao próprio ChatGPT. O ciclo de vida nessa etapa ainda gira em torno do estado Draft: você atualiza o código rapidamente, experimenta padrões de UX diferentes, discute feedback dentro da equipe.

Etapa 3. Preparação para o Store e revisão

Neste passo você decide: “Sim, o GiftGenius já está apresentável para mostrar a usuários externos”. Agora o foco muda do código para a embalagem do produto:

• escreve uma descrição honesta e clara do App;
• configura permissões: explica a quais dados o App acessa e por quê;
• garante que o UX não induz em erro e que o App não promete o impossível.

Esse é o momento da transição de Draft para Under review. Você envia o App para revisão e, por um tempo, ele fica nesse estado intermediário. É possível que surjam observações: precisar detalhar a política de privacidade, ajustar formulários, reduzir permissões. Você volta ao Draft, faz melhorias e reenvia.

Etapa 4. Publicação e “vida real”

Após a aprovação, seu GiftGenius fica no estado Published. Agora os usuários podem encontrá-lo no Store, o ChatGPT pode sugeri-lo em consultas relevantes, e você começa a coletar feedback real, observar o uso e pensar em escalabilidade.

Agora, cada mudança de código não é mais “vou só ajustar rapidinho a função”. É um mini‑release. Você precisa pensar em compatibilidade retroativa, planejar migrações, preferencialmente alterar primeiro a versão de dev, validá-la e só então atualizar a configuração de produção.

Se necessário, você pode colocar temporariamente o App em Paused, por exemplo, se encontrar uma vulnerabilidade crítica ou se seu backend não estiver suportando a carga. Mas o ideal é evoluir gradualmente o ramo Published, sem esquecer o ambiente de dev para experimentos.

7. Como o desenvolvedor deve pensar em ambientes: dev, staging, production + Dev Mode

Com o GiftGenius, percorremos o caminho da ideia no Dev Mode até o App publicado. Agora vamos organizar isso no esquema familiar de ambientes — dev/staging/production — e ver como ele se relaciona com o Dev Mode e o Store.

Na cabeça, costuma ser útil ter esta matriz:

O Developer Mode, na essência, conecta-se à sua infraestrutura de dev ou staging: você publica ali um URL temporário que o ChatGPT usa para testes. A configuração do Store, por sua vez, aponta para o URL de produção.

No futuro, quando falarmos sobre deploy na Vercel e túneis, essa matriz virará um conjunto de passos bem concretos. Mas já agora é útil manter uma ideia simples: sempre saiba onde a requisição atual do ChatGPT está chegando — à sua sandbox de dev ou ao ambiente de produção, por onde passam os usuários.

8. Um pequeno “trecho de código” sobre o ciclo de vida

Para conectar tudo isso a um estilo TypeScript familiar, vamos escrever um tipo simples que reflita o ciclo de vida do App não no nível da plataforma, mas do seu próprio tooling. Você pode colocá-lo no repositório para não esquecer os diferentes estados.

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 – seleção de presentes',
  state: 'draft',
  lastDeployedAt: null,
  devUrl: 'https://dev.giftgenius.example.com',
};

Você nunca enviará esse objeto ao ChatGPT, mas ele ajuda a equipe a ficar no mesmo contexto. Dá até para fazer um CLI simples que mostre o estado de todos os seus Apps, para não confundir onde está o rascunho e onde já há algo no Store.

Nos módulos seguintes, voltaremos constantemente a esse modelo de ciclo de vida: quando configurarmos túneis e deploy na Vercel, projetarmos o servidor MCP e cenários de agentes, pensarmos no fluxo de commerce e na preparação para revisão no Store. Pense no Dev Mode e no Store como dois polos de um mesmo sistema: a sandbox para experimentos e a vitrine para um produto já amadurecido.

9. Erros comuns ao trabalhar com Dev Mode e Store

Erro nº 1: “Direto para o Store, e a gente vê depois”.
Às vezes dá vontade de “conquistar o mercado” o quanto antes e publicar o App no Store ainda na fase de protótipo meia-boca. Isso quase sempre leva a avaliações negativas dos usuários, estatísticas de uso ruins e perguntas extras na revisão. É muito mais saudável primeiro passar por algumas iterações no Developer Mode, coletar feedback de colegas e amigos, estabilizar o UX básico e só então ir para o Store.

Erro nº 2: Misturar ambientes de dev e de produção.
Cenário típico: você configura o Dev Mode no mesmo URL do production e depois se surpreende porque “algumas mudanças de debug” foram vistas por usuários reais. Separar os URLs de dev e de prod é tão importante quanto você já faz para web services comuns. Se na configuração do ChatGPT App está um production-URL, não o use para “experimentos rápidos à noite”.

Erro nº 3: Falta de uma visão clara dos estados.
Quando os desenvolvedores não têm clareza sobre em que estado o App está (Draft, Under review, Published, Paused), surgem situações estranhas: alguém da equipe acha que o App já está no Store, outro ainda o considera um protótipo local. Vale pelo menos descrever no README do projeto onde o App está agora e o que é preciso fazer para passar à próxima etapa.

Erro nº 4: Ignorar políticas e revisão até o último momento.
Algumas equipes desenvolvem o App “como se fosse apenas um site” e só lembram de políticas, permissões e exigências do Store um dia antes do envio para revisão. O resultado é que será necessário refatorar seriamente coleta e armazenamento de dados, reescrever descrições e reduzir permissões. Melhor manter isso em mente desde o início e, no Dev Mode, já experimentar com permissões honestas e mínimas.

Erro nº 5: Falta de uma estratégia separada para uso interno e externo.
Se o App nasce como ferramenta corporativa interna e depois você quer transformá-lo em produto público, é fácil confundir o público-alvo. Internamente, dá para tolerar um UX menos “polido” e cenários mais complexos; no Store externo, os usuários esperam outro nível de conveniência. Não saber em que modo você está agora leva a um App público com cara de ferramenta interna de admin, e a um piloto interno travado porque você pensou cedo demais no Store global.

Erro nº 6: Não vincular o Dev Mode à observabilidade.
O Developer Mode é excelente para depuração — e é preciso aproveitar essa vantagem. Se você não olha logs e não registra que requisições o ChatGPT envia ao seu App no ambiente de dev, depois, em produção, podem surgir surpresas desagradáveis. É melhor usar o Dev Mode como um espaço para estudar o comportamento real do modelo e dos usuários, não apenas para checar “se o widget compila”.