Bilingual marketing site shipped in five weeks with our own agent pipeline

The problem

Every agency selling AI-built software needs a credible artifact that says "we use this on ourselves." Talking about the pipeline in slide decks is one thing. A live, public, bilingual marketing site with green CI, a Lighthouse SEO gate, and a structured case-study system is another.

The site had to ship in weeks, not months — and the work had to come out of the same orchestrator and the same agent pipeline we point clients to. A double-budget meta project (one budget for the work, one for the agents) was off the table from the start.

What we built

A static-first Next.js 14 marketing site, bilingual from day one (Spanish and English live on the same domain via next-intl), with:

• 7 public routes per locale (home, services, how-we-work, about, blog, cases, contact) plus legal pages, sitemap, robots, and dynamic OpenGraph images.
• Content-as-code via Velite — case studies and blog posts live as MDX in the repo with a typed frontmatter schema (industry enum, hero metric, tech stack, hours-of-human-review, region). Adding a case is a PR, not a CMS click.
• Per-route Lighthouse CI that gates merges on accessibility ≥0.9 and SEO ≥0.9. Performance ≥0.8 is a warning, not an error — an explicit decision so a bundle regression doesn't block a copy fix.
• Sentry error tracking with separate client / server / edge configs, source maps uploaded on every Vercel deploy.
• Bilingual SEO: hreflang alternates, locale-prefixed routes, sitemap with both URLs per page, OpenGraph images per route.

The pipeline that built it ran the same orchestrator steps any client project does: Strategist → UX Designer → Frontend → SEO → CI/CD → PM. Every PR was reviewed by a human before merge.

Key decisions

Why next-intl over a paid translation platform. Translation copy lives in messages/en.json and messages/es.json. A PR-based workflow means a translator can review the diff in GitHub, the spec author owns the source of truth, and there's no third-party billing surface. For a sub-100-string marketing site that's the right call. Above that scale, a hosted platform pays for itself.

Why Velite for content. Adding a case study should not require touching the codebase or remembering CMS field names. Velite enforces the schema at build time — if a frontmatter field is missing or an enum value is wrong, the build fails before deploy. That's the verification at the seam the orchestrator's Rule 5a calls for, applied to content.

Why LOCAL_FIRST CI mode. Every check that can run locally (lint, typecheck, build, content validation) runs via lefthook on push. Only Lighthouse — which needs a live preview URL — stays in GitHub Actions. The site stopped paying for cloud-CI minutes on everything that can run on the laptop.

Why a Lighthouse gate instead of "we'll check it manually." Marketing sites are exactly the class of project where performance regressions are easy to introduce (a stray third-party script, an oversized hero image) and easy to miss. Gating the merge means the only path to a regression in production is a deliberate decision, not an oversight.

Results

The site went from empty repo to public, bilingual site in 5 weeks. 54 commits, 2 languages, 7 routes per locale. The Lighthouse gate is wired to fail merges on accessibility or SEO regressions before they reach production.

Every client conversation now starts with a live link instead of a slide deck. The fastest proof we can ship the work is to point at the work, and the case study you're reading is part of that proof.