Proceso de revisión: cuentas de prueba, observaciones, iteraciones

1. Vista de alto nivel del proceso de revisión

Publicar una ChatGPT App en el Store no es «subir un enlace y olvidarse», sino un ciclo vivo. En una versión simplificada se ve así: preparas la App, la envías a revisión, las personas revisoras la prueban con sus check‑lists, recibes observaciones, mejoras y vuelves a enviar. Y así varias veces, hasta que todo quede satisfactorio para todos.

Lo más cómodo es verlo como un pequeño flujo de trabajo (workflow):

flowchart TD
  A[Dev Mode / Internal beta] --> B[Submit to Store]
  B --> C[Under review]
  C -->|Approved| D[Published]
  C -->|Changes requested| E[Fixes & Iteration]
  E --> B
  D --> F[Updates]
  F --> C
  D --> G[Paused / Unpublished]

En las fases tempranas (Dev Mode, beta interna) detectas problemas técnicos y de UX. Cuando pulsas «Submit to Store», comienza una revisión más formal: comprueban el cumplimiento de la política de contenidos, los permisos, la estabilidad y lo que está escrito en el listing y en los documentos legales.

Conviene adoptar desde el principio la siguiente filosofía: la revisión no es un examen en el que o «apruebas» y nunca vuelves, o «suspendes». Es un canal continuo de feedback entre tú y la plataforma. Store quiere que tu App sea segura, comprensible y estable, y tú quieres que te den acceso a los usuarios y no te retiren a la semana. Sorpresa: vuestros intereses, en realidad, coinciden.

2. Qué envías a revisión

Antes de que alguien del lado de la plataforma abra tu App, rellenas un conjunto bastante básico de elementos:

1. Metadatos de la App: nombre, subtítulo, categoría e icono.
2. Descripción del listing: descripción breve y completa, ejemplos de escenarios.
3. Enlaces a Privacy Policy, Terms, Support/Contact.
4. Configuración de permisos: qué accesos solicita la App (por ejemplo, OAuth, APIs externas, modos de pago, etc.).
5. A veces: descripción de escenarios de prueba y cuentas para la persona revisora.
6. La propia App: servidor MCP, bundle de UI, system‑prompt y descripciones de herramientas, que la plataforma ya conoce por Dev Mode/production‑URL.

Técnicamente, para entonces ya despliegas la versión de producción (normalmente en Vercel o similar), a la que el Store hará las solicitudes. Es decir, el botón «Submit» no trata del despliegue del código, sino sobre cambiar su estado: «este código ya está en tu producción; ahora, por favor, revísalo y da acceso a los usuarios».

Para conectar todas las piezas, suele ser útil tener una pequeña config en el repositorio, donde fijes explícitamente qué se incluye en la versión «candidata a revisión». Por ejemplo, una estructura sencilla en TypeScript:

// config/release-candidate.ts
export const releaseCandidate = {
  version: "1.0.0",
  apiBaseUrl: process.env.API_BASE_URL,
  enableCommerce: true,
  privacyPolicyUrl: "https://example.com/legal/privacy",
  termsUrl: "https://example.com/legal/terms",
  supportUrl: "https://example.com/support",
};

Este archivo no sustituye al propio formulario del Store, pero ayuda a tu equipo a entender qué es exactamente lo que estás «vendiendo» a los revisores y a los usuarios.

3. Cómo miran los revisores tu App

Bien, ya has completado los formularios, has preparado los enlaces y has pulsado Submit. ¿Qué ocurre al otro lado del Store? Imagina que tú mismo eres revisor. No has visto tu código, no conoces toda la historia del proyecto, pero tienes un check‑list y tiempo limitado. Normalmente se mira la App desde varios ángulos.

Primero, miran el cumplimiento de la política de contenidos y de marca. No se pueden ofrecer categorías prohibidas ni infringir las normas sobre medicina, derecho o finanzas sin los disclaimers necesarios y sin «human in the loop». No puedes hacerte pasar por OpenAI ni usar su marca como si fuera un producto oficial suyo.

Segundo, analizan los permisos. Si solicitas acceso a algo sensible (perfiles de usuario, pagos, una cuenta de terceros mediante OAuth), te preguntarán: ¿de verdad es necesario? ¿Y le queda claro al usuario por la descripción y por el comportamiento de la App? El caso ideal es que los permisos sean mínimos y se ajusten exactamente a los escenarios descritos.

Tercero, evalúan el UX y la estabilidad. La App no debe tomar toda la pantalla de ChatGPT: si se pone en fullscreen sin parar por cualquier motivo y sin una explicación clara, será un punto negativo. Si el backend lanza errores con frecuencia y las herramientas se rompen de forma intermitente, tampoco generará confianza.

Por último, miran la honestidad del listing: si la descripción de la App coincide con lo que el revisor ve realmente en el chat. Si prometes «selección relámpago del regalo perfecto y checkout inmediato», pero en la práctica la App falla tres veces en la fase de búsqueda y no sabe tramitar pedidos, la revisión terminará rápido y de forma poco agradable.

Para facilitar el trabajo a los revisores, tiene sentido prepararles de antemano una «ruta»: una lista de pasos que conviene probar y cuáles son los resultados esperados. Esto también te servirá para tu propia regresión.

Un ejemplo sencillo de este tipo de descripción en código es una estructura con escenarios de prueba, a la que se puede hacer referencia en la documentación interna:

// test/review-scenarios.ts
export const reviewScenarios = [
  {
    id: "gift-basic",
    title: "Selección de regalo sin compra",
    steps: [
      "Pedir: Elige un regalo para un amigo, le gustan los juegos de mesa, presupuesto 50$",
      "Verificar que la App ofrece opciones y no requiere inicio de sesión",
    ],
  },
  {
    id: "gift-checkout",
    title: "Selección de regalo con checkout de prueba",
    steps: [
      "Elegir cualquier regalo de la lista",
      "Ir al proceso de pago usando una tarjeta de prueba",
    ],
  },
];

Esta estructura no se envía directamente al Store, pero disciplina a tu equipo y luego ayuda a actualizar la descripción para revisores y soporte técnico.

4. Cuentas y datos de prueba: sin ellos la revisión no despega

En cuanto entran en juego el dinero, los datos personales o cuentas externas, los revisores esperan que proporciones una forma segura de recorrer todo el escenario sin usar su tarjeta real, su correo personal ni un Slack/Google/lo que sea reales.

De forma aproximada, se pueden distinguir dos grandes tipos de elementos de prueba.

Primer tipo: usuarios/organizaciones de prueba en tu sistema. Por ejemplo, para GiftGenius puedes crear una «organización de revisión» especial con un catálogo demo preparado y métodos de pago de prueba vinculados en el modo sandbox del proveedor de pagos. Es importante que el revisor no tenga que pasar por un onboarding complejo: idealmente, debería recibir un login/contraseña o un enlace mágico y aterrizar directamente en un sandbox listo para usar.

Segundo tipo: datos de prueba de proveedores externos. Los pagos, por regla general, tienen un modo sandbox (test cards, test accounts). Si tu App delega el pago a través de ACP/Instant Checkout, debes asegurarte de que usa el entorno de prueba durante la revisión y que nadie paga con dinero real. Esto ya toca la arquitectura de la parte de commerce, pero la idea es simple: añadir en el backend un flag de «review/test mode».

En términos de código, puede verse como un simple flag de entorno y una config:

// config/env.ts
export const env = {
  nodeEnv: process.env.NODE_ENV,
  reviewMode: process.env.REVIEW_MODE === "true",
  paymentProviderEnv: process.env.REVIEW_MODE === "true" ? "sandbox" : "production",
};

Y en el lugar donde inicializas el cliente del sistema de pagos:

// lib/payments/client.ts
import { env } from "@/config/env";

export const paymentClient = createPaymentClient({
  environment: env.paymentProviderEnv, // "sandbox" o "production"
  apiKey: process.env.PAYMENT_API_KEY!,
});

Este pequeño detalle facilita mucho la vida: puedes ejecutar la App en un modo lo más parecido posible a producción, pero sin que los revisores toquen dinero real.

Conviene pensar por separado en escenarios de prueba para integraciones como Gmail, Slack, Notion, etc. Donde se usa OAuth, la revisión a menudo espera o bien una cuenta demo común, o bien una instrucción muy simple sobre cómo crear un workspace de prueba. Procura evitar escenarios del tipo «escribe a soporte y te activamos algo manualmente» — muchas revisiones están automatizadas y tienen tiempo limitado, y nadie va a esperar a tu correo.

5. Observaciones típicas de la revisión y cómo responder

Ahora, quizás una noticia poco agradable: la probabilidad de que tu primer paso por la revisión sea perfecto es similar a la de que un programador escriba código sin bugs a la primera. Es decir, cercana a cero. Y no pasa nada.

Las observaciones suelen encajar en varias categorías predecibles.

Primera categoría — permisos y privacidad. Por ejemplo, solicitas acceso al email del usuario, pero en el listing no explicas para qué. O en la Privacy Policy pone que «no guardas datos del chat», pero los logs del servidor MCP registran tranquilamente toda la solicitud con PII. El revisor puede pedirte o bien aclarar los documentos, o bien cambiar el comportamiento de la App, o ambas cosas.

Segunda categoría — UX y comportamiento en el chat. La App puede «apoderarse» del diálogo: abrir agresivamente fullscreen donde bastaría con inline, no dejar un resumen textual tras las acciones, no dar al usuario una forma clara de «volver al chat». En tales casos, probablemente te pedirán simplificar el UX y respetar la interfaz conversacional principal de ChatGPT.

Tercera categoría — estabilidad y errores. Si en escenarios típicos la App muestra con frecuencia «Error talking to app» o 500 internas, la revisión puede detenerse hasta que demuestres que es un caso aislado y no la norma. Aquí se espera de ti no solo la corrección de bugs, sino también una observabilidad mínima: logs, health checks, timeouts razonables.

Cuarta categoría — honestidad del listing y promesas de marketing. Si en la descripción prometes más de lo que realmente puedes hacer, los revisores suelen detectarlo bastante rápido, especialmente si prometes «resultados garantizados» en dominios sensibles. La corrección aquí consta de dos pasos: o bien reduces las promesas, o bien aumentas la implementación (más bien lo primero).

¿Cómo responder correctamente a las observaciones? La regla principal es tratar la revisión como una colaboración, no como «moderadores malvados». En la respuesta conviene:

1. Reconocer el problema con claridad: «Sí, en la versión actual la App hace X y en la descripción pone Y».
2. Describir lo que ya has cambiado: «Hemos corregido el listing y actualizado la Privacy Policy, precisando que…».
3. Si es posible, añadir una breve descripción del escenario de prueba donde el revisor verá la corrección.

Si no entiendes con claridad por qué llegó la observación, es mejor hacer una pregunta de aclaración que intentar adivinar. Por ejemplo: «¿Entendemos bien que el problema principal es que la App se abre automáticamente en fullscreen sin petición del usuario?».

6. Checklist interno antes de enviar a revisión

Para reducir el número de iteraciones, es útil tener tu propio «checklist de preflight» inspirado en los módulos 7, 15–17. No es una lista «para cumplir el trámite», sino algo práctico que realmente pasas antes de cada envío.

Técnicamente incluso puedes incorporar este checklist al repositorio como un pequeño módulo JSON/TS y mostrarlo en el README o en el pipeline.

Una variante sencilla en TypeScript puede verse así:

// tools/review-checklist.ts
export interface ChecklistItem {
  id: string;
  description: string;
  done: boolean;
}

export const reviewChecklist: ChecklistItem[] = [
  {
    id: "ux-inline-first",
    description: "Los escenarios principales de la App funcionan en modo inline; fullscreen solo donde realmente esté justificado.",
    done: false,
  },
  {
    id: "privacy-links",
    description: "Los enlaces a Privacy Policy, Terms, Support son válidos y se abren sin autenticación.",
    done: false,
  },
  {
    id: "permissions-minimal",
    description: "Solo se solicitan los permisos mínimos necesarios; cada uno está descrito en el listing.",
    done: false,
  },
];

Y en alguna de tus herramientas internas o simplemente en la consola puedes mostrar esta lista y marcar el progreso. No es una automatización obligatoria, pero los programadores se llevan tradicionalmente mejor con el código que con Google Docs, así que ¿por qué no usar la herramienta habitual?

7. Iteraciones y versionado: la vida después de la primera publicación

Sorpresa número dos: incluso después de que tu App pase la revisión y sea accesible para los usuarios, el proceso no termina. Cualquier actualización relevante puede volver a activar una comprobación, especialmente si cambias permisos, añades escenarios sensibles o rediseñas el UX de forma radical.

Por eso conviene tratar la ChatGPT App como un producto vivo con un proceso de release normal, no como «el último disparo».

Normalmente, el mínimo razonable es: tener una versión en el código (semver), un registro de cambios (changelog) y una idea de qué releases requieren una nueva revisión y cuáles no. Por ejemplo, corregir erratas en el UI que no afectan al comportamiento de la App ni a los permisos puede pasar sin ruido, pero pasar de «solo recomendaciones» a «checkout completo con pago» seguro que requerirá nueva atención.

En el código puede verse como una constante sencilla y un objeto con cambios:

// config/app-version.ts
export const appVersion = "1.1.0";

export const appChangelog = {
  "1.1.0": [
    "Se añadió sandbox-checkout para usuarios de prueba",
    "Se precisó la descripción de permisos en el listing",
  ],
  "1.0.0": ["Primera versión pública de GiftGenius sin pagos"],
};

Y sí, es fantástico si sincronizas estas notas con lo que escribes en las notas de la versión del Store. Así tanto los revisores como los usuarios entienden más fácilmente qué ha pasado.

8. Comunicación con la plataforma: cómo no pelearse con los revisores

Quizá la habilidad más infravalorada sea hablar con normalidad con los revisores. Por lo general, el feedback llega en forma de un conjunto de puntos: qué está mal, qué apartados de la política estás incumpliendo, qué partes del UX generan dudas. Una buena respuesta no es «No tenéis ni idea», sino un mensaje tranquilo y concreto.

Conviene tener presentes algunos principios sencillos.

Primero, claridad. No escribas ensayos interminables sobre cómo está diseñada la arquitectura interna de tu servidor MCP y por qué es tan bonita. Al revisor le interesa ante todo la experiencia del usuario y el cumplimiento de la política. Basta con describir brevemente qué has cambiado y cómo puede comprobarse ahora.

Segundo, transparencia. Si el problema es más complejo que «hemos cambiado un texto» y requiere cambios sustanciales, es más honesto escribir: «Esta observación afecta a una parte clave de nuestro checkout‑flow; necesitaremos 1–2 semanas para corregirlo correctamente. Enviaremos una versión actualizada en cuanto esté lista».

Tercero, memoria. Conviene guardar las observaciones de la revisión no solo en el correo o en el tracker interno, sino también como una pequeña «decisión» en la documentación: qué exactamente no estaba permitido y por qué. Esto ayuda a que los nuevos desarrolladores y el product manager no tropiecen con las mismas piedras. Una nota interna simple en la documentación o incluso una sección README del tipo «Store Review Decisions» puede ayudar.

9. Relación con la arquitectura y los módulos anteriores

Es útil ver el proceso de revisión como una «prueba integral» de todo lo que hiciste en los módulos anteriores.

Sin los módulos de seguridad y permisos (7, 15) probablemente tendrás preguntas sobre accesos, trabajo con PII, OAuth y acciones destructivas.

Sin los módulos de estabilidad y observabilidad (16, 17) no podrás responder con claridad por qué la App a veces falla y a veces no, y cómo lo monitorizas. Las métricas y los SLO dejan de ser teoría y se convierten en argumentos: «vemos p95 < 2 segundos para la herramienta principal y error rate < 1% en los últimos N días».

Sin los módulos de UX (8, 11) la App puede simplemente «romper» el chat: fullscreen donde no hace falta, transiciones confusas entre modos, ausencia de un resumen textual. Los revisores ven estas cosas más rápido que tú porque prueban muchas Apps y perciben bien cuando alguien «se pasa».

Y, por último, sin la comprensión del proceso de revisión de hoy corres el riesgo de quedarte atascado en la fase de «enviamos, nos devolvieron, nos enfadamos». Es mejor verlo como otro ciclo de iteración, muy parecido a tu regresión interna, solo que con otro participante interesado — la plataforma.

En definitiva, si tienes un checklist razonable, cuentas de prueba y modo sandbox, una observabilidad básica y una comunicación normal con los revisores, el proceso de revisión deja de ser una lotería. Es simplemente otro ciclo iterativo alrededor de tu ChatGPT App — tan natural como la regresión previa al lanzamiento o el code‑review dentro del equipo.

10. Errores típicos al pasar la revisión

Error n.º 1: Enviar la App «tal cual» sin checklist interno.
Muchos equipos pulsan «Submit» justo después de que la App «funcione» en Dev Mode. Como resultado, en la revisión salen cosas básicas: enlaces rotos a Privacy/Terms, escenarios que no funcionan, ausencia de cuentas de prueba. Se soluciona con un check‑list interno sencillo que realmente pasas antes de cada envío (enlaces válidos, permisos mínimos, escenarios clave funcionando) — un ejemplo de ese check‑list lo acabamos de ver más arriba en la sección «Checklist interno antes de enviar a revisión».

Error n.º 2: Ignorar las cuentas de prueba y los modos sandbox.
Enviar a revisión una App que requiere la tarjeta bancaria real del revisor es una mala idea. Igual de malo es que el checkout exista teóricamente, pero que el revisor no pueda probarlo en absoluto. Hay que planear con antelación organizaciones/usuarios de prueba en tu sistema y el modo sandbox del proveedor de pagos, vinculado a REVIEW_MODE o a un flag similar.

Error n.º 3: Intentar «negociar» excepciones en lugar de solucionar el problema.
A veces los desarrolladores empiezan a discutir con el revisor: «pero los competidores lo hacen igual» o «es una limitación de la plataforma, no es cosa nuestra». Ese estilo rara vez ayuda. Es mucho más eficaz reformular el escenario, simplificar el UX, reducir los permisos y ajustar el listing para que refleje honestamente el comportamiento de la App.

Error n.º 4: No documentar las observaciones y las decisiones.
Si recibiste un comentario de la revisión y simplemente «arreglaste un bug en el código» sin anotar qué exactamente no estaba permitido, en seis meses alguien del equipo hará lo mismo de nuevo. Es mejor llevar un pequeño registro de decisiones de revisión: «No se puede abrir fullscreen automáticamente sin una acción explícita del usuario», «no se pueden guardar los textos completos de los chats más de N días sin indicarlo explícitamente en la Policy», etc.

Error n.º 5: «Releases grandes» sin una estrategia por etapas.
Intentar añadir en un solo release pagos, nuevos permisos, un nuevo UX y un backend rediseñado es una buena receta para largas iteraciones de revisión. Es mucho más tranquilo salir con pasos pequeños: primero recomendaciones sin pagos, luego sandbox‑checkout, y después un flujo de pago completo. Así reduces riesgos y hay menos motivos de discusión en la revisión.

Error n.º 6: Confiar en la aceptación del Store en vez de en tu propio QA y observabilidad.
A veces el equipo, de forma inconsciente, espera que los revisores «prueben por ellos». Como resultado, la revisión se convierte en un QA gratuito, pero retrasa el lanzamiento semanas. Es mucho más sano tratar la revisión como una comprobación final de cordura de un producto ya bastante maduro, con sus propias pruebas, logs, métricas y escenarios claros.