Una web para un cliente no está terminada cuando se ve bien. Está terminada cuando el negocio puede usarla, recibir consultas y mantener al día la información que cambia con el tiempo. Si cada nuevo proyecto, testimonio o cambio de horario requiere llamar a quien creó la página, hemos entregado una web bonita, pero no una herramienta cómoda para trabajar.
Mi método consiste en separar dos cosas: el diseño, que preparo a medida, y el contenido que el cliente necesita administrar. Para mostrar el proceso completo voy a crear una web para una empresa ficticia de construcción y reformas. Empezaré con Antigravity y Astro, añadiré un panel conectado a Supabase, comprobaré que las consultas lleguen y publicaré el proyecto en Hostinger mediante GitHub.
No voy a dedicar horas a perfeccionar cada detalle visual. Aquí lo importante es recorrer el camino desde el primer prompt hasta una web publicada con un administrador sencillo y útil. El diseño siempre se puede seguir trabajando después.
Tabla de contenido
- 🧱 Primero, decidir qué debe poder editar el cliente
- 🤖 Crear la primera versión con Antigravity y Astro
- 🗂️ Un panel personalizado, sin convertir la web en un editor de diseño
- 🔌 Conectar Supabase mediante MCP
- 🔐 Crear el acceso y recorrer el administrador
- ➕ Mejorar proyectos con altas, desactivación y paginación
- 🚀 Preparar la publicación con GitHub y Hostinger
- 🧪 Una web publicada puede cargar y aun así no estar terminada
- ✅ El método completo, resumido en decisiones prácticas
- 🛠️ Recursos para seguir creando
🧱 Primero, decidir qué debe poder editar el cliente
Antes de abrir una herramienta de inteligencia artificial, conviene pensar en el uso real de la web. Una constructora puede necesitar actualizar sus servicios, mostrar nuevas obras, incorporar experiencias de clientes, corregir sus datos de contacto y revisar solicitudes de presupuesto. Nada de eso exige que pueda cambiar la estructura de la página o rediseñar la sección principal.
Esta distinción evita un error bastante común: pedir un administrador capaz de modificarlo todo. Suena flexible, pero añade complejidad donde no hace falta. Si el cliente solo necesita cambiar textos y registros concretos, prefiero darle controles claros para esas tareas. Así el panel es más fácil de entender y la identidad visual del sitio se mantiene consistente.
Para este proyecto, el alcance editable queda bastante definido:
- Servicios: los textos que explican qué trabajos ofrece la empresa.
- Proyectos: las obras que aparecen en el sitio, con la posibilidad de agregar otras.
- Testimonios: las experiencias que la empresa quiera mostrar.
- Datos del negocio: información de contacto y horarios.
- Consultas: los mensajes enviados desde el formulario para pedir presupuesto.
La regla práctica es sencilla: si una información puede cambiar durante la operación normal del negocio, vale la pena evaluar si debe estar en el panel. Si se trata de una decisión de diseño, no necesariamente necesita ser editable por el cliente.
🤖 Crear la primera versión con Antigravity y Astro
Uso Antigravity porque permite comenzar gratis y su versión gratuita resulta bastante generosa para trabajar en un proyecto como este. El método no depende de una sola herramienta: también podría hacerse con otro agente de programación. Lo que importa es darle instrucciones claras y revisar el resultado, no asumir que el primer intento será definitivo.
Después de instalar Antigravity, creo un proyecto nuevo en una carpeta nueva. En este caso la llamo «web constructora». Todo lo que el agente genere quedará guardado allí. Parece un paso menor, pero mantener cada trabajo en su propia carpeta ayuda a saber qué archivos pertenecen a cada cliente.
Para el primer prompt ya había ordenado un poco las ideas con ChatGPT. Le pido a Antigravity que construya una web para la empresa ficticia de construcción y reformas usando Astro, con las páginas y secciones esperables en una web de negocio. También especifico algo importante: todavía no debe conectar el backend. Sé que después usaré Supabase, pero prefiero resolver primero la base visual y funcional del sitio.
Cuando pido un framework, suelo indicar que se use su versión estable más reciente y que se instalen las dependencias necesarias. Es una forma simple de orientar la configuración inicial. También elijo el mejor modelo al que tengo acceso en ese momento, porque estas herramientas y sus modelos cambian con rapidez.
En la primera pasada, Antigravity instala Astro y genera la web. Ya hay imágenes, contenido, páginas internas, formulario, preguntas frecuentes y una integración visible con WhatsApp. Es un buen punto de partida. Pero que algo esté completo no significa que esté resuelto: la página se siente demasiado cargada de texto y la imagen principal queda oscurecida por una capa muy intensa.
Corregir con instrucciones concretas, no con «hazlo mejor»
En lugar de reiniciar el proyecto, le pido ajustes precisos. Quiero que se vea más la imagen de la casa en la sección principal, que el texto sea más conciso y que la página conserve su intención comercial. La idea no es quitar información por quitarla. Es permitir que una persona entienda rápidamente qué ofrece la empresa y encuentre cómo contactar.
La siguiente versión ya respira mejor, aunque sigue viéndose algo oscura. Hago otra petición concreta: un azul menos apagado, un amarillo más intenso, algunas secciones con fondo blanco y más espacio entre elementos. Antigravity cambia la cabecera y alterna zonas claras con otras oscuras. El resultado se siente más vivo y es más fácil recorrerlo.
Este es el tipo de revisión que recomiendo hacer siempre. No hay que pedir un diseño perfecto en un único prompt. Es mucho más práctico obtener una primera versión, identificar dos o tres problemas visibles y corregirlos con indicaciones específicas. En este caso, con unas pocas pasadas ya tengo una base con la que puedo avanzar al trabajo que más me interesa: el administrador de contenidos.
🗂️ Un panel personalizado, sin convertir la web en un editor de diseño
Con la apariencia general encaminada, le pido a Antigravity que integre Supabase como base de datos y como sistema de autenticación para el área de administración. La instrucción central es crear un panel simple para gestionar servicios, testimonios, proyectos, datos del negocio y consultas del formulario.
También aclaro el límite: no quiero un sistema para cambiar cada parte del diseño. Quiero que el cliente pueda mantener actualizadas las secciones donde editar contenido tiene sentido. Esta precisión importa tanto como la lista de funciones. Si solo enumeramos posibilidades, un agente puede construir más de lo que necesitamos y complicar una herramienta que debería ser sencilla.
Un panel de este tipo aporta valor porque traduce necesidades del negocio en tareas reconocibles. En vez de pedirle al cliente que busque archivos o identifique componentes, le damos opciones como «Servicios» o «Datos del negocio». El cliente piensa en su empresa; el sistema debería hablarle en esos términos.
🔌 Conectar Supabase mediante MCP
Para que Antigravity trabaje con Supabase, instalo su integración MCP desde la propia herramienta. MCP sirve como vía de conexión entre el agente y el servicio. En este caso permite que el agente realice directamente parte de la configuración que, de otro modo, tendría que preparar manualmente.
La instalación, sin embargo, no termina el trabajo. Al principio el agente no consigue usar la conexión. Reviso la configuración y encuentro el problema: todavía no había autenticado mi cuenta de Supabase. Tras autorizarla y completar el enlace, la integración queda disponible.
Me parece importante mostrar también estos tropiezos. Cuando una herramienta «no encuentra» un servicio, no siempre significa que el prompt esté mal o que haya que rehacer el proyecto. A veces falta una autorización, una conexión no ha quedado activa o la aplicación necesita volver a abrirse. Antes de cambiar toda la implementación, reviso esos pasos básicos.
Una vez conectada la cuenta, Antigravity puede seguir con la integración. Eso reduce bastante la cantidad de configuración que tengo que hacer por mi cuenta. No elimina la necesidad de comprobar el resultado, pero sí acelera el camino entre pedir el panel y tenerlo funcionando.
🔐 Crear el acceso y recorrer el administrador
Cuando el agente termina la primera versión del panel, abro el sitio y creo el usuario administrador. Después entro en la sección de gestión para comprobar qué construyó realmente. El panel reúne las áreas que habíamos pedido: leads o consultas, servicios, proyectos, testimonios y datos del negocio.
La organización es deliberadamente simple. En servicios puedo revisar y editar la información ofrecida. En proyectos aparecen las obras y sus textos. Los testimonios tienen su propia sección. En datos del negocio encuentro información de contacto y horarios. No necesito una interfaz enorme para que esto sea útil; necesito que las tareas habituales estén a mano.
También reviso si el panel permite algo más que corregir registros existentes. Una constructora seguirá terminando obras y necesitará mostrarlas. Si solo puede editar los seis proyectos iniciales, el administrador se quedará corto muy pronto. Es una buena demostración de por qué conviene recorrer cada sección como lo haría el cliente, en lugar de dar por buena una lista de funciones generada por la IA.
Probar el formulario de principio a fin
Una web comercial necesita recibir consultas. Por eso hago una prueba sencilla: voy al formulario de solicitud de presupuesto, introduzco datos de prueba, acepto las condiciones que muestra y envío la consulta. El sitio confirma que se ha recibido.
Pero esa confirmación no basta. Vuelvo al panel y compruebo que la consulta aparece registrada en la sección correspondiente. Ahí está la prueba que importa: la información salió del formulario público y llegó al lugar donde el negocio podrá gestionarla.
Cuando trabajo con IA, intento verificar los recorridos completos. Una página puede mostrar un botón y un formulario impecables, pero eso no garantiza que el dato llegue al administrador. La prueba de envío evita entregar una función que solo parece funcionar.
➕ Mejorar proyectos con altas, desactivación y paginación
La primera versión permite editar proyectos, pero quiero que el cliente también pueda agregar nuevos. Le doy una instrucción adicional a Antigravity: permitir crear proyectos, editar los existentes y marcarlos como no activos para retirarlos de la lista pública.
La opción de desactivar es especialmente práctica. No siempre queremos borrar una obra del sistema para que deje de aparecer en la web. Tal vez convenga conservar sus datos y decidir más adelante si vuelve a mostrarse. Por eso distingo entre mantener el registro en el administrador y publicarlo en el sitio.
También pido paginación cuando el número de proyectos supere los seis que se muestran inicialmente. Si la empresa continúa agregando trabajos, no quiero que la página se convierta en una lista interminable. La paginación ayuda a mantener ordenada la presentación sin limitar la cantidad de obras que el cliente puede registrar.
Después reviso la página pública de proyectos para ver el resultado. Aparecen las tarjetas de obras y la navegación entre grupos de proyectos. Esta comprobación completa la anterior: no basta con tener un botón «Nuevo proyecto» en el panel; la web pública también debe presentar correctamente el contenido administrado.
Esta es una forma muy cómoda de avanzar con un agente: pedir una primera solución, usarla, detectar una necesidad concreta y solicitar una mejora acotada. No hace falta intentar prever todas las funciones antes de tener algo entre manos.
🚀 Preparar la publicación con GitHub y Hostinger
Con el panel y el formulario probados, preparo la publicación para disponer de un enlace que pueda compartir con el cliente. En Hostinger creo una aplicación web de Node.js para alojar el proyecto hecho con Astro y selecciono un dominio temporal. Para este ejemplo es suficiente: primero quiero verificar que la web cargue fuera de mi máquina.
Hostinger ofrece la posibilidad de subir archivos directamente, pero prefiero conectar un repositorio de GitHub. Si mañana tengo que cambiar un texto, ajustar una página o mejorar una función, mantener el proyecto en un repositorio evita depender de volver a subir manualmente todos los archivos. Es un flujo más cómodo para seguir trabajando.
Le pido a Antigravity que prepare el proyecto para GitHub. El agente inicializa Git en la rama principal y ofrece crear el repositorio en mi cuenta y subir el código. Acepto. Luego vuelvo a Hostinger, elijo importar desde GitHub y selecciono el repositorio recién creado.
Durante la conexión aparece un pequeño problema con la autorización de Hostinger. Lo soluciono eliminando esa conexión y creándola de nuevo. Tras autorizar el acceso, puedo seleccionar el repositorio. Hostinger reconoce el proyecto como Astro y muestra la configuración de implementación, incluida la versión de Node.js y el directorio raíz. En este caso dejo los valores detectados por defecto.
Si estás siguiendo un proceso parecido y quieres usar el mismo proveedor, aquí está mi enlace de Hostinger. Lo relevante para este método no es solo dónde alojamos la página, sino comprobar que la aplicación compila y después configurar correctamente lo que necesita para conectarse a Supabase.
🧪 Una web publicada puede cargar y aun así no estar terminada
Hago primero una implementación sin añadir las variables de entorno. No es el estado final: quiero comprobar que el proyecto compila y que el sitio público puede abrirse. La compilación termina y la web carga bien.
Al intentar entrar al panel aparece el problema esperado: el cliente de Supabase no está disponible. Es una distinción importante. Que la página principal abra no significa que la autenticación y la base de datos estén funcionando. La publicación tiene dos comprobaciones distintas: la web debe estar en línea y sus servicios conectados deben responder.
Vuelvo al panel de Hostinger y entro en la sección de variables de entorno. Puedo añadirlas una por una, pero en este caso uso la opción de importación desde el archivo .env del proyecto. Aplico los cambios y espero a que termine la nueva compilación.
Tras la nueva implementación, abro otra vez la web. Compruebo que las páginas carguen y regreso al acceso de administración. Ahora sí puedo iniciar sesión. Dentro del panel aparecen las consultas y las secciones de contenido con los datos que había revisado antes. Ese es el cierre real de la publicación: no solo existe una dirección pública, también funciona la parte que el cliente necesita para trabajar.
✅ El método completo, resumido en decisiones prácticas
Después de recorrer todo el proceso, hay varias decisiones que me parecen más importantes que cualquier prompt aislado. Son las que convierten una generación rápida con IA en un proyecto utilizable:
- Definir el alcance editable. Identificar qué datos cambian en el negocio y no convertir cada elemento visual en una opción de administración.
- Crear primero la base del sitio. En este caso, una web con Astro para una constructora, sin conectar todavía Supabase.
- Revisar el diseño con criterio. Corregir exceso de texto, contraste, colores y espaciado mediante peticiones concretas.
- Añadir un panel enfocado. Servicios, proyectos, testimonios, datos del negocio y consultas, sin complejidad adicional.
- Verificar la conexión. Autorizar correctamente Supabase y comprobar que el agente puede trabajar con su integración MCP.
- Probar acciones reales. Enviar una solicitud desde el formulario y confirmar que aparece en el administrador.
- Mejorar según el uso. Añadir nuevos proyectos, permitir desactivarlos y paginar su presentación cuando haga falta.
- Publicar y volver a probar. Conectar GitHub con Hostinger, configurar las variables de entorno y comprobar el inicio de sesión en la web publicada.
Fíjate en el orden. No empiezo diseñando un administrador gigantesco ni intento cerrar todos los detalles con un único prompt. Construyo una versión, la recorro, encuentro lo que falta y avanzo. Esa forma de trabajar aprovecha la velocidad de la IA sin renunciar a tomar decisiones sobre el producto.
🛠️ Recursos para seguir creando
Este proyecto lo he construido con Antigravity, Astro, Supabase, GitHub y Hostinger. Si te interesan otros recursos relacionados con la creación de webs y aplicaciones, también puedes explorar Dínamo Sites para crear webs, Primera App para encontrar prompts profesionales orientados a aplicaciones y mi comunidad de creación de apps con IA para continuar aprendiendo y compartiendo proyectos.
La idea de fondo no depende de una herramienta concreta: entregar una web que responda a las necesidades del negocio y que no obligue al cliente a pedir ayuda cada vez que quiera actualizar algo sencillo. Para muchos proyectos, un panel pequeño, claro y hecho exactamente a medida vale más que un sistema enorme lleno de opciones que nadie va a usar.
Ese es el resultado que busco: una página atractiva para presentar el trabajo de la empresa, un formulario que entregue las consultas donde corresponde y un administrador desde el que el cliente pueda mantener viva su información sin tocar el diseño.
Aviso: este artículo puede incluir enlaces promocionales. Si realizas una compra, puedo recibir una comisión sin costo adicional para ti.
