Construir
Cómo crear una app web con ChatGPT Sites (de la idea a una URL real)
Guía paso a paso con tres apps construidas de punta a punta: qué escribir en el prompt, dónde se guardan los datos, cómo probarla en serio y cómo publicarla sin exponerla sin querer.
Qué te llevás
- La plantilla de one-shot prompt: las diez piezas que hacen que la primera versión ya sea usable
- Los tres prompts completos de las apps que construimos, sin recortar
- El criterio para elegir dónde viven los datos, y por qué casi siempre alcanza con lo más simple
- El protocolo de pruebas y las 25 comprobaciones antes de abrirlo al público
- La diferencia entre guardar, desplegar y publicar — que es donde se cometen los errores caros
Antes de empezar
Necesitás: una cuenta de ChatGPT con acceso a Sites, y unos 35 minutos para leerla entera.
No necesitás: saber programar, ni saber diseñar, ni haber usado nunca una herramienta de desarrollo.
Sites está en beta pública mientras escribimos esto. La disponibilidad depende del plan, la región y las políticas del espacio de trabajo — los planes Free y Go no tienen acceso según la documentación oficial. Los nombres de los botones van a cambiar; el método de abajo no.
Esta guía documenta tres apps construidas de verdad el 30 de julio de 2026, con sus prompts completos y sus capturas. Ninguna quedó abierta al público, y esa decisión también es parte de lo que se enseña.
La idea central. Un Site no es una respuesta con texto ni una imagen de cómo podría verse una app. Es un proyecto web con interfaz, lógica, estados, almacenamiento y una URL de producción. Eso cambia lo que hay que pedir y lo que hay que revisar antes de publicarlo.
El mapa mental que evita los errores de publicación
Casi todos los accidentes con Sites vienen de mezclar estos siete conceptos. Vale la pena leer la tabla despacio una vez.
| Concepto | Qué significa | Qué NO significa |
|---|---|---|
| Proyecto o Site | El objeto que conserva el sitio, sus archivos, configuración y versiones. | Que el público pueda verlo. |
| Vista previa | Una ejecución temporal para inspeccionar mientras construís. | Una URL pública permanente. |
| Versión guardada | Un candidato inmutable que podés desplegar más adelante. | Que esté en producción por haberla guardado. |
| Despliegue | La acción que pone una versión en una URL de producción. | Que el sitio quede abierto a Internet. |
| Acceso | Quién puede abrir el Site: vos, personas elegidas, el espacio de trabajo o cualquiera. | Permiso para editar el proyecto. |
| URL de producción | La dirección estable de una versión desplegada. | Prueba de que sea pública: puede pedir autenticación. |
| Versión de trabajo | Los cambios que ChatGPT está construyendo en la conversación. | Un reemplazo de una versión guardada ni de un despliegue. |
La regla que resume todo. Toda URL de despliegue es producción. Si todavía estás revisando, pedí explícitamente «guardá una versión sin desplegar». La vista previa y la versión guardada son tus espacios seguros.
Dónde va a guardar la información tu app
La interfaz es la mitad del trabajo. En cuanto la app tiene favoritos, resultados, archivos o un ranking, hay que decidir dónde vive eso. La opción más simple que cumple el objetivo es casi siempre la correcta.
| Opción | Cuándo | El límite que hay que conocer |
|---|---|---|
| Sin persistencia | Simuladores, calculadoras cuyo resultado se puede rehacer, demos sin datos personales. | Todo desaparece al recargar. |
| localStorage | Borradores, favoritos, listas personales sin cuenta. | No sincroniza entre el teléfono y la computadora. Se pierde si se limpia el navegador. |
| D1 | Varias personas leen o escriben los mismos registros: puntajes, solicitudes, votos. | Es una verdad compartida: hay que pensar quién escribe y qué pasa si abusan. |
| R2 | Archivos: documentos, imágenes. | Suele combinarse con D1, que guarda el nombre, la fecha y el estado. |
Hay tres cosas que se confunden seguido y conviene separar: el acceso es quién puede entrar, la identidad es cómo la app sabe quién es esa persona, y los permisos son qué puede hacer una vez adentro.
Las claves nunca van en el prompt. Ni en un archivo de contenido, ni en el código visible. Van como variables de entorno, desde la configuración del Site.
La fórmula de un one-shot prompt
«One shot» no significa pedir «haceme una web» y aceptar lo que salga. Significa entregar en un solo mensaje un brief tan claro que la primera construcción ya sea completa y probable.
Un prompt profesional cubre diez piezas: disparador, audiencia, resultado, recorrido, reglas, datos, diseño, estados, calidad y liberación.
Plantilla universal
Creá un Site llamado "[NOMBRE]" para [AUDIENCIA]. Objetivo: [RESULTADO CONCRETO QUE DEBE LOGRAR EL USUARIO]. Flujo principal: 1. [PRIMERA ACCIÓN]. 2. [SEGUNDA ACCIÓN]. 3. [RESULTADO Y ACCIÓN FINAL]. Lógica y reglas: - [REGLA 1]. - [REGLA 2]. - [CASOS LÍMITE]. Datos: - Guardá [DATOS] en [SIN PERSISTENCIA / LOCALSTORAGE / D1 / R2]. - No solicites [DATOS INNECESARIOS O SENSIBLES]. - Incluí una acción para [BORRAR / EXPORTAR / REINICIAR]. Diseño: - [DIRECCIÓN VISUAL]. - Responsive para escritorio y móvil. - Interfaz en español rioplatense, clara y profesional. Calidad: - Validá campos y mostrale al usuario cómo corregir errores. - Incluí estados vacío, carga, éxito y error. - Usable con teclado, foco visible, labels y contraste legible. - Probá el recorrido completo y corregí los errores encontrados. Entrega: - Abrí una vista previa privada para revisar. - No despliegues ni cambies el acceso público. - Al terminar, resumí qué construiste, qué probaste y qué queda por configurar.
Lo que el prompt no decide, ChatGPT lo interpreta. Para el diseño eso puede jugar a favor. Para los datos, la privacidad, la publicación y las reglas de negocio, no.
01
Definí una sola transformación
Completá esta oración antes de escribir nada: «después de usar mi Site, la persona podrá…». Si te salen tres verbos sin relación entre sí, el alcance es demasiado grande y conviene partirlo en dos productos.
Sirven: «calcular el costo anual de sus reuniones y diseñar un escenario mejor». «Jugar un desafío de fútbol y comparar su puntaje». «Elegir una microaventura realizable hoy y guardar el plan».
No sirven: «tener una plataforma integral». «Gestionar todo el negocio». «Hacer una web moderna».
02
Elegí dónde van a vivir los datos
Cinco preguntas, en este orden: ¿la app puede funcionar sin recordar nada? ¿Los datos son personales y sólo deben vivir en ese dispositivo? ¿Varias personas necesitan ver la misma información? ¿Hay archivos? ¿La app necesita saber de quién es cada registro?
La respuesta define si vas a pedir localStorage, D1 o nada. Decidirlo ahora evita rehacer la app entera después.
03
Abrí Work y pedí un Site
En ChatGPT web o en la app de escritorio, entrá a Work e indicá explícitamente que querés crear un Site. También podés mencionar @Sites si la interfaz lo admite. El pedido explícito ayuda a activar el flujo correcto en vez de recibir una respuesta de texto.
04
Pegá el prompt y adjuntá referencias
Podés sumar archivos con datos de ejemplo, un logo y una paleta sobre los que tengas derechos, capturas propias, un moodboard original, enlaces accesibles o restricciones legales y de marca.
Una referencia no es un permiso para copiar. Pedí que se extraigan principios —jerarquía, ritmo, densidad, color— y no una réplica pixel por pixel. Más abajo está la instrucción exacta que usamos.
05
Esperá la construcción y autorizá la vista previa
Sites puede tardar varios minutos. Una app con almacenamiento, lógica y pruebas tarda bastante más que una landing estática, y eso es buena señal: significa que está construyendo y probando, no maquetando.
Durante la primera previsualización puede aparecer una autorización para abrir el entorno temporal. Revisala y aceptala sólo si coincide con lo que pediste.
06
Probá como usuario, no como espectador
Acá es donde se cae la mayoría. No alcanza con mirar si quedó linda: hay que completar la acción principal.
- Empezá desde cero.
- Cargá un dato normal.
- Forzá un dato inválido.
- Llegá hasta el resultado.
- Recargá la página.
- Comprobá qué se conservó y qué no.
- Repetí todo en el teléfono.
- Navegá con el teclado si el caso lo amerita.
07
Pedí correcciones observables
«Mejoralo» no se puede verificar, así que produce cambios al azar. Este pedido, en cambio, tiene criterio de terminado:
Pasada de QA
Revisá el Site "[NOMBRE]" como QA. Probá el recorrido completo en escritorio y móvil. Corregí cualquier error que impida [ACCIÓN PRINCIPAL]. Verificá validaciones, estados vacíos, recarga, persistencia, botones de copiar/exportar y navegación por teclado. No cambies el objetivo del producto, no agregues funciones nuevas y no despliegues. Al terminar, listá las pruebas ejecutadas y los cambios realizados.
08
Guardá un checkpoint sin publicarlo
Este paso separa el trabajo creativo de la decisión de producción, y es el que casi nadie da.
Guardar sin desplegar
Guardá la versión actual de "[NOMBRE]" como una versión inmutable y desplegable, pero no la despliegues, no generes una URL de producción y no cambies el acceso. Confirmame el número de versión guardada.
09
Desplegá recién cuando estés listo
Desplegar con acceso limitado
Desplegá la versión [NÚMERO] de "[NOMBRE]". Mantené el acceso limitado únicamente a [PROPIETARIO / PERSONAS / WORKSPACE]. No habilites acceso público a Internet. Luego confirmame la URL y el nivel de acceso efectivo.
Para volverlo público, pedilo en una instrucción aparte. Así no se confunde «tener URL» con «estar abierto», que es exactamente el error que produce las publicaciones accidentales.
10
Verificá como visitante
Abrí la URL en una ventana o sesión que represente al público real, no en la tuya. Confirmá quién puede entrar, si se pide inicio de sesión, que no hayan quedado datos de prueba a la vista, que la acción principal funcione, que privacidad y contacto estén visibles si corresponde, y que en móvil se pueda usar.
El kit
Los tres prompts completos, sin recortar
Los prompts de las tres apps que vas a ver abajo, enteros y listos para adaptar. Más la plantilla comentada, los seis pedidos de iteración, el protocolo de pruebas y las 25 comprobaciones de lanzamiento. Dejanos tu correo y se abren acá y al pie.
Te suscribís a Señal IA. Un correo cada dos días, baja en un clic.
Tres apps, tres arquitecturas distintas
Las tres se construyeron el mismo día, con un solo prompt cada una. Sirven porque resuelven problemas distintos y por eso terminan guardando los datos en lugares distintos: no hay una arquitectura única para «hacer una app».
A
EL ÚLTIMO 10 — un juego con ranking compartido
Una experiencia de 60 segundos con cinco decisiones tácticas y un puntaje compartible. La misma «semilla» permite que dos amigos jueguen exactamente el mismo desafío. No busca simular un partido real: busca una mecánica rápida y comparable.
Prompt completo
Creá un Site llamado “EL ÚLTIMO 10 — Desafío de fútbol”. Concepto: Un mini juego competitivo, rápido y compartible para fanáticos del fútbol. El jugador dispone de 60 segundos para resolver 5 situaciones tácticas. En cada ronda ve una cancha esquemática, una pregunta y 4 decisiones posibles. La respuesta correcta debe ser determinística para que dos personas que jueguen la misma semilla reciban el mismo desafío. Flujo: 1. Inicio: pedir solamente un apodo de máximo 16 caracteres y elegir dificultad: Potrero, Primera o Mundial. 2. Mostrar una semilla visible y una acción para copiar el desafío. 3. Ejecutar 5 rondas. Cada ronda debe permitir una sola respuesta, explicar en una frase por qué la opción fue buena o mala y avanzar. 4. Calcular un puntaje de 0 a 1000 con aciertos, bonus por velocidad y racha. 5. Resultado: puntaje, perfil de juego entre cuatro arquetipos originales, resumen por ronda, acción “jugar otra vez” y texto listo para compartir sin depender de una API social. 6. Mostrar Top 10 general y Top 10 de esa semilla. Datos: - Usá almacenamiento durable D1 para ranking, porque distintos jugadores deben ver los mismos resultados. - Guardá únicamente apodo, puntaje, duración, dificultad, semilla y fecha. - No pidas email, teléfono, ubicación ni nombre real. - Evitá insultos básicos en apodos y validá longitud. Contenido: - Creá al menos 18 situaciones originales para rotar. - Usá equipos, escudos y nombres completamente ficticios. - No uses logos, camisetas, jugadores, ligas ni marcas reales. Diseño: - Estética de transmisión deportiva nocturna + arcade editorial. - Fondo casi negro, marfil, verde lima eléctrico y acentos cian. - Tipografía de alto impacto para titulares y monoespaciada para datos. - Cancha abstracta y legible; animaciones breves que respeten reduced motion. - Responsive y especialmente cómodo en móvil. Calidad: - Incluí estados de carga, error, ranking vacío y partida finalizada. - Evitá respuestas dobles, puntajes repetidos y partidas reiniciadas por recarga. - Usable con teclado, foco visible, labels, contraste y mensajes comprensibles. - Probá inicio, cinco rondas, guardado del resultado, ranking, reinicio y móvil. Entrega: - Construí y abrí una vista previa privada. - No habilites acceso público. - Al final resumí qué probaste y qué datos persisten.
Qué enseña. Un resultado compartible y una semilla común generan conversación sin depender de ninguna red social. El ranking necesita D1: no puede vivir en el navegador de cada jugador. Y el atractivo futbolero no exige copiar una liga, un escudo ni un jugador real.
Estado de publicación. Esta demo se desplegó en una URL de producción con acceso privado, limitado al propietario. Alcanzó para comprobar el ciclo completo de despliegue sin exponerla. Tener una URL no la vuelve pública.
B
MEETING TAX — una herramienta con impacto económico
Una calculadora que traduce una reunión recurrente a costo mensual y anual, evalúa su «deuda de decisión» con seis criterios y propone una acción: mantener, rediseñar, volver asincrónica o eliminar.
Prompt completo
Creá un Site llamado “MEETING TAX — El costo invisible de reunirse”. Audiencia: Equipos, líderes y profesionales que quieren entender cuánto cuestan sus reuniones recurrentes y rediseñarlas con mejores decisiones. Objetivo: Permitir calcular en menos de dos minutos el costo por reunión, mensual y anual; evaluar la calidad de decisión; comparar un escenario actual con uno mejorado; y copiar o exportar un resumen accionable. Flujo y campos: 1. Nombre de la reunión. 2. Cantidad de asistentes. 3. Duración en minutos. 4. Frecuencia mensual. 5. Costo promedio por hora y selector de moneda editable. 6. Seis preguntas Sí/No: agenda previa, decisión esperada, responsable definido, material enviado, sólo participan personas necesarias y existe registro final. 7. Resultado inmediato y transparente. Cálculos: - costo por reunión = asistentes × duración/60 × costo horario; - costo mensual = costo por reunión × frecuencia; - costo anual = costo mensual × 12. - Mostrá la fórmula y no presentes el cálculo como una estimación exacta de productividad o retorno. - Construí un índice de deuda de decisión basado exclusivamente en las seis respuestas y explicá la regla. - Recomendación determinística entre Mantener, Rediseñar, Async o Eliminar. Escenarios: - Incluir una comparación “actual vs. propuesta” modificando asistentes, minutos y frecuencia; calcular ahorro mensual y anual. - Precargar dos ejemplos editables, uno de daily y otro de comité. Gestión: - Guardar reuniones en una cartera local. - Duplicar, editar, eliminar, ordenar por costo anual. - Botón para borrar todos los datos. - Copiar un mensaje breve para Slack/email. - Exportar la cartera a CSV. Datos: - Usá localStorage; no crees backend ni cuenta. - Explicá que los datos permanecen únicamente en ese navegador y no sincronizan. - No solicites salarios individuales, nombres de asistentes ni datos sensibles. Diseño: - Editorial financiero, serio pero provocador. - Papel cálido, negro, rojo señal y verde para ahorro. - Titulares grandes, números con jerarquía, grilla clara y detalles precisos. - Responsive; en móvil, los campos y resultados deben leerse sin zoom. Calidad: - Validá cero, negativos, campos vacíos y valores extremos. - Incluí estados de cartera vacía, confirmación antes de borrar y feedback al copiar. - Navegación por teclado, labels, foco visible, contraste y texto alternativo. - Probá cálculo, escenario, guardado, edición, duplicado, borrado, copia, CSV, recarga y móvil. Entrega: - Abrí una vista previa privada. - No despliegues, no generes URL de producción y no cambies el acceso. - Resumí las pruebas realizadas.
Qué enseña. Una herramienta convierte datos simples en una conversación operativa, cosa que un consejo genérico no hace. La fórmula queda auditable: cualquiera puede comprobar de dónde salió el número. Y «determinística» obliga a que las mismas respuestas den siempre la misma recomendación, en vez de una adivinanza distinta cada vez.
C
PLAN B — una app personal a partir de una referencia visual
Un generador de microaventuras cercanas para resolver «¿qué hago hoy?» sin mapas, sin geolocalización, sin clima y sin ninguna API. Filtrás por tiempo, presupuesto, energía, escenario y compañía, y recibís un itinerario corto que podés guardar.
Antes del prompt hubo un paso previo: en vez de copiar una pantalla de Mobbin o Dribbble, se armó un moodboard propio.
Prompt completo
Creá un Site llamado “PLAN B — Microaventuras cerca, sin sobrepensar”. Audiencia: Personas que tienen entre 45 minutos y medio día libre y quieren hacer algo distinto sin organizar un viaje, revelar su ubicación ni investigar durante una hora. Objetivo: Generar en segundos un plan concreto, seguro y adaptable a cualquier ciudad. Referencia: Usá la imagen adjunta como moodboard original. Extraé su jerarquía editorial, papel cálido, azul intenso, rojo, amarillo, números grandes y lenguaje de pase/ticket. No copies pixel por pixel ni conviertas la referencia en una imagen estática. Construí una interfaz web responsive y accesible. Filtros: - tiempo disponible; - presupuesto: gratis, bajo o medio; - energía: baja, media o alta; - escenario: interior, exterior o cualquiera; - compañía: solo, pareja o amigos. Contenido y lógica: - Creá 24 microaventuras originales, genéricas y adaptables, sin negocios ni lugares reales. - Usá una semilla visible para que la misma combinación reproduzca el mismo plan. - El resultado incluye: título, intención, itinerario por bloques, preparación de cinco minutos, checklist, presupuesto estimado y alternativa por clima, cansancio o cierre. - Evitá actividades ilegales, intrusivas, peligrosas, ingreso a propiedad privada, conducción distraída y consejos médicos. - Si una actividad exige evaluar seguridad local, decilo con claridad. Gestión: - Guardar planes, copiar un pase en texto, duplicar, renombrar y eliminar. - Usá localStorage; no backend, cuenta, geolocalización, mapas, clima ni API externa. - Agregá “Borrar mis planes” y explicá que sólo persisten en ese navegador. Estados: - inicio claro, generación, resultado, guardados vacíos, error y confirmación. - Si no existe una combinación exacta, ofrecer la alternativa más cercana y explicar qué filtro cambió. Diseño y accesibilidad: - Español rioplatense, tono cálido y nada infantil. - Responsive, touch targets cómodos, labels, foco visible, contraste y reduced motion. - No uses el color como único indicador. Pruebas: - Generación con combinaciones distintas, semilla, alternativa, guardar, copiar, duplicar, renombrar, borrar, recargar, teclado y móvil. Entrega: - Abrí una vista previa privada. - No despliegues, no generes URL de producción y no cambies el acceso. - Resumí lo construido y probado.
Qué enseña. No toda app necesita APIs: sacar geolocalización y clima reduce permisos, riesgo y fallas. La semilla aporta consistencia sin identificar a nadie. Y el fallback es parte del producto: si no hay coincidencia exacta, la app explica qué filtro relajó en vez de devolver una pantalla vacía.
Qué muestra el panel cuando mirás las tres juntas
La diferencia entre las tres filas no es un error, es el patrón que conviene seguir: construir y probar, guardar un checkpoint, decidir si hace falta desplegar, definir la audiencia y recién ahí verificar la experiencia real.
| Decisión | EL ÚLTIMO 10 | MEETING TAX | PLAN B |
|---|---|---|---|
| Propósito | Juego compartible | Decisión laboral cuantificada | Plan personal accionable |
| Persistencia | D1 compartido | localStorage | localStorage |
| Identidad | Apodo, sin cuenta | No necesaria | No necesaria |
| API externa | No | No | No |
| Estado final | Desplegado, privado | Versión 1, sin desplegar | Versión 1, sin desplegar |
| Riesgo central | Abuso de apodos y marcas deportivas | Leer la estimación como exactitud | Seguridad de las actividades |
| Prueba distintiva | Partida + ranking + móvil | Fórmulas + CSV + recarga | Fallback + semilla + guardados |
El protocolo de pruebas
Seis pasadas sobre el producto funcionando. Ninguna se hace mirando la portada.
A. Recorrido feliz. El caso normal de principio a fin, sin interrumpirlo hasta llegar al valor prometido.
B. Errores y extremos. Campos vacíos, números negativos o excesivos, texto larguísimo, doble clic, volver atrás, recargar en la mitad, quedarse sin resultados, perder conexión.
C. Persistencia. Guardá algo, cerrá, recargá. Qué reaparece, en qué dispositivo, si otro usuario lo ve, si borrar borra de verdad y si duplicar crea un registro nuevo.
D. Móvil. Sin desplazamiento horizontal accidental, botones de tamaño táctil, formularios legibles sin zoom, teclado numérico donde corresponde, y el resultado importante visible sin scrollear.
E. Accesibilidad mínima. Navegación completa con teclado, foco visible, labels asociados, contraste suficiente, mensajes de error comprensibles, el color nunca como único indicador, y animaciones que respeten prefers-reduced-motion.
F. Privacidad y permisos. Pedir sólo lo necesario, explicar dónde se guarda, ofrecer borrar y exportar, probar con el acceso real y no dejar datos de ejemplo a la vista.
Auditoría final
Actuá como responsable de QA y lanzamiento de este Site. 1. Enumerá los criterios de aceptación del recorrido principal. 2. Probá happy path, campos inválidos, estados vacíos, recarga y persistencia. 3. Probá ancho móvil y navegación por teclado. 4. Revisá qué datos se capturan, dónde se guardan y cómo se eliminan. 5. Confirmá que no haya secretos, datos de prueba, enlaces rotos ni marcas sin permiso. 6. No agregues alcance nuevo. 7. Corregí los fallos reproducibles. 8. Entregá un reporte breve: prueba, resultado, corrección y riesgo restante. No despliegues ni cambies el acceso.
Refinar sin romper lo que ya funciona
Las mejores iteraciones son específicas y conservan límites. Estas tres cubren casi todo lo que vas a necesitar.
Cambio visual
En "[NOMBRE]", conservá toda la lógica y los datos. Reducí la densidad visual de la pantalla inicial: un objetivo principal, un CTA y la información secundaria debajo. Mantené la paleta y la accesibilidad. No cambies reglas, persistencia ni despliegue. Probá móvil al terminar.
Cambio funcional
En "[NOMBRE]", agregá [FUNCIÓN] únicamente después de [EVENTO]. Definición de terminado: - [CRITERIO 1]; - [CRITERIO 2]; - [ERROR ESPERADO]. No modifiques [ZONAS ESTABLES]. No despliegues.
Reparar una regresión
La acción [BOTÓN/PASO] falla cuando [CONDICIÓN]. Reproducí el error, identificá la causa, corregilo y repetí la prueba. No rediseñes la interfaz ni agregues funciones. No despliegues.
Guardá el checkpoint antes, no después. Si una iteración empeora el producto, volvés a una versión anterior. Eso sólo funciona si la guardaste con un nombre claro antes de tocar nada.
Publicación, acceso y dominio
| Estado | ¿URL? | Quién entra | Para qué |
|---|---|---|---|
| Vista previa | No | Sólo vos | Probar mientras construís |
| Versión guardada | No | Nadie | Congelar un candidato |
| Despliegue privado | Sí | Propietario o autorizados | QA real |
| Despliegue público | Sí | Internet | Lanzamiento |
Según el plan y la configuración, un Site puede limitarse al propietario y administradores, a personas o grupos elegidos, a los miembros del espacio de trabajo, o abrirse a cualquiera. Compartir para ver no da permiso de edición: eso es otro permiso sobre el proyecto.
Cuando esté disponible para tu plan, podés conectar un dominio propio y configurar DNS. Conviene revisar disponibilidad y límites actuales antes de prometérselo a un cliente. Los Sites desplegados también pueden registrar métricas de visitantes y vistas — pero tener analytics incorporado no te exime de los avisos legales ni de la base legal que corresponda.
Seguridad y responsabilidad
OpenAI da la infraestructura. Quien crea el Site sigue siendo responsable de su contenido, su funcionamiento, sus derechos y del tratamiento de los datos de sus usuarios.
Antes de pedir un dato, siete preguntas: ¿es indispensable? ¿Puedo cumplir el objetivo con menos? ¿Dónde se almacena? ¿Quién puede verlo? ¿Cuánto se conserva? ¿Cómo lo corrige, exporta o elimina la persona? ¿Qué pasa si es incorrecto o abusivo?
Lo que no va en un Site. Claves de API o credenciales, información confidencial de un cliente, datos personales sin finalidad ni base adecuadas, contenido sobre el que no tengas derechos, y datos de prueba que identifiquen a personas reales. La documentación actual también indica que Sites no debe usarse para información médica protegida ni datos de tarjetas de pago.
En el lanzamiento, Sites no ofrece residencia de datos ni de inferencia. Para una organización con requisitos regulatorios, eso hay que evaluarlo antes de construir, no después.
Usar una referencia visual sin copiarla
Una captura de Mobbin, Dribbble o de una web existente sirve para hablar de diseño, pero como plantilla trae tres problemas: no te da licencia sobre marca ni ilustraciones, no define comportamiento ni datos ni errores, y puede producir un producto genérico que ignora a tu audiencia.
La instrucción segura
Analizá esta referencia únicamente por sus principios de jerarquía, espaciado, densidad, ritmo, contraste y tono. No copies composición, textos, iconos, logos, ilustraciones ni detalles distintivos. Proponé un sistema visual original que cumpla el objetivo de mi Site y documentá qué principios adoptaste.
Si algo sale mal
No aparece Sites. Plan, región, beta o política del espacio de trabajo. Revisá el plan, la disponibilidad y consultá al administrador.
La construcción tarda muchísimo. Es normal si hay lógica, almacenamiento y pruebas. Pedí un resumen sólo si parece detenida del todo.
La vista previa abre otro proyecto. Contexto temporal de la conversación. Nombrá explícitamente el Site y pedí reabrir su preview.
«Compartir» aparece inactivo. Hay versión guardada, pero no hay despliegue. Es el comportamiento correcto: decidí si corresponde desplegar.
La URL existe pero otra persona no entra. El acceso es privado o requiere identidad. Revisá la audiencia efectiva, no la que creías haber configurado.
Se perdieron los favoritos. Estaban en localStorage y se limpió el navegador, o se abrió desde otro. Si hace falta sincronizar, el camino es D1.
Dos usuarios ven rankings distintos. El ranking se guardó localmente. Migralo a almacenamiento compartido.
El diseño se parece demasiado a la referencia. Se trató la imagen como plantilla. Pedí principios y un sistema original.
La app luce bien pero falla. Se revisó la portada y no el recorrido. Corré el protocolo de QA completo.
Checklist antes de abrirlo al público
Producto. La promesa se entiende sin explicación · el recorrido principal termina · existen los estados vacío, carga, éxito y error · las fórmulas se pueden explicar · no hay contenido ficticio presentado como real.
Datos. Cada dato pedido es necesario · la persistencia coincide con el caso · borrar y exportar funcionan · no hay secretos en el código visible · los datos de prueba fueron eliminados.
Calidad. Se probó escritorio y móvil · teclado y foco · labels y validación · el color no es el único indicador · enlaces, copiar, exportar y recarga funcionan.
Publicación. Se guardó una versión candidata · se desplegó exactamente esa · se verificó la URL como visitante · la audiencia efectiva coincide con la intención · hay un responsable de volver atrás.
Legal. Derechos revisados · privacidad y contacto visibles · moderación prevista si hay contenido de usuarios · analytics declarado · términos vigentes revisados.
Ocho ideas para adaptar
Son disparadores de una sola transformación, no prompts completos. Para elegir, priorizá una fricción frecuente, un resultado demostrable en menos de tres minutos y una salida que la persona quiera guardar o compartir.
- Generador de brief para campañas: entrevista guiada, resumen y exportación.
- Calculadora de precio: variables transparentes y escenario recomendado.
- Diagnóstico de madurez de IA: preguntas, puntaje explicable y plan de 30 días.
- Portal de onboarding: checklist, recursos y progreso por rol.
- Juego de cultura interna: situaciones, decisiones y debate en equipo.
- Planificador de menú semanal: restricciones, tiempo y lista copiable.
- Informe interactivo: datos subidos, filtros y narrativa por público.
- Selector de propuesta comercial: necesidades, alcance, supuestos y próximos pasos.
Preguntas frecuentes
¿Necesito saber programar para usar ChatGPT Sites?
No para empezar. Necesitás describir con precisión el objetivo, el flujo, los datos y las pruebas. El conocimiento técnico ayuda en integraciones complejas, seguridad y diagnóstico, pero no es requisito para construir estas tres clases de app.
¿Un one-shot prompt elimina la iteración?
No. Produce una primera versión más completa. La iteración sigue haciendo falta para comprobar comportamiento real, accesibilidad, privacidad y ajuste con usuarios.
¿Guardar una versión publica mi Site?
No. Una versión guardada es un candidato desplegable. La publicación ocurre cuando desplegás esa versión.
¿Desplegar lo vuelve público?
No necesariamente. Un despliegue crea una URL de producción, pero el acceso puede seguir limitado al propietario, a personas seleccionadas o al espacio de trabajo.
¿localStorage es una base de datos?
No. Es almacenamiento local del navegador: no sincroniza entre dispositivos y no crea una verdad compartida. Para registros compartidos y durables, la opción es D1.
¿Puedo usar una captura de otro producto como referencia?
Podés analizar referencias cuyo uso sea legítimo, pero una captura no concede permiso para copiar. Pedí principios visuales, usá activos propios o licenciados y construí un sistema original.
¿Puedo conectar una API externa?
Depende del soporte y de la configuración del Site. Las claves van en variables de entorno, nunca en el prompt, en archivos públicos ni en texto visible.
¿Puedo cobrar dentro de un Site?
Revisá las capacidades y políticas vigentes. Los datos de tarjeta no deben procesarse directamente en Sites; cuando el caso está permitido, se usa un procesador externo.
¿Quién es responsable de los datos de los visitantes?
Quien crea y opera el Site. La plataforma da la infraestructura, pero la finalidad, la información al usuario, la seguridad, la conservación y la moderación siguen siendo responsabilidad de quien lo publica.
¿Cómo sé si mi Site está listo?
Cuando existe una versión identificable que pasa los criterios de aceptación, las pruebas de error, móvil, teclado, persistencia, privacidad y acceso; y fue verificada como visitante después del despliegue.
De dónde salen los datos
Las tres demostraciones se construyeron y se probaron en una sesión real el 30 de julio de 2026. EL ÚLTIMO 10 se desplegó con acceso privado; MEETING TAX y PLAN B quedaron como versiones guardadas sin desplegar. Ninguna se abrió al público.
- Creating and managing ChatGPT Sites — OpenAI Help Center
- ChatGPT Sites — guía oficial para desarrolladores
- ChatGPT Sites Terms
- Understanding responsibilities for your ChatGPT Sites
- ChatGPT Sites: complying with data protection laws
- ChatGPT Sites: how to prepare a privacy policy
Cómo envejece esta guía. Sites está en beta: los nombres de los botones, los planes y los límites van a cambiar. El método no. Antes de repetir una cifra de disponibilidad o de prometerle algo a un cliente, mirá la fecha de la documentación oficial.
El kit
plantilla-one-shot-prompt.md— empezá por acá: las diez piezas y la plantilla para llenardecidir-donde-guardar-datos.md— la decisión que va antes del promptprompt-el-ultimo-10.md— el prompt completo del juego con rankingprompt-meeting-tax.md— el prompt completo de la calculadoraprompt-plan-b.md— el prompt completo del generador de planesprompts-de-iteracion.md— los seis pedidos para corregir, guardar y desplegarprotocolo-de-pruebas.md— las seis pasadas de QA y la auditoría finalchecklist-lanzamiento.md— las 25 comprobaciones y los cuatro estadosreferencias-visuales-sin-copiar.md— cómo usar una referencia sin quedar pegadoglosario-sites.md— los doce términos, en una páginaREADME.md— en qué orden usar todo
Dejanos tu correo y las descargas se abren acá mismo.
Te suscribís a Señal IA. Un correo cada dos días, baja en un clic.
Listo — el kit es tuyo
O bajalos de a uno:
- plantilla-one-shot-prompt.md — empezá por acá
- decidir-donde-guardar-datos.md — la decisión previa al prompt
- prompt-el-ultimo-10.md — el juego con ranking
- prompt-meeting-tax.md — la calculadora
- prompt-plan-b.md — el generador de planes
- prompts-de-iteracion.md — corregir, guardar, desplegar
- protocolo-de-pruebas.md — las seis pasadas de QA
- checklist-lanzamiento.md — las 25 comprobaciones
- referencias-visuales-sin-copiar.md — referencias sin copiar
- glosario-sites.md — los doce términos
- README.md — en qué orden usar todo