Cómo Creé la Landing Page de VanTrip Usando Solo IA (y lo que aprendí del desastre multilingüe)

¿Te imaginas crear la landing de tu app sin escribir apenas una línea de código?
Eso es lo que intenté hacer para VanTrip, mi app de viajes, y aunque fue un reto, aprendí lecciones valiosas sobre IA, stacks modernos y lo importante que es entender la infraestructura antes de dejarse llevar por la “magia”.
Todo empezó queriendo probar Astro (sin tener ni idea de cómo funcionaba) y usar la IA como copiloto. ¿El objetivo? Ver hasta dónde podía llegar en una jornada de trabajo.
El experimento: ¿puede la IA crear la landing por mí?
Mi primer intento fue directo:
Le pasé una captura del diseño esperando que “la magia ocurriera”.
Fracaso total. La IA no fue capaz de generar nada ni remotamente parecido.
Así que cambié de enfoque: le pedí que me estructurara la página por secciones (hero
, features
, FAQ
...), y ahí sí. En menos de un día tenía una landing funcional, limpia y modular. Incluso pensé en reutilizarla para otros proyectos cambiando solo los textos y el branding.
¿Qué falló? El problema de Astro + Firebase Hosting
Estaba desplegando en Firebase Hosting, que funciona como un CDN estático:
- Solo sirve archivos ya generados (
.html
,.css
,.js
). - No procesa peticiones en tiempo real.
- No ejecuta código de servidor para detectar el idioma o personalizar contenido.
La IA seguía sugiriéndome soluciones imposibles, basándose en la documentación oficial de Astro (que asume un entorno serverless o con middleware). Y como no hice commits intermedios, la IA acabó rompiendo lo que ya funcionaba y no pude volver atrás.
¿Cómo lo solucioné finalmente?
Implementé una estructura de carpetas físicas con rutas por idioma:
/dist/
index.html # Inglés (idioma por defecto)
about.html # Página "about" en inglés
/es/
index.html # Español
about.html # Página "about" en español
Además, creé componentes reutilizables que reciben currentLang
como parámetro, evitando duplicar código.
Esta solución funciona perfectamente en CDNs estáticos como Firebase Hosting porque:
- No requiere servidor ni lógica en tiempo real.
- Cada URL apunta a un archivo estático real.
- Mejor rendimiento (menos TTFB, sin cold starts).
- Más simple de cachear y más fácil de mantener.
- Coste predecible (sin funciones en la nube ejecutándose).
🛠️ Tip extra: Guía a la IA, no dejes que tome el control
Antes de pedirle que “haga cosas”, pídele un checklist de tareas y que las ejecute una a una.
Esto te permite:
- Revisar cada paso antes de avanzar.
- Hacer commits pequeños y frecuentes.
- Mantener el control total de la estructura.
Créeme, evitarás muchos disgustos.
Reflexión final: lo que aprendí de todo esto
- La IA acelera, pero no entiende la arquitectura de tu proyecto.
- Las soluciones oficiales no siempre son las mejores para tu caso concreto.
- Lo que parece “un apaño” a veces funciona mejor que soluciones complejas.
- Haz commits frecuentes. Si no, cuando algo se rompe, no hay vuelta atrás.
- Entender la infraestructura antes de empezar es clave.
- Y lo más importante: la IA es una herramienta, no un arquitecto.
¿Volvería a usar IA para desarrollo web?
Absolutamente.Pero ahora sé que debo mantener bajo control las decisiones clave y usar la IA como ejecutor, no como diseñador de la arquitectura.
¿Has vivido algo parecido? ¿Te ha pasado que la solución más simple acaba funcionando mejor que la “oficial”?
¡Te leo en los comentarios o por contacto@monti.dev!