14 production sites from a single codebase

The challenge

The client operates multiple consumer brands in Argentina, with expansion planned across Brazil, Chile, and further LATAM markets. Each brand needs its own site: own domain, own identity, own content, own technical SEO. The naive approach — one codebase per brand — collapses under its own weight somewhere around the fifth site: every fix multiplies by the fleet, every launch takes weeks, and the engineering budget goes to maintenance instead of growth.

The brief was blunt: dozens of sites now, hundreds later, one codebase, and the client's own team must be able to run it after handover.

The architecture

One Next.js monorepo deploys to N independent Vercel projects. The brand identity is injected through a single environment variable at build time — launching a new brand means adding configuration and content, not writing code. The frontend is fully dynamic: zero hardcoded brand references anywhere in the codebase, with every page resolving its brand context and content at build.

Each brand generates its own sitemap.xml and robots.txt from the same logic — during the build-out we caught and fixed a desync between the two that was quietly 404-ing content pages, the kind of defect that costs young domains their crawl budget. Content lives in Postgres (Supabase) with a multi-schema layout prepared for per-market expansion. The sites are statically generated, which is what makes the model scale: runtime memory stays flat no matter how many sites are live. Scaling is a CI and build-orchestration problem, not a server-sizing one — that is how the architecture supports a ceiling of roughly 500 brands on shared code.

The content engine

Sites without content are shells, so the platform ships with a five-stage automated pipeline built on n8n:

• Page planner — a cross-join of brands, page templates, and keyword clusters produces the full page plan per site.
• Market scout — search-API research plus LLM extraction gathers factual material per market before a single word is generated.
• Content factory — multi-model LLM generation with E-E-A-T controls, so no single model's failure mode defines the output.
• Market refresh — live pages get their market data updated on schedule instead of decaying.
• Deployer — automated builds and deploys to the right Vercel project per brand.

Localization is native to the pipeline, not bolted on: es-419 Spanish, local currency, and locally relevant payment methods referenced in the content itself.

The handover

In early June the entire platform was migrated to the client's own infrastructure: their database, their GitHub organization, their Vercel team. The client owns every line of code, every workflow, and every credential. This is the "full code ownership, no vendor lock-in" promise from our engagement terms executed literally — the platform runs without us, and ongoing involvement is the client's choice, not a hostage situation.

Honest results

The 14 sites went live around June 14, 2026. Within the first week, 102 of 206 submitted URLs were indexed. By day nine, Search Console showed an average position of 18.3 with impressions growing.

We will not dress those numbers up as a ranking success — they are the normal early trajectory of young domains, and anyone who promises otherwise at week two is selling you something. The result of this project is not a position on a chart. It is that 14 production properties were designed, built, filled with localized content, and delivered into the client's full ownership — and that brand number 15 costs a configuration file, not a project.

Where this applies

The same architecture fits any operator who needs many related-but-distinct web properties on shared machinery: real estate developers with multi-project portfolios, property portals segmented by city or market, agencies running fleets of niche sites, and media operators expanding across regions. If your roadmap says "more sites" and your budget says "same team", this is the model built for that tension.