Crear una aplicación web completa ya no tiene por qué sentirse como una montaña técnica. Hoy puedes pasar de una idea simple a una app funcional con frontend, backend, base de datos, autenticación, panel administrativo y despliegue real, todo con un flujo mucho más directo.
Para demostrarlo, armé una app de reservas para una barbería. El objetivo fue construir algo pequeño, claro y útil, pero que al mismo tiempo incluyera casi todas las piezas que normalmente aparecen en una app real.
La app permite que una persona reserve una hora en la barbería y que el negocio luego gestione esa reserva desde un panel privado para confirmarla o cancelarla. Ese ejemplo sirve muy bien porque combina interfaz pública, persistencia de datos, lógica de negocio y administración.
Además del desarrollo, también recorrí dos partes que muchos tutoriales se saltan: cómo publicar la aplicación y cómo probarla de verdad antes de darla por terminada.
Tabla de contenido
- 🧠 La idea del proyecto: una app sencilla, pero completa
- ✍️ El prompt inicial importa más de lo que parece
- 🔌 Conectar Supabase desde Codex
- 🏗️ Lo que Codex construye cuando le das el contexto correcto
- 🗣️ Cómo ajustar el trabajo sin cortar la ejecución
- 📱 Revisar la interfaz desde el principio
- 🗄️ Confirmar si Supabase quedó realmente conectado
- 🧪 Probar el flujo público con una reserva real
- ✅ Verificar los datos directamente en Supabase
- 🔐 Crear el usuario administrador para el panel privado
- 🧾 El panel admin y la lógica de confirmación
- 🚀 Publicar la app sin complicarte la vida
- 📦 Preparar el proyecto para GitHub
- 🌐 Desplegar en Hostinger
- 🔁 Lo mejor del flujo: cambio, push y deploy automático
- 🎨 Mejorar el diseño con una sección hero generada por IA
- 🧪 Probar la app publicada con TestSprite CLI
- 🧰 Qué se validó con las pruebas
- 🧭 Qué hace tan potente este flujo completo
- 💡 Algunas lecciones prácticas que vale la pena quedarse
- 🌍 De proyecto de ejemplo a app con valor real
- 🤝 Recursos útiles para replicar este flujo
- 🏁 Cerrar el círculo: construir, publicar y validar
🧠 La idea del proyecto: una app sencilla, pero completa
El proyecto parte con una decisión importante: elegir algo suficientemente simple para entenderlo rápido, pero suficientemente realista para que el flujo completo valga la pena. Por eso la app de reservas de barbería funciona tan bien como ejemplo.
No es solo un formulario bonito. Tiene varias piezas clave:
- Una interfaz pública para reservar hora.
- Una base de datos para guardar las reservas.
- Un backend real.
- Autenticación para separar el acceso público del acceso administrativo.
- Un panel interno para revisar y actualizar el estado de cada reserva.
- Diseño responsivo para celular, tablet y escritorio.
Ese conjunto ya te da una mini app de negocio, no solo una demo visual.
La base del trabajo ocurre dentro de un proyecto en Codex. En la práctica, un proyecto aquí no es más que una carpeta de trabajo. Todo lo que se genera queda en ese directorio, así que desde el principio conviene tener claro dónde vas a construir.
✍️ El prompt inicial importa más de lo que parece
Una de las formas más rápidas de avanzar con Codex es arrancar con un prompt bien planteado. En este caso no hizo falta un documento gigante ni una especificación eterna. Bastó con describir con claridad el objetivo principal: una aplicación web de reservas para una barbería, con flujo público para pedir hora y lógica administrativa para confirmar o cancelar solicitudes.
Ese tipo de prompt ya le da a la IA una estructura bastante útil:
- qué problema debe resolver,
- qué tipo de usuarios existen,
- qué acciones principales deben estar disponibles,
- y qué tecnología se quiere usar.
Si quieres profundizar en cómo escribir mejores prompts para apps, tiene sentido revisar la guía de creación de prompts para tu app, que va más al detalle sobre cómo pedir funcionalidades de forma más profesional.
También está disponible el prompt usado en este ejemplo, que sirve como base si quieres replicar un flujo parecido.
🔌 Conectar Supabase desde Codex
Una vez definida la app, el siguiente paso natural es conectar el backend. Para eso usé Codex junto con Supabase.
Supabase cumple un rol central aquí porque resuelve varias necesidades a la vez:
- base de datos,
- autenticación,
- estructura backend lista para usar.
La conexión se hace desde los complementos disponibles en Codex. En vez de configurar todo a mano desde cero, puedes instalar el plugin de Supabase y autorizar el acceso con tu cuenta. Eso simplifica muchísimo el arranque, porque le permite al agente trabajar con contexto real del proyecto.
Después de autorizar, ya puedes invocar Supabase directamente dentro del flujo de trabajo. Ese detalle cambia bastante la experiencia, porque Codex deja de ser solo alguien que genera archivos y pasa a operar conectado a servicios reales.
Si todavía no tienes cuenta en Supabase, puedes crear una gratis y comenzar sin costo. Para proyectos de prueba y primeras apps, es más que suficiente.
🏗️ Lo que Codex construye cuando le das el contexto correcto
Con el prompt listo y Supabase conectado, Codex puede empezar a armar la aplicación.
En este ejemplo, el agente entiende que hay dos frentes que deben quedar bien resueltos:
- el flujo visual de reservas,
- y las reglas de seguridad del lado del backend.
Eso es importante porque una app no queda bien hecha solo por verse linda. También necesita que el acceso a los datos y las acciones sensibles estén protegidos.
Mientras trabaja, Codex puede ir tomando decisiones técnicas razonables para unir esas piezas: formularios, tablas de base de datos, autenticación y estructura de interfaz.
Y aquí aparece una función muy útil: puedes seguir dirigiendo al agente sin interrumpir lo que está haciendo.
🗣️ Cómo ajustar el trabajo sin cortar la ejecución
Hay un detalle muy práctico en Codex que vale oro cuando estás construyendo interfaces: puedes darle instrucciones adicionales mientras sigue trabajando.
Por ejemplo, algo tan simple como pedir que no use ciertos colores. En este caso, una indicación fue evitar morados o púrpuras, porque muchas veces los modelos tienden a irse hacia esa paleta visual por defecto.
La gracia está en que no hace falta cancelar el proceso ni empezar de nuevo. Puedes redirigirlo y dejar que incorpore ese ajuste dentro de la ejecución actual.
Ese flujo se siente mucho más natural. En vez de esperar a que termine todo para recién corregir, puedes ir afinando el resultado sobre la marcha.
📱 Revisar la interfaz desde el principio
En cuanto la primera versión estuvo lista, lo siguiente fue abrir la app en el navegador interno y revisar cómo se comportaba en distintos tamaños de pantalla.
Eso conviene hacerlo temprano, no al final. Si la app ya nace con una estructura responsiva razonable, te ahorras una buena cantidad de ajustes posteriores.
La app de barbería quedó adaptándose bien a móvil, tablet y escritorio. No era solo una maqueta estática. Ya se podía navegar, interactuar con el formulario y ver un panel con secciones administrativas.
Eso ayuda mucho porque te permite validar rápido si el diseño general tiene sentido antes de meterte a revisar datos o seguridad.
🗄️ Confirmar si Supabase quedó realmente conectado
Un punto muy importante cuando trabajas con IA es no asumir nada. Aunque la interfaz se vea lista, eso no significa automáticamente que el backend esté conectado de verdad.
Por eso lo correcto fue preguntarle directamente a Codex si aún faltaba configuración en Supabase o si ya estaba todo operativo.
La respuesta fue clara: el código estaba preparado, pero todavía faltaba terminar la conexión real. Ese tipo de verificación evita que te engañe una app que parece funcional pero todavía está usando lógica incompleta.
Después se resolvió la parte pendiente y quedó habilitado el vínculo real con la base de datos.
🧪 Probar el flujo público con una reserva real
Con Supabase ya enlazado, llegó el momento de hacer la prueba más obvia: crear una reserva como si fuera un cliente real.
Se completaron campos típicos:
- nombre,
- teléfono,
- correo,
- tipo de corte,
- fecha,
- hora.
Al enviar el formulario, la app respondió correctamente indicando que la reserva había sido recibida y quedaba pendiente de confirmación.
Eso ya es una buena señal, pero todavía faltaba la comprobación real: verificar si el dato terminó guardado en la base de datos.
✅ Verificar los datos directamente en Supabase
Este paso es clave. Si quieres trabajar de manera seria con herramientas de IA, tienes que mirar también el otro lado del sistema.
Después de enviar la reserva, se abrió Supabase para revisar el proyecto creado y entrar a la tabla correspondiente. Ahí apareció exactamente lo que debía aparecer: una fila nueva con la reserva recién enviada.
Ese momento es importante porque confirma varias cosas al mismo tiempo:
- el formulario funciona,
- la app está conectada al backend real,
- la base de datos está recibiendo y almacenando la información.
En otras palabras, ya no estás frente a una demo vacía. Tienes una app operativa.
🔐 Crear el usuario administrador para el panel privado
Como la app también necesitaba gestión interna, faltaba crear el acceso administrativo.
Ese usuario puede crearse manualmente desde el dashboard de Supabase, pero también se le puede pedir al agente que lo haga. Para eso basta con indicarle el correo y la contraseña que quieres usar.
Aquí hay una recomendación obvia pero necesaria: para una demo puedes usar datos inventados, pero para cualquier uso real debes elegir credenciales seguras y, si es posible, usar un correo verdadero para completar correctamente el flujo de autenticación.
Una vez creado ese usuario, quedó habilitado el ingreso al panel admin de la app.
🧾 El panel admin y la lógica de confirmación
Con el acceso administrativo disponible, ya se pudo entrar al panel interno y revisar la reserva creada anteriormente.
Desde ahí, la app permitía cambiar el estado de la solicitud. Por ejemplo:
- recibida,
- confirmada,
- cancelada.
Se hizo la prueba cambiando el estado a confirmado, y luego se comprobó que ese cambio quedaba reflejado correctamente.
Ese es otro hito importante. Ya no solo existe creación de datos, sino también actualización con lógica administrativa. Eso convierte la app en una herramienta realmente usable para un negocio.
Además, la estructura visual quedó bastante limpia: formulario al lado izquierdo, panel de acceso personal al lado derecho, servicios listados abajo y área administrativa más abajo. Todo con una estética sobria y bastante adecuada para una barbería.
🚀 Publicar la app sin complicarte la vida
Muchísima gente se queda a mitad de camino justo aquí. Construyen una app funcional, la prueban localmente, todo se ve bien, pero nunca terminan aprendiendo a publicarla.
Por eso este paso no se puede omitir.
La forma recomendada fue preparar primero el proyecto para GitHub y luego usar un hosting conectado al repositorio. Ese flujo tiene varias ventajas sobre subir archivos manualmente:
- mantienes control de versiones,
- los cambios quedan registrados,
- puedes volver atrás si rompes algo,
- no dependes de una sola copia local en tu máquina,
- y el despliegue posterior se vuelve casi automático.
📦 Preparar el proyecto para GitHub
Para esta parte conviene instalar también el complemento de GitHub dentro de Codex. Así el agente puede ayudarte a dejar el proyecto listo para versionarlo y publicarlo.
La instrucción fue simple: preparar el proyecto para subirlo a GitHub y luego publicarlo en hosting. Con eso, Codex dejó la estructura acomodada para ese siguiente paso.
Idealmente, incluso el propio agente podría encargarse de crear el repo y empujar el código, aunque a veces puede faltar alguna configuración local o remota. Cuando eso pasa, no es drama. Se puede completar manualmente en GitHub en un par de minutos.
La secuencia es muy simple:
- crear un repositorio nuevo,
- ponerle un nombre coherente,
- copiar la URL remota,
- entregársela al agente para que termine la conexión.
Una vez hecho eso, el código queda subido y disponible con toda su estructura.
Además, esto tiene otra ventaja: el proyecto ya queda documentado. Si en algún momento trabajas con otras personas, GitHub se vuelve la base de colaboración natural.
🌐 Desplegar en Hostinger
Con el repositorio listo, el siguiente paso es conectarlo a un hosting. Aquí usé Hostinger, porque permite enlazar fácilmente una app Node.js con un repositorio y dejar configurado el flujo de despliegue.
La diferencia entre importar un proyecto estático y conectar el repo directamente es enorme.
Si subes un build manual, cada cambio futuro implica recompilar y volver a subir todo. En cambio, cuando conectas GitHub al hosting:
- cambias el código,
- haces push,
- y el hosting despliega la nueva versión automáticamente.
Ese flujo es mucho más moderno y sostenible.
En Hostinger, bastó con elegir la opción para app web Node.js, usar un dominio temporal y seleccionar el repositorio creado. Después de la compilación e implementación, la aplicación quedó publicada y accesible desde un enlace real.
Si luego quieres llevar esto a algo más profesional, puedes conectar un dominio propio desde el panel. Si te interesa ese camino, el enlace de Hostinger con descuento es el mismo que se usó como referencia para este flujo.
🔁 Lo mejor del flujo: cambio, push y deploy automático
Aquí es donde realmente empieza a sentirse poderosa la combinación de Codex, GitHub y hosting conectado.
Una vez que ya tienes ese flujo armado, hacer cambios deja de ser una pesadilla. Puedes pedirle a Codex una mejora visual, dejar que modifique el proyecto, mandarlo a GitHub y esperar a que el hosting vuelva a desplegar solo.
Eso fue exactamente lo que pasó con la mejora siguiente: agregar una sección principal más atractiva para la barbería.
🎨 Mejorar el diseño con una sección hero generada por IA
Después de tener la app funcional, quise darle más presencia visual. La instrucción fue agregar una primera sección con imagen atractiva y un texto breve alineado con la identidad de la barbería.
Codex entendió la intención, generó imágenes con su integración de modelo de imágenes y las incorporó al diseño.
Este punto es especialmente interesante porque muestra que la IA no solo puede escribir lógica o formularios. También puede ayudarte a crear recursos visuales e integrarlos directamente en la interfaz.
Y hubo otro detalle muy bueno: al generar una imagen pesada, el sistema detectó que el archivo era demasiado grande y lo optimizó, comprimiéndolo y pasándolo a un formato más eficiente. Eso mejora el rendimiento sin que tengas que andar pensando en cada detalle técnico.
Al terminar, bastó con pedir que los cambios se enviaran a GitHub. El hosting detectó la nueva versión, hizo el despliegue y al refrescar la página ya aparecía la nueva portada de la barbería publicada en línea.
🧪 Probar la app publicada con TestSprite CLI
Ahora viene una parte que demasiadas veces se ignora: las pruebas reales.
Una app que parece funcionar puede fallar en validaciones, romperse en flujos secundarios o comportarse mal con ciertos estados. Por eso quise hacer una ronda de testing después del despliegue.
Para eso usé TestSprite, una herramienta muy útil para validar aplicaciones con enfoque práctico. En este caso, lo interesante fue usar su CLI, porque encaja muy bien con el flujo de agentes y acelera bastante la ejecución de pruebas.
La idea fue probar la app publicada como si una persona real estuviera interactuando con ella, pero aprovechando al mismo tiempo la capacidad del agente para entender el contexto del proyecto.
🧰 Qué se validó con las pruebas
La instrucción a TestSprite fue bastante directa: revisar todos los flujos principales de la app publicada.
Entre los casos importantes estaban:
- carga inicial de la página,
- creación de una reserva,
- validación de campos obligatorios,
- revisión del panel administrativo,
- actualización del estado de una reserva.
Esto es muy valioso porque los errores más molestos muchas veces aparecen en casos borde. A veces el flujo principal funciona perfecto, pero una validación incompleta o una transición mal manejada rompe la experiencia.
Herramientas como TestSprite ayudan a descubrir ese tipo de detalles antes de entregar una app o mostrársela a un cliente.
Si quieres explorarla por tu cuenta, aquí está el acceso a TestSprite. También puedes pasar por su comunidad de Discord para ver ejemplos, novedades y resolver dudas, y revisar su hackathon Season 3 si te interesa experimentar construyendo y probando con este tipo de herramientas.
🧭 Qué hace tan potente este flujo completo
Más allá de la app concreta de barbería, lo interesante aquí es el patrón de trabajo.
El flujo completo quedó así:
- definir una idea clara,
- describirla con un prompt útil,
- conectar servicios reales como Supabase,
- generar la app con Codex,
- verificar datos y autenticación,
- subir el código a GitHub,
- publicar en hosting,
- probar la app ya desplegada,
- hacer mejoras y redeploy automático.
Ese proceso ya es perfectamente aplicable a muchos otros casos:
- agendamiento para profesionales,
- formularios de captura para negocios locales,
- microsistemas internos,
- paneles administrativos simples,
- prototipos funcionales para clientes.
La enseñanza importante no es solo que una barbería pueda tener su agenda online. La enseñanza es que hoy puedes construir una solución web bastante completa sin meterte durante semanas en configuraciones manuales.
💡 Algunas lecciones prácticas que vale la pena quedarse
De todo este proceso, hay varias conclusiones que realmente ayudan:
- Empieza con algo acotado. Una app pequeña pero completa enseña más que una idea gigante a medio hacer.
- Verifica siempre el backend. Que algo se vea bien no significa que guarde datos reales.
- Usa plugins y conexiones reales. Ahorran muchísimo tiempo y le dan contexto útil al agente.
- No te saltes GitHub. El control de versiones deja de ser opcional en cuanto haces más de un cambio.
- Automatiza el despliegue. Publicar a mano cada vez se vuelve una pérdida de tiempo muy rápido.
- Prueba la app después de publicarla. El entorno real siempre te puede mostrar algo que en local no viste.
- Ajusta el diseño durante el proceso. No hace falta esperar al final para mejorar la estética.
🌍 De proyecto de ejemplo a app con valor real
Lo bonito de este ejemplo es que no se quedó en teoría. Terminó con una aplicación funcional, una base de datos real, un panel admin operativo, despliegue en línea y pruebas de flujos esenciales.
Eso ya es suficiente para mostrarle a un negocio una propuesta concreta. Y también es una base excelente para seguir iterando.
Podrías extenderla con:
- recordatorios por correo,
- bloques de horarios ocupados,
- múltiples barberos,
- pagos en línea,
- historial de clientes,
- gestión de servicios y precios.
Pero lo más importante es que ya tienes el esqueleto correcto para crecer.
🤝 Recursos útiles para replicar este flujo
Si quieres repetir este proceso o adaptarlo a tu propia idea, estos enlaces sí tienen sentido porque corresponden exactamente a las herramientas y recursos usados durante el recorrido:
- Codex para construir y modificar la app.
- TestSprite para testing y validación de flujos.
- Discord de TestSprite para comunidad y soporte.
- Hackathon de TestSprite si quieres explorar desafíos y premios.
- Hostinger para despliegue y publicación.
- Primera App para aprender a escribir mejores prompts de producto.
- Comunidad de Vibe Coding para seguir aprendiendo y construir con IA.
- Prompt de ejemplo usado para esta app.
🏁 Cerrar el círculo: construir, publicar y validar
La gran diferencia entre una idea interesante y una app útil está en cerrar el ciclo completo. No basta con generar pantallas. Hay que conectar datos, proteger accesos, publicar y comprobar que todo responda bien.
Eso fue exactamente lo que se logró con esta app web de reservas para barbería.
Y ese es, probablemente, el mejor mensaje de todo el proceso: hoy puedes apoyarte en IA para construir mucho más rápido, pero la clave sigue siendo trabajar con método. Pedir bien, revisar bien, publicar bien y probar bien.
Si haces eso, una idea pequeña puede convertirse muy rápido en un producto funcional de verdad.
