Sitio de marketing bilingüe entregado en cinco semanas con nuestro propio pipeline de agentes

El problema

Toda agencia que vende software construido con IA necesita un artefacto creíble que diga "esto lo usamos en nosotros mismos". Hablar del pipeline en presentaciones es una cosa. Un sitio de marketing público, bilingüe, con CI verde, un gate de SEO en Lighthouse y un sistema estructurado de casos de estudio es otra.

El sitio tenía que entregarse en semanas, no en meses — y el trabajo tenía que salir del mismo orquestador y del mismo pipeline de agentes al que apuntamos a los clientes. Un meta-proyecto con doble presupuesto (uno para el trabajo, otro para los agentes) estuvo descartado desde el principio.

Lo que construimos

Un sitio de marketing en Next.js 14 con estrategia static-first, bilingüe desde el día uno (español e inglés viven en el mismo dominio vía next-intl), con:

• 7 rutas públicas por idioma (home, servicios, cómo-trabajamos, sobre-nosotros, blog, casos, contacto) más páginas legales, sitemap, robots e imágenes OpenGraph dinámicas.
• Contenido como código vía Velite — los casos de estudio y blog posts viven como MDX en el repo con un schema tipado de frontmatter (enum de industria, métrica destacada, stack técnico, horas de revisión humana, región). Agregar un caso es un PR, no un click en un CMS.
• Lighthouse CI por ruta que bloquea merges con accesibilidad ≥0.9 y SEO ≥0.9. Performance ≥0.8 es warning, no error — una decisión explícita para que una regresión de bundle no bloquee un fix de copy.
• Sentry para tracking de errores, con configs separadas para cliente / server / edge y source maps subidos en cada deploy de Vercel.
• SEO bilingüe: alternates de hreflang, rutas con prefijo de locale, sitemap con ambas URLs por página, imágenes OpenGraph por ruta.

El pipeline que lo construyó corrió los mismos pasos del orquestador que cualquier proyecto de cliente: Strategist → UX Designer → Frontend → SEO → CI/CD → PM. Cada PR fue revisado por un humano antes del merge.

Decisiones clave

Por qué next-intl en lugar de una plataforma de traducción paga. La copy de traducciones vive en messages/en.json y messages/es.json. Un workflow basado en PRs significa que un traductor puede revisar el diff en GitHub, el autor del spec es dueño de la fuente de verdad y no hay superficie de facturación de terceros. Para un sitio de marketing sub-100 strings esa es la decisión correcta. Por encima de esa escala, una plataforma hospedada se paga sola.

Por qué Velite para contenido. Agregar un caso de estudio no debería requerir tocar el código o recordar nombres de campos de un CMS. Velite enforza el schema en tiempo de build — si falta un campo de frontmatter o un valor de enum es incorrecto, el build falla antes del deploy. Esa es la verificación en el seam que la Rule 5a del orquestador exige, aplicada al contenido.

Por qué CI en modo LOCAL_FIRST. Cada check que puede correr localmente (lint, typecheck, build, validación de contenido) corre vía lefthook en el push. Solo Lighthouse — que necesita una URL de preview en vivo — se queda en GitHub Actions. El sitio dejó de pagar minutos de CI en la nube por todo lo que puede correr en la laptop.

Por qué un gate de Lighthouse en lugar de "lo chequeamos a mano". El trabajo de marketing-site es exactamente la clase de proyecto donde las regresiones de performance son fáciles de introducir (un script de terceros perdido, una hero image grande de más) y fáciles de pasar por alto. Bloquear el merge significa que el único camino a una regresión en producción es una decisión deliberada, no un descuido.

Resultados

El sitio pasó de repo vacío a sitio público y bilingüe en 5 semanas. 54 commits, 2 idiomas, 7 rutas por locale. El gate de Lighthouse está conectado para fallar merges ante regresiones de accesibilidad o SEO antes de que lleguen a producción.

Cada conversación con cliente ahora arranca con un link en vivo en lugar de una presentación. La prueba más rápida de que podemos entregar el trabajo es señalar el trabajo, y el caso que estás leyendo es parte de esa prueba.