Scalable Website Design: How a Regional Home Services Brand Built 129 Components Across 1,175+ Pages

The Challenge: Brand Drift at Scale

A regional home services brand operating across a midwest metro and surrounding service area had grown its digital presence page by page — but without a unified design language. The result was brand drift: inconsistent colors, mismatched typography, and UI elements that were rebuilt manually for every new page. With only 15 original pages, the cracks were manageable. But the business needed to scale to hundreds of location-specific and service-specific pages to compete for local search traffic. At that volume, manual, per-page styling wasn't just slow — it was a structural liability.

Every new product page required a developer to style it from the ground up, referencing whatever styles existed elsewhere on the site. There was no single source of truth for what a button should look like, how a hero section should behave on mobile, or which font weight was correct for a section heading. Brand standards lived in someone's memory or a PDF style guide that wasn't connected to the codebase in any functional way. The business consequence was real: an inconsistent site appearance eroded user trust, slowed time-to-market for new service offerings, and made maintenance a recurring burden.

Key Metrics: What a Scalable Web Design System Delivers

Our Approach: Design Tokens First, Components Second

The strategic decision that made this design system scalable was establishing the design token layer before writing a single component. Rather than hardcoding colors and typography into individual UI elements, the team defined all brand values as CSS custom properties at the root level. Every color — from the primary deep navy to the conversion-focused CTA orange — became a named variable. This meant that any component referencing `--cta` would automatically reflect brand color decisions, now and in the future, without requiring component-level edits.

With the token foundation in place, the team used shadcn/ui as the base component layer. This avoided weeks of building accessible, tested form elements, modals, and navigation patterns from scratch. The 67 shadcn/ui components were customized to consume the brand's CSS variables — meaning they looked and behaved like the brand from day one, while remaining fully accessible and well-tested. On top of this foundation, 62 custom business components were built for domain-specific needs: product detail sections, trust indicators, consultation CTAs, and the 5 GEO components required for location page templates.

Implementation Deep Dive: Building the Component Library

Phase one established the CSS variables design system — the non-negotiable foundation that everything else would inherit from. Using HSL-formatted custom properties, the team defined the complete brand palette: background, foreground, primary navy, accent gold, CTA orange, muted tones, card surfaces, borders, and form elements. HSL values were chosen deliberately: they make future dark mode implementation straightforward, because switching themes requires only changing the lightness values rather than replacing hex codes entirely. Layout tokens — including header height at standard and large breakpoints — were also included, ensuring responsive behavior was consistent from the start.

Phase two built the component library itself, split into two distinct tracks running in parallel. The shadcn/ui integration track customized 67 proven base components — buttons, inputs, dialogs, tabs, accordions, toast notifications, and more — to inherit the brand token layer. Simultaneously, the custom business component track built 62 domain-specific components from scratch. The most critical of these were the product detail section components: ProductHero, TrustBar, StyleOptionsGrid, TestimonialSection, ComparisonTable, FeaturesBenefits, ProductGallery, InstallationGallery, FAQSection, and RelatedProducts. These ten components, used together, power the full product page template.

Technical Architecture: How 129 Components Power 1,175+ Pages

The component architecture follows a three-tier model. At the base layer, shadcn/ui components provide accessible, tested primitives: forms, overlays, feedback elements, and navigation patterns. These components are customized via CSS variables and class-variance-authority (CVA) variant definitions — the Button component, for example, exposes variants for default, outline, ghost, link, and a custom `cta` variant specifically engineered for conversion actions. The CVA variant system means all size and style combinations are defined in one place, preventing the kind of one-off styling that previously caused brand drift.

Above the base layer sit the business components — 62 custom-built components for domain-specific use cases. The TrustBar component renders star ratings, warranty information, licensing credentials, and fulfillment timelines in a consistent grid, pulling from a centralized business constants file rather than hardcoding values. The ConsultationCTA component wraps the Button component, adds Google Tag Manager tracking via a dedicated tracking utility, and fires a modal open event — ensuring that every call-to-action across all 1,175+ pages behaves identically and is measured against the same $150 phone conversion value. Above the business layer, the 5 GEO components power the programmatic location page templates.

Programmatic Scaling: From 15 Pages to 1,175+

The design system's most consequential application was enabling programmatic page generation at scale. Starting from just 15 original pages, the component library became the rendering engine for 1,122 programmatic pages and 66 location pages — a 7,733% increase in total content. Location coverage grew 2,100%, meaning the brand's addressable search footprint expanded dramatically without requiring designers or developers to touch individual pages. Every programmatic page inherits the full component system: consistent hero sections, trust bars, FAQ accordions, comparison tables, and GEO-specific content blocks, all rendering at under 200ms per component.

The 5 GEO components were specifically engineered for the location page template. A TLDR section gives search engines and users an immediate summary of the service offering in the given area. A question-and-answer section addresses location-specific queries. A benefits table surfaces competitive differentiators. A local expertise block establishes geographic authority. A comparison table allows service and product comparisons relevant to the local market. Each of these components accepts dynamic data props — location name, service specifics, local context — while rendering within the design system's constraints. The result is a page that feels handcrafted but is generated automatically, maintaining 95+ Lighthouse scores throughout.

Results & Impact: Verified Metrics

Key Takeaways: What Makes a Design System Scale

Brand Consistency at Scale: The Systematic Approach

Brand consistency at scale is not a design problem — it's an architecture problem. The visual identity of a home services brand is defined by its color palette, typography, spacing rhythm, and interaction patterns. When those elements live in a designer's head or a disconnected style guide, consistency degrades proportionally with the number of pages. When they live in CSS custom properties consumed by a shared component library, consistency is enforced automatically. The 129 components in this system don't just look consistent — they're structurally incapable of drifting from the brand, because every visual decision is resolved by the same token layer.

The CVA variant system for the Button component exemplifies this principle. Rather than having developers choose colors and sizes ad hoc, the component exposes a fixed set of variants — default, outline, ghost, link, and cta. The `cta` variant is purpose-built for conversion actions, applying the conversion orange token, removing border radius for a squared look, and setting hover state behavior. This means that across all 1,175+ pages, every conversion button looks identical, behaves identically, and tracks identically against the $150 phone conversion value. That level of consistency is impossible to achieve manually at this page count — it requires the system to enforce it.

Lessons Learned: What We'd Repeat and What We'd Do Differently

The decision to build on shadcn/ui rather than raw Tailwind was validated completely. The 67 base components arrived accessible, keyboard-navigable, and ARIA-compliant — removing a class of quality concerns that would have consumed significant development time. If we were starting over, the one addition we'd make from day one is Storybook for component documentation. As the library grew to 129 components, developer discovery relied on well-organized `index.ts` export files — functional, but a visual component explorer would have accelerated onboarding and made the library more self-documenting.

The incremental component development approach — building components as actual page templates required them, rather than speculatively — proved correct for a project at this scale and timeline. Over-engineering the library upfront would have delayed page production without adding measurable value. The animation utility system (shared `fade-in-up` keyframes with configurable stagger delays) was a small investment that created outsized perceived quality across the site — a pattern worth adopting early in any design system project. The HSL-based CSS variable format, while slightly less intuitive than hex codes, paid dividends by making the dark mode foundation trivially easy to scaffold for future implementation.