Leadership & Cost • Delivery & Cost

Delivering White-Label Dealer Sites at Scale

TL;DR: A repeatable template and delivery pipeline for shipping many client dealer websites from one shared Next.js codebase. A versioned site template, standardized CI with Playwright e2e and Lighthouse checks, Sentry error tracking, and cache-warming on deploy mean a new client site is a configuration of a proven base — not a bespoke build each time. The leverage is in the template and the pipeline, not in repeating the work.

Scope: Multi-site delivery program • Status: In Production

Quick Links

This is a delivery and cost story rather than a single-system story. The existing multi-site migration case is about re-architecting one platform; this is about the program around it — turning “build another dealer site” from a bespoke project into configuring a proven, well-tested base. The engineering leverage is in the template and the pipeline, so quality and operational tooling come for free with every new site.

📋Summary

Problem: Building each client dealer site from scratch is slow, inconsistent, and expensive to maintain across a growing roster.
Solution: One versioned Next.js site template plus a standardized CI/CD pipeline, so each site is a configured instance of a proven base.
Impact: New sites ship faster and more consistently; quality gates (e2e + Lighthouse) and error tracking are inherited by every instance, not re-invented per client.

Sites

~11 from one base

Quality gates

Playwright + Lighthouse CI

Per-site CI

standardized

📋Context

Across the dealer roster there are roughly a dozen client websites that share the same fundamental shape — inventory, product pages, lead capture, SEO — differing mainly in branding and content. Treating each as a one-off would multiply both build time and maintenance burden. The leadership/cost move was to invest in a shared, versioned template and a standardized pipeline so the marginal cost of a new site drops sharply.

🎯Goals, Requirements, Constraints

Goals

Make a new client site a configuration of a proven base, not a fresh build
Bake quality gates (e2e tests, performance budgets) into the shared pipeline
Keep error tracking and operational tooling consistent across every site
Reduce the per-site build and maintenance cost as the roster grows

Constraints

Sites are TypeScript (strict) Next.js apps on a shared component foundation
Each site has its own CI workflow and deploy, derived from the common template

Non-Goals

A fully no-code site builder — these are real Next.js apps, just templated
Re-architecting each client site for its own stack

🏗️Approach

A single versioned site template (its package identity carries a shared version that tracks across instances) defines the structure, components, and tooling every client site inherits. Each site is provisioned from that base and customized via branding and content rather than rewritten. The standardized npm scripts (dev/build/lint/test/test:e2e, Lighthouse runs, post-deploy cache warming) and per-site GitHub Actions workflows mean every site gets the same quality gates and operational behavior automatically.

Key Design Decisions

Decision: Invest in a shared, versioned template instead of per-client builds
Why: A dozen near-identical sites is exactly the case where templating pays for itself — fixes and improvements to the base propagate, and a new site starts from a known-good foundation.
Alternatives: Bespoke builds per client maximize flexibility but multiply cost and drift.
Decision: Bake quality gates into the shared pipeline
Why: Playwright e2e tests and Lighthouse checks live in the template's CI, so every site inherits performance and functional gates without anyone re-adding them.
Alternatives: Per-site, hand-rolled CI guarantees inconsistency and gaps.
Decision: Standardize operational tooling (Sentry, cache warming) in the base
Why: Error tracking and a post-deploy cache-warm step are the kind of thing that's easy to forget per site; putting them in the template makes them default.
Alternatives: Adding them ad hoc per client leads to sites with no monitoring.

⚙️Implementation

Components / Modules

Versioned site template: Shared Next.js (TypeScript, Tailwind) foundation with common components and a version that tracks across instances; new sites start here.
Standardized CI/CD: Per-site GitHub Actions workflows derived from the template — build, lint, Playwright e2e, and Lighthouse checks.
Operational defaults: Sentry error tracking and a post-deploy cache-warming step inherited by every site.

Automation & Delivery

Each site's CI runs the same build/test/e2e/Lighthouse pipeline
Post-deploy cache warming runs automatically
Shared template version propagates improvements to new instances

📊Results

Outcomes

Velocity: A new client site is a configured instance of a proven base, so it ships far faster than a bespoke build.
Consistency: Every site inherits the same quality gates, error tracking, and operational steps from the template.
Cost: Investing once in the template and pipeline lowers the marginal cost of each additional site and reduces ongoing maintenance drift.
Quality: Playwright e2e and Lighthouse checks are enforced uniformly rather than depending on per-site discipline.

⚖️Tradeoffs

A shared base is a shared dependency — a regression in the template can affect many sites, so its quality bar has to be high
Templating trades some per-client flexibility for consistency and speed

🚀Next Steps

Tighten the upgrade path so template improvements roll out to existing sites more easily
Expand shared performance budgets enforced in CI