Cómo construimos una landing page en menos de 24h con Astro e IA

82 commits. 29 183 líneas de código. Tres idiomas. Accesible WCAG AA. Unas 10 horas de trabajo efectivo, entregado a la mañana siguiente. Un fundador, un agente de IA, cero presupuesto.

Esto no es una demo. Es hayka-pacha.io, el sitio que estás leyendo ahora mismo.

Aquí te contamos exactamente cómo lo hicimos, qué funcionó, qué falló, y si este workflow es replicable para tu próximo proyecto.

¿Por qué construir una landing page en un día?

Necesitábamos un sitio de marketing real, no un placeholder. Algo que haga pensar a los socios potenciales “esta gente sabe lo que hace.” Esto es lo que teníamos que entregar:

• Trilingüe (inglés, francés, español) con hreflang y enrutamiento i18n nativo
• Rápido: tiempos de carga por debajo de 2 segundos en cualquier dispositivo
• Accesible: conforme con WCAG AA desde el primer día
• Listo para SEO: datos estructurados, sitemaps, meta tags, imágenes Open Graph
• Blog integrado: colecciones de contenido MDX, sistema de borradores, publicación programada
• Captura de leads: formulario de contacto con consultas categorizadas y emails personalizados

Una agencia típica cotizaría 2 a 4 semanas y de 5 000 a 15 000 USD por este alcance. Nosotros gastamos 0 USD y 17 horas.

El stack, y por qué cada elección importa

No elegimos herramientas porque están de moda. Cada dependencia está ahí porque resuelve un problema sin crear dos más.

12 dependencias en total. Eso es todo. Sin librería de gestión de estado, sin CSS-in-JS, sin librería de componentes con 47 peer dependencies. Menos dependencias significa menos superficies de ataque, builds más rápidos y menos mantenimiento.

¿Qué es Astro? Astro es un framework web que genera páginas como HTML estático en tiempo de build, sin enviar JavaScript al navegador a menos que lo solicites explícitamente. Es ideal para sitios con mucho contenido donde el rendimiento y el SEO importan más que la interactividad del lado del cliente.

El workflow asistido por IA, lo que realmente pasó

Seamos concretos con lo de “asistido por IA”. No escribimos “constrúyeme un sitio” y nos fuimos a dormir. Un humano tomó cada decisión. La IA escribió el código, rápido.

Fase 1: Arquitectura (~1 hora)

Yo escribí una spec de 400 líneas: identidad de marca, jerarquía de audiencias, requisitos por sección, paleta de colores, elecciones tipográficas. Desde la etimología quechua de nuestro nombre hasta los valores OKLCH exactos.

Claude Code tomó esa spec y generó el plan de implementación: 12 tareas con dependencias, rutas de archivos y criterios de aceptación. Scaffolding del proyecto Astro con el adapter correcto, configuración i18n y setup del esquema de colecciones de contenido.

Decisión clave: Elegimos el enrutamiento i18n nativo de Astro (prefijo /{lang}/ en todas las rutas) en lugar de librerías i18n de terceros. Esto significa que el router maneja la detección de idioma en el edge, y los archivos de traducción se mantienen como JSON simple: cero overhead en tiempo de ejecución.

// src/content.config.ts : el esquema que cada artículo debe cumplir
const blog = defineCollection({
  loader: glob({ pattern: '**/*.mdx', base: './src/content/blog' }),
  schema: z.object({
    title:       z.string(),
    description: z.string(),
    pubDate:     z.coerce.date(),
    lang:        z.enum(['en', 'fr', 'es']),
    category:    z.enum(['SEO', 'Infra', 'Automation', 'Business']),
    readTime:    z.number(),
    draft:       z.boolean().default(false),
  }),
});

Este esquema se verifica en tiempo de build. Si un artículo omite un campo obligatorio o usa una categoría inválida, el build falla. Sin errores silenciosos, sin páginas rotas en producción.

Fase 2: Componentes (~5h30)

Aquí es donde los agentes de IA brillan. Esta fase fue rápida. Yo describía lo que quería, la IA escribía el componente, yo corregía lo que no encajaba, la IA ajustaba. Ocho veces seguidas.

Construimos 8 componentes en 5 horas y media:

6 de 8 componentes no envían nada de JavaScript. El único JS de la página es un IntersectionObserver ligero para animaciones al scroll (menos de 1 KB) y el handler de envío del formulario. Todo lo demás se renderiza como HTML estático en tiempo de build.

Fase 3: Pulido y endurecimiento (~6 horas)

La mayoría de los proyectos “build fast” se saltan esta fase. Nosotros no.

Creación del design system: Cada color, espaciado y regla tipográfica acabó en .claude/skills/hayka-design-system/SKILL.md. Cuando la IA construye un componente nuevo, lee este archivo primero. Consistencia de marca sin pensar en ello.

Auditoría de accesibilidad: Ejecutamos AccessLint en cada componente y corregimos:

• Labels de formulario faltantes
• Contraste de color insuficiente (recalibración completa de la paleta OKLCH para WCAG AA)
• Enlace de navegación rápida faltante
• Estilos de focus para navegación por teclado

Endurecimiento de seguridad:

• Verificación de origen CSRF en la API del formulario de contacto
• Headers de seguridad via Cloudflare (CSP, X-Frame-Options, HSTS)
• Secretos de entorno leídos desde el runtime de Cloudflare Workers, no embebidos en el build

Completitud i18n: Cada cadena de cada componente fue extraída a archivos de traducción. Detectamos 14 cadenas en inglés hardcodeadas que habrían salido sin traducir.

Fase 4: Despliegue e iteraciones (~4 horas)

Despliegue en Cloudflare Workers, generación de imagen OG, configuración del robots.txt, generación del sitemap. Luego el ciclo de iteración del copy: 23 commits de puro refinamiento, reformulación del manifiesto, corrección de anglicismos en la traducción francesa, ajuste de comillas.

Último commit justo antes del almuerzo.

Qué falló, y qué aprendimos

Se rompieron cosas. Esto es lo que pasó.

La pesadilla de CI multi-plataforma

Nuestro mayor sumidero de tiempo: 5 commits luchando con dependencias de binarios nativos. Tailwind CSS v4 usa binarios nativos específicos por plataforma (@tailwindcss/oxide). El package-lock.json generado en macOS no incluía los binarios de Linux necesarios para CI. Probamos npm ci, limpieza de caché y dependencias opcionales explícitas antes de encontrar una solución estable.

Lección: Cuando usas herramientas con módulos nativos específicos por plataforma, prueba tu pipeline de CI temprano, no después de haber construido 8 componentes.

La confusión Cloudflare Pages vs Workers

Inicialmente configuramos para Cloudflare Pages, pero el adapter de Astro para Cloudflare genera un formato Worker. Dos commits desperdiciados en el conflicto de configuración wrangler.jsonc entre los modos de despliegue Pages y Workers.

Lección: Lee la documentación del adapter antes del primer despliegue, no después de que wrangler deploy falle.

El bug del contenido invisible

Agregamos una clase CSS que ocultaba contenido hasta que JavaScript cargara (para animaciones de aparición al scroll). Resultado: los crawlers y herramientas de captura de pantalla veían secciones vacías. Un commit para corregir, pero podría haber matado nuestro SEO si lo hubiéramos pasado por alto.

Lección: Nunca ocultes contenido detrás de JavaScript sin un fallback. Los motores de búsqueda no esperan a tu IntersectionObserver.

Los números

32% de los commits fueron correcciones de bugs. Es normal. Ir rápido rompe cosas.

¿Es replicable este workflow?

Sí, pero no para todo el mundo ni en todas las condiciones.

Lo que hizo que funcionara fue la spec. 400 líneas escritas antes de tocar el código. La IA no adivina lo que quieres: ejecuta lo que le describes. Una spec mediocre produce un sitio mediocre, sin importar el modelo.

El stack disciplinado también ayudó. 12 dependencias, cada una justificada. Cuantas menos piezas móviles, menos cosas que romper y menos contexto que la IA necesita cargar para entender el proyecto.

Lo que no es automáticamente transferible: la experiencia previa. Tenía años trabajando con Astro, Tailwind y Cloudflare. La IA amplifica lo que ya sabes, no lo reemplaza. Alguien sin experiencia en despliegue va a atascarse donde yo no me atrasqué, y no va a saber por qué.

Tampoco era un proyecto complejo en cuanto a estado o interactividad. Un sitio de marketing con un formulario de contacto es un buen candidato para este workflow. Una aplicación con autenticación, base de datos en tiempo real y lógica de negocio compleja necesita mucha más supervisión en cada componente.

Lo que viene

Este sitio es la base de todo lo que vamos a publicar: estudios de caso, inmersiones técnicas, y el conocimiento en infraestructura que hemos construido gestionando más de 400 sitios en clusters de Kubernetes.

Lo siguiente: cómo nuestros agentes de IA gestionan toda la flota sin que toquemos nada. Ver todos los artículos o contáctanos si quieres que construyamos algo así para ti.