Project OPUS: Design System & Execution

Tailwind + Flowbite, Heavily Customized

The technical foundation was Tailwind CSS as the styling platform and Flowbite as a base-level UI kit, deliberately chosen as a starting point, not an off-the-shelf solution, since it needed to flex across 20+ distinct brand identities without losing structural consistency underneath.

This is the clearest visual evidence of that balance: every brand runs the same token structure, Primary, Secondary, Accent 1, Accent 2 — but the values populating those tokens are entirely brand-specific. The system enforces structure, not appearance. That distinction was the whole point: a brand president could look at their site and see their brand, while engineering only ever had to build against one consistent token model.

Solving the Hardest Problem First

Before component-level work began, the first and largest task was navigation, the one piece of the experience that had to scale across every brand's unique service structure without becoming either a bloated mega-menu or an oversimplified one.

This artifact is worth using directly rather than paraphrasing, it documents its own guiding principles: mobile-first, easy path to requesting service, simple and logical navigation, clean and effective use of white space, and consistency across brands while still reflecting each brand's personality. Those principles, defined early on Mr. Electric, became the test every subsequent brand's navigation had to pass.

Building Once, Reusing Everywhere

With navigation solved, the work shifted to defining standard components, built once against the token system, then reused across every brand's templates in CrownPeak: heroes, service grids, offer carousels, testimonial blocks, forms.

The flows artifact below is the clearest single proof of the "build once" principle, the same functional component (location capture, contact form, address validation) reused across different brands and screen states (desktop, mobile, error, success), rather than each brand getting a custom version. This is what made the migration schedule realistic: new brands entering the system got a large percentage of their experience "for free" from components that already existed.

How Gaps Became Permanent System Additions

Not every brand fit the existing component library. As new brands entered the migration, we'd regularly discover a need the system hadn't accounted for yet, we called these deltas. Rather than solving them as one-off exceptions, every delta was designed, reviewed, and then folded back into the shared design system, where it became available for any brand to pick up.