Developer Mode vs Store

1. Introducción

En lecciones anteriores ya hablamos de qué es un ChatGPT App, de qué capas se compone y en qué se diferencia de los antiguos plugins y de simples bots sobre la OpenAI API. Ahora pasamos al segundo tema importante: el ciclo de vida de este tipo de aplicación.

Si llevas al menos unos años desarrollando servicios web, la palabra «lifecycle» no te asusta. Todo producto tiene un recorrido básico: «lo escribimos localmente → lo desplegamos en staging → lo desplegamos en production → a veces lo rompimos todo → lo arreglamos». En el ecosistema de ChatGPT con App es lo mismo, pero con matices: aparece el Dev Mode dentro del propio ChatGPT y una entidad aparte: el Store.

Es importante separar claramente dos planos:

1. Dónde vive tu código físicamente: servidor local de Next.js, Vercel, algún clúster de Kubernetes, etc. Ese es tu mundo: allí mandas tú.
2. Cómo ChatGPT ve tu App: como un conjunto de metadatos, URL y permisos que puedes conectar en Developer Mode o presentar como producto listo en el Store. Ese ya es el mundo de OpenAI, con sus reglas, revisión y usuarios.

Esta lección trata precisamente del segundo plano. Nos apoyaremos en tu modelo habitual de entornos (dev / staging / prod), pero lo miraremos con los ojos de ChatGPT. Nuestro objetivo es que en cualquier momento puedas responderte varias preguntas: ¿Qué código exacto ejecuta ahora mi App? ¿Quién lo ve? ¿Cómo experimentar con seguridad? ¿Y qué significa realmente «actualizar el App» en el Store?

2. Developer Mode: tu sandbox personal dentro de ChatGPT

Empecemos por lo más agradable para una persona desarrolladora: la sandbox donde puedes romperlo todo sin hacer daño (casi) a nadie.

Developer Mode es un modo especial en ChatGPT en el que puedes conectar tus ChatGPT Apps directamente por URL, sin pasar revisión, sin publicar el App en el Store y sin mostrar el App al mundo entero. En espíritu se parece a localhost:3000 en el navegador, pero en el mundo de ChatGPT.

Cómo se ve conceptualmente

La forma más sencilla de imaginarlo es con este esquema:

flowchart TD
    User("ChatGPT UI (Dev Mode)")
    AppConfig["Config de App en Dev (URL + metadatos)"]
    AppServer["Tu servidor de App (Next.js + Apps SDK)"]

    User -->|solicitud en el chat| ChatGPTCore[GPT]
    ChatGPTCore -->|hace falta el App| AppConfig
    AppConfig --> AppServer
    AppServer -->|UI/herramientas| ChatGPTCore
    ChatGPTCore --> User

Tú, como desarrollador, en la configuración de Developer Mode le dices a ChatGPT: «Este es mi App, esta es su URL, así se llama y esto hace». ChatGPT comienza a considerar esa URL como la fuente de tu aplicación. Mientras no envíes tu App al Store, solo tú lo verás (y, posiblemente, otras personas de tu equipo si las añades como desarrolladoras).

Los detalles técnicos de la conexión (túnel HTTPS, Vercel y otras alegrías) los veremos más adelante. Aquí lo importante es entender la idea: Dev Mode es una especie de «acceso directo dinámico» a tu servidor de dev que ChatGPT sabe invocar.

Cómo habilitar el Developer Mode

Para que tengas la posibilidad de "conectar" tu servidor local a la interfaz de ChatGPT, necesitas activar el interruptor correspondiente en la configuración.

• Sigue el enlace https://chatgpt.com/#settings/Connectors/Advanced o ve a Settings -> Connected apps -> Advanced.
• Developer Mode - ON

Tan pronto como hagas esto, aparecerá el botón Create App.

En qué se diferencia Dev Mode de production

La diferencia se parece mucho a la que hay entre un entorno de dev y uno de production en la web normal, pero con algunos aspectos específicos.

En primer lugar, la visibilidad. Tu App en Dev Mode, por regla general, no está disponible para usuarios corrientes de ChatGPT. Solo lo ves tú y, quizá, las personas de tu organización con los permisos correspondientes. Puedes experimentar sin miedo a que alguien se tope con una UX medio rota.

En segundo lugar, la estabilidad y los experimentos. En Dev Mode puedes cambiar el código cada dos minutos, levantar un servidor local, tumbarlo, reiniciar el túnel. ChatGPT intentará ir a la URL indicada, pero no se enfadará si a veces devuelves 500 o directamente no respondes: para eso es dev.

En tercer lugar, permisos y política. En Dev Mode te resulta más fácil probar distintas configuraciones. Pero recuerda que las políticas de contenido y la seguridad básica no se desactivan ni siquiera en dev: ChatGPT no te permitirá convertirte de repente en un «App de hacking para todo». Sin embargo, los marcos de revisión del Store aquí todavía no se activan: no necesitas una ficha perfecta, un logotipo bonito, etc.

Y, por último, en Dev Mode suele ser más fácil diagnosticar los puntos problemáticos. Puedes cambiar la lógica rápidamente, ver qué solicitudes hace ChatGPT a tu servidor y corregir el comportamiento sin pensar en «migraciones de usuarios».

Ya hemos visto el Dev Mode como sandbox personal para aplicaciones y hemos mirado de reojo el Store. Ahora vamos a plasmar todo esto en una «máquina de estados» comprensible del ciclo de vida del App.

3. Estados de ChatGPT App: del borrador a la retirada

Convirtamos esto en una «máquina de estados» clara para tu App. Hablaremos, de forma aproximada, de cuatro estados principales: Draft / Dev-only, Under review, Published y Paused/Removed.

Máquina de estados del ciclo de vida

Intentemos dibujarlo como un diagrama:

stateDiagram-v2
    [*] --> Draft

    Draft: Dev Mode / borrador
    Review: Under review (Store)
    Published: En Store, disponible para usuarios
    Paused: Paused / Removed

    Draft --> Review: Enviar a revisión
    Review --> Draft: Rechazado / devolver para corrección
    Review --> Published: Aprobado
    Published --> Paused: Poner en pausa / retirar
    Paused --> Draft: Reanudar trabajo en modo dev
    Draft --> Published: Despliegue interno sin Store (para la organización)

En el estado Draft tu App existe solo como recurso de dev. Puedes conectarlo en Developer Mode, probar distintas funciones, pero sin exponerlo en el Store.

Cuando decides que es hora de mostrar el App a la gente, lo envías «a revisión», es decir, al estado Under review. Ahí OpenAI (o el sistema interno de revisión de tu organización) comprueba el cumplimiento de las políticas, la estabilidad, la seguridad básica y la adecuación del UX.

Si todo va bien, el App pasa a Published: aparece en el Store o queda disponible para los usuarios de tu empresa (si es un escenario corporativo). A partir de ese momento, empiezan a llegar usuarios reales y todo lo que hagas con el código y la configuración debe planificarse con más cuidado.

Si por el contrario no quieres que el App esté disponible temporalmente, puedes pasarlo al estado Paused/Removed. En Paused queda oculto para usuarios nuevos, pero puede seguir funcionando para sesiones ya iniciadas o incluso desactivarse por completo: los detalles dependen de la implementación de la plataforma y de la configuración.

4. Store: cuando tu App se convierte en producto

Developer Mode es tu taller particular. El Store es el concesionario oficial. Aquí entran en juego los usuarios, las valoraciones, las reglas de la ficha y la revisión.

Qué cambia cuando vas al Store

Lo primero y más importante: tu App se convierte en «producto». Aparece una ficha: nombre, descripción, icono, categorías, a veces indicaciones iniciales para la conversación. Con estos metadatos el ChatGPT Store buscará y recomendará tu aplicación a los usuarios, y el propio modelo entenderá en qué escenarios es relevante el App.

La segunda cuestión clave es la revisión y la política. Antes de que el App aparezca en el Store, se comprobará su cumplimiento con los requisitos de seguridad, contenido y UX. Esto implica que:

• no puedes recopilar a escondidas datos personales innecesarios;
• no puedes prometer lo que el App no hace;
• no puedes salirte de las categorías de contenido permitidas.

Hablaremos con detalle sobre la política y la sandbox en próximas lecciones, pero ya ahora conviene ver el Store como el lugar al que solo llevas versiones relativamente «educadas» de tu App.

La tercera cuestión es la responsabilidad por la estabilidad. Mientras juegas en Dev Mode, tus caídas son tu problema. En el Store se espera de tu App una disponibilidad razonable, latencia contenida y ausencia de «pantallas rojas de la muerte» en el widget. Más adelante hablaremos de SLO, métricas y revisión del Store precisamente en este contexto.

Versiones: dev frente a production

La pregunta típica: «Si actualizo el código, ¿qué verá el usuario?». En el mundo de los ChatGPT Apps conviene pensar en dos «ramas» a la vez:

• rama de dev, conectada al Developer Mode y que puede apuntar a un servidor de dev al lado de tu IDE;
• rama de production, asociada a la configuración publicada en el Store y que apunta a una URL estable.

Arquitectónicamente, esto puede expresarse incluso con un pequeño tipo de TypeScript en tu proyecto:

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

En la vida real, la plataforma ChatGPT guarda la configuración, no tu código, pero este tipo de estructuras ayudan a mantener en mente que son dos «imágenes» distintas del mismo App.

El lanzamiento de un ChatGPT App se parece más a un lanzamiento de aplicación en el Apple App Store que a una actualización de un sitio web. Tus widgets y mcp-tools se almacenan en caché cada vez que publicas una versión de la aplicación. Y la revisión puede tardar hasta 2 semanas. Así que nada de «desplegamos en production y allí seguimos probando». Debes enviar a revisión una aplicación completamente probada y estable.

5. Contexto organizativo: cuenta personal vs empresa

Ya hemos dividido el App en ramificaciones de dev y de production y hemos visto cómo se refleja en el Store. Otra dimensión importante del ciclo de vida es «dónde» vive organizativamente.

En el caso más simple, haces un App como particular en tu ChatGPT Plus personal. Entonces el Dev Mode es solo tuyo y el Store también bajo tu cuenta. Todo es relativamente simple: lo haces para ti, lo publicas y haces feliz al mundo.

Pero muy a menudo los ChatGPT Apps viven en un contexto corporativo. Entonces aparecen varios roles adicionales. Hay administradores de la organización que deciden qué Apps están disponibles para el personal, cuáles hay que bloquear, cuáles solo se pueden usar en un grupo piloto. Tu App puede publicarse no para todo el mundo, sino solo para una empresa concreta, o incluso para departamentos específicos dentro de ella.

En ese escenario, el ciclo de vida puede verse así: primero el App existe solo como proyecto de dev dentro del equipo, luego aparece un «production interno»: disponible, por ejemplo, solo para el departamento de ventas en un piloto. Solo después, si todo va bien, decides enviar el App al Store global para convertirlo en un producto externo.

Para la arquitectura, esto es importante porque debes diseñar el App para que funcione adecuadamente tanto como herramienta interna como producto público. A veces esto implica tener flags de funcionalidades, modos «solo para los nuestros» y ajustes de autenticación separados.

6. Escenario práctico: ciclo de vida de GiftGenius

Para que todo lo anterior no se quede en la abstracción, veamos el App hipotético GiftGenius —un asistente para elegir regalos— que nos acompañará a lo largo del curso.

Etapa 1. Idea y prototipo inicial en Dev Mode

Decides crear GiftGenius: un App que pregunta al usuario para quién es el regalo, con qué presupuesto cuenta y qué intereses tiene la persona que lo recibe, y después propone opciones usando tu catálogo de productos.

En el primer paso tú:

1. Levantas un proyecto simple de Next.js con un widget mínimo.
2. Activas el Developer Mode en ChatGPT y añades la URL de tu servidor de dev.
3. Realizas varios diálogos de prueba: le pides a GPT «Ayúdame a elegir un regalo para un amigo gamer de hasta 50 $» y miras cómo invoca tu App, cómo renderiza el widget y cómo se ve la UX.

En esta etapa no piensas en el Store, la revisión, los iconos bonitos. Tu tarea es demostrarte a ti y al equipo que la idea funciona y que la plataforma ChatGPT permite implementar el escenario necesario.

Etapa 2. Consolidación del prototipo y «alfa» interna

Cuando te aseguras de que el escenario básico funciona, comienza la etapa de «consolidación». Tú:

• ordenas la lógica hacia una estructura más o menos clara;
• empiezas a pensar qué permisos y datos necesita realmente el App;
• compruebas cómo se comporta el App ante errores (por ejemplo, cuando el catálogo de productos no responde).

Sigues en Dev Mode, pero ya no en solitario: añades a colegas como desarrolladores o testers para que también puedan conectar el App a su ChatGPT. El ciclo de vida en esta fase sigue girando alrededor del estado Draft: actualizas el código rápidamente, pruebas distintos patrones de UX y discutís el feedback dentro del equipo.

Etapa 3. Preparación para el Store y revisión

En este paso decides: «Sí, GiftGenius ya es lo bastante decente como para mostrarlo a usuarios externos». Ahora el foco pasa del código al empaquetado del producto:

• escribes una descripción honesta y clara del App;
• configuras los permisos: explicas a qué datos accede el App y para qué;
• te aseguras de que la UX no induce a error y de que el App no promete imposibles.

Este es el momento de pasar de Draft a Under review. Envías el App a revisión y durante un tiempo vive en ese estado intermedio. Puede que te lleguen comentarios: precisar la política de privacidad, ajustar textos, limitar permisos. Vuelves a Draft, corriges y lo envías de nuevo.

Etapa 4. Publicación y «vida real»

Tras la aprobación, tu GiftGenius queda en estado Published. Ahora los usuarios pueden encontrarlo en el Store, ChatGPT puede proponerlo en consultas relevantes y tú empiezas a recopilar feedback real, observar el uso y pensar en escalar.

A partir de ahora cada cambio de código no es simplemente «voy a ajustar rápido esta función». Es un mini‑lanzamiento. Debes pensar en la compatibilidad hacia atrás, planear migraciones, en lo posible cambiar primero la versión de dev, validarla y solo después actualizar la configuración de production.

Si es necesario, puedes pasar temporalmente el App a Paused si, por ejemplo, encuentras una vulnerabilidad crítica o tu backend no soporta la carga. Pero el ideal es desarrollar gradualmente la rama Published sin olvidar el entorno de dev para experimentar.

7. Cómo pensar los entornos: dev, staging, production + Dev Mode

Con el ejemplo de GiftGenius hemos recorrido el camino desde la idea en Dev Mode hasta el App publicado. Ahora organicémoslo en el esquema familiar para un desarrollador —dev/staging/production— y veamos cómo se relaciona con el Dev Mode y el Store.

Lo más cómodo suele ser tener en mente esta matriz:

Developer Mode, en esencia, se «adhiere» a tu infraestructura de dev o staging: publicas allí una URL temporal que ChatGPT usa para pruebas. La configuración del Store apunta, en cambio, a una URL de production ya madura.

En el futuro, cuando hablemos del deploy en Vercel y de los túneles, esta matriz se convertirá en una secuencia de pasos muy concretos. Pero ya ahora es útil mantener una idea simple: ten siempre claro dónde está la solicitud actual de ChatGPT —si en tu sandbox de dev o en el entorno en producción donde entran los usuarios.

8. Un «trozo de código» sobre el ciclo de vida

Para vincular todo esto con tu enfoque habitual de TypeScript, escribamos un tipo simple que refleje el ciclo de vida del App no ya a nivel de plataforma, sino a nivel de tu propio tooling. Puedes dejarlo en el repositorio para no olvidar los distintos 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 – selección de regalos',
  state: 'draft',
  lastDeployedAt: null,
  devUrl: 'https://dev.giftgenius.example.com',
};

Nunca enviarás un objeto así a ChatGPT, pero ayuda a que el equipo comparta contexto. Incluso puedes crear un CLI sencillito que muestre el estado de todos tus Apps para no confundirte entre lo que es borrador y lo que ya está en el Store.

En los siguientes módulos volveremos constantemente a este modelo de ciclo de vida: cuando configuremos túneles y el deploy en Vercel, al diseñar el servidor MCP y los escenarios de agentes, al pensar en el flujo de commerce y en la preparación para la revisión en el Store. Piensa en el Dev Mode y el Store como dos polos de un mismo sistema: la sandbox para experimentar y el escaparate para un producto ya maduro.

9. Errores típicos al trabajar con Dev Mode y el Store

Error n.º 1: «Directo al Store y ya veremos».
A veces quieres «conquistar el mercado» lo antes posible y subes el App al Store cuando aún es un prototipo medio funcional. Esto casi siempre lleva a valoraciones negativas, malas estadísticas de uso y preguntas adicionales en la revisión. Es mucho más sano vivir primero varias iteraciones en Developer Mode, recopilar feedback de colegas y amistades, estabilizar el UX básico y solo después ir al Store.

Error n.º 2: Mezclar los entornos de dev y production.
Escenario típico: configuras el Dev Mode con la misma URL que production y luego te sorprende que «unos cambios de depuración» los vieran usuarios reales. Debes separar las URLs de dev y prod con el mismo cuidado que en los servicios web normales. Si en la configuración de tu ChatGPT App hay una URL de production, no la uses para «experimentos rápidos por la noche».

Error n.º 3: Carecer de una idea clara sobre los estados.
Cuando el equipo no es consciente del estado en el que vive el App (Draft, Under review, Published, Paused), surgen situaciones extrañas: alguien cree que el App ya está en el Store, otra persona lo sigue viendo como un prototipo local. Vale la pena, al menos en el README del proyecto, describir dónde está ahora el App y qué hay que hacer para pasar a la siguiente etapa.

Error n.º 4: Ignorar la política y la revisión hasta el último momento.
Algunos equipos desarrollan el App «como si fuera solo un sitio» y recuerdan la política, los permisos y los requisitos del Store un día antes de enviarlo a revisión. Al final resulta que hay que rehacer en serio la recogida y el almacenamiento de datos, reescribir descripciones y restringir permisos. Mejor tener los márgenes en mente desde el principio y, ya en Dev Mode, experimentar con permisos honestos y mínimos.

Error n.º 5: No tener una estrategia separada para uso interno y externo.
Si el App nace como herramienta corporativa interna y luego quieres convertirlo en producto público, es fácil confundir la audiencia objetivo. Dentro de la empresa puedes permitirte una UX menos «pulida» y escenarios más complejos; en el Store externo los usuarios esperan otro nivel de comodidad. No entender en qué modo estás ahora lleva a que el App público parezca una herramienta interna de administración y que el piloto interno se estanque porque piensas demasiado pronto en el Store global.

Error n.º 6: Falta de conexión entre Dev Mode y la observabilidad.
Developer Mode es perfecto para depurar, pero hay que aprovechar esa ventaja. Si no miras los logs y no registras qué solicitudes exactas envía ChatGPT a tu App en el entorno de dev, más tarde, en production, puedes llevarte sorpresas desagradables. Mejor usar el Dev Mode como plataforma para estudiar el comportamiento real del modelo y de los usuarios, y no solo para comprobar «que el widget compila».