Codex Sites vs aplicaciones web a medida: cuándo usar cada opción en 2026

La decisión Codex Sites vs aplicación web a medida es simple: use Codex Sites para aplicaciones internas de workspace, prototipos revisables y herramientas temporales. Construya una aplicación web a medida cuando usuarios externos, datos de negocio duraderos, auth profunda, cumplimiento, integraciones o propiedad del código fuente definan el proyecto.

OpenAI no mató a las agencias web el 2 de junio de 2026. OpenAI mató la excusa de que un equipo necesita un mes para ver una primera versión funcional.

Eso importa si su equipo tiene una idea atrapada en un documento, un workflow en una hoja de cálculo o un dashboard que nadie tiene tiempo de construir. Este artículo le da la línea de decisión, la checklist de riesgo y el marco de precios. Separa lo que Codex Sites debería asumir de lo que pertenece a una aplicación web a medida preparada para producción.

• Codex Sites encaja mejor con aplicaciones internas de workspace. Piense en planificadores, dashboards, hubs de revisión, juegos y herramientas puntuales que su equipo puede usar detrás de acceso controlado.

• Cada URL de despliegue de Sites es producción. La documentación de OpenAI indica a los equipos que primero guarden una versión si quieren revisar antes de un despliegue live.

• Las aplicaciones web a medida siguen ganando cuando la app es el negocio. Usuarios externos, datos privados, permisos profundos, integraciones API directas y propiedad a largo plazo sacan el trabajo de Sites.

• El error de compra es llamar plataforma a un prototipo. Cubrimos el mismo fallo en MVPs vibe-coded que se convierten en deuda técnica.

• webvise construye aplicaciones full-stack desde 7.500 € en 4 a 10 semanas cuando el trabajo necesita código fuente, arquitectura, monitoring y traspaso en lugar de una app temporal de workspace.

Qué entrega realmente Codex Sites

OpenAI anunció Codex Sites el 2 de junio de 2026, junto con role plugins y annotations para revisión compartida. El anuncio dice que Codex tiene más de 5 millones de usuarios semanales, con uso por no desarrolladores creciendo 3x en el mes anterior y superando el 20 por ciento del uso.

La afirmación de producto es útil porque nombra la audiencia. Codex ya no es solo una superficie de coding para desarrolladores. Es una herramienta de workspace para personas que tienen un plan, una hoja de cálculo, un proceso o una idea de producto aproximada y quieren algo interactivo.

La documentación de Codex Sites de OpenAI describe un workflow alojado donde Codex puede crear, guardar, desplegar e inspeccionar sitios web, aplicaciones web y juegos. Los proyectos Sites pueden usar D1 para datos relacionales, R2 para almacenamiento de archivos, identidad autenticada del workspace y modos de acceso configurables.

El detalle importante se pasa por alto con facilidad: cada URL de despliegue de Sites es un despliegue de producción. Si quiere revisar antes de que esté live, la documentación dice que guarde una versión sin desplegarla.

La línea de decisión es audiencia y propiedad

La primera pregunta no es si Codex puede construir la interfaz. A menudo puede llegar lo bastante lejos. La primera pregunta es quién depende del resultado una vez que existe la URL.

Si la audiencia es su equipo interno, el acceso está limitado al workspace y un fallo solo retrasa una decisión, Sites encaja bien. Si la audiencia son clientes, partners, auditores o usuarios de pago, la superficie tiene otro perfil de riesgo. La app necesita arquitectura, rutas de soporte, observabilidad y control de cambios.

La propiedad es la segunda línea. Una herramienta temporal de planificación puede vivir dentro de un workspace alojado. Un producto central debería vivir en código fuente que usted controle, con infraestructura que su equipo o agencia pueda inspeccionar, probar y mover.

Si su respuesta cae tres veces en la columna derecha, trate Sites como herramienta de descubrimiento, no como ruta de producción. Ahí encaja el servicio de aplicaciones full-stack de webvise: Next.js, PostgreSQL, Better Auth, tRPC, Drizzle, despliegue, monitoring y traspaso como una base de código propia.

Dónde gana Codex Sites

Sites gana cuando el coste de no ver el workflow es mayor que el coste de una primera versión aproximada. Un equipo puede pedir un dashboard, una app de planificación, una simulación o un hub de revisión y compartir el resultado con una audiencia controlada.

Una historia real del lanzamiento es el cambio en quién puede empezar. El 2026-06-02, OpenAI presentó Codex para cada rol, no solo para desarrolladores. Eso importa porque muchas apps internas útiles nunca empiezan como tickets. Empiezan como modelo financiero, plan de lanzamiento o hoja de operaciones desordenada.

La solicitud correcta para Sites es estrecha: convierta este plan en una herramienta interna funcional que nuestro equipo pueda inspeccionar hoy. La solicitud equivocada es amplia: construya la plataforma de la que nuestros clientes dependerán durante los próximos tres años.

• Planificador interno de lanzamiento. Convierta una checklist de lanzamiento en un tablero de estado con responsables, fechas y bloqueos.

• Sandbox de previsión. Convierta un modelo de hoja de cálculo en sliders, tablas y escenarios guardados para una revisión de dirección.

• Juego de formación. Construya un pequeño ejercicio interactivo para un taller interno sin encargar un producto completo.

• Prototipo de workflow. Deje que operaciones haga clic por el proceso antes de que alguien discuta sobre campos en una especificación.

• Dashboard temporal. Lleve un conjunto limitado de datos a una superficie de revisión para una reunión semanal.

Estas apps son valiosas. También están acotadas. En cuanto se convierten en el record of truth, la decisión cambia.

Dónde siguen ganando las aplicaciones web a medida

Las aplicaciones web a medida ganan cuando el software pasa a ser parte del modelo operativo. La app necesita auth que usted pueda razonar, un modelo de datos que su equipo posea, integraciones que no dependan de un prompt y gestión de errores que funcione cuando nadie está mirando.

En webvise, la base full-stack empieza en 7.500 € y suele tomar 4 a 10 semanas para aplicaciones de producción. Ese presupuesto compra cosas que una demo por prompt omite: arquitectura de base de datos, contratos API, permisos basados en roles, CI/CD, monitoring y una ruta de traspaso.

webvise.io es la prueba interna del modelo, sin depender de una prueba de proyecto externa. El sitio no es un folleto. Es un monorepo Next.js 16 con tRPC, Drizzle, PostgreSQL, Better Auth, AI SDK 6 mediante Vercel AI Gateway, siete locales, 93 slugs de blog, 651 archivos JSON localizados, seis páginas de servicio, una herramienta WordPress Health Report y un AI assistant.

La lección no es que cada sitio empresarial necesite tanta maquinaria. La lección es que la velocidad de construcción asistida por AI funciona mejor dentro de una arquitectura definida. La arquitectura mantiene útil el código después de la primera demo.

Para la economía más amplia, lea Build vs Buy Software in 2026. El mismo punto de cruce aplica aquí: alquile o genere la superficie temporal, construya el workflow que compone valor.

La tabla de decisión de 2026

La mayoría de equipos tiene ahora cuatro caminos, no dos. La elección correcta depende de audiencia, riesgo de datos, vida útil y propiedad.

La tabla está sesgada a propósito contra construir de más. Si el trabajo es temporal, use Sites. Si el workflow es estable pero genérico, use no-code. Si el producto debe convertirse en un activo empresarial propio, constrúyalo correctamente.

Eso no es anti-AI. Es la versión práctica de la entrega asistida por AI. Use AI para acortar el camino hacia software funcional, luego use criterio de ingeniería para decidir qué software funcional merece una base de código real.

Una checklist de 20 minutos antes de construir

Antes de pedir a Codex, a un app builder o a una agencia que empiece, responda estas preguntas por escrito. Las respuestas deciden el camino más rápido que otra demo de herramienta.

• Audiencia: ¿El acceso está limitado a empleados en un workspace, o lo usarán clientes, partners o contratistas?

• Datos: ¿Almacena PII, pagos, contratos, archivos, analytics privados o registros operativos?

• Vida útil: ¿A alguien le importará esta app dentro de 90 días?

• Fallo: ¿Qué pasa si la app está equivocada, no disponible o desactualizada durante un día laboral?

• Integraciones: ¿Necesita acceso directo a su CRM, ERP, base de datos, procesador de pagos o API interna?

• Permisos: ¿Hay más de dos roles, o un usuario necesita ver registros que otro usuario no puede ver?

• Propiedad: ¿Necesita el código fuente en su repositorio, con tests, docs y una ruta de traspaso?

Sume un punto por cada sí fuera de la primera pregunta. Cero a dos puntos significa: pruebe primero Codex Sites o no-code. Tres o cuatro puntos significa: prototipe con Sites y luego defina el build. Cinco o más significa: la app ya está en territorio de aplicación web a medida.

webvise construye los proyectos de la columna derecha: aplicaciones full-stack propias con código fuente, auth, integraciones, monitoring y una ruta de despliegue que su equipo puede seguir usando. Si está decidiendo si Codex Sites basta o si el proyecto necesita un build a medida, envíenos las respuestas de la checklist y le diremos qué camino tomaríamos.