Everything, everywhere, all at once

AI has changed what teams can build and how quickly they can build it. Bankrate needed a design system that could support its growing range of products and experiences: a marketing site, SaaS products, internal tools, and white-label partnerships.

Treasury was the design system for Bankrate’s marketing site. Ledger is the next evolution, building on Treasury’s foundation and extending the system to support Bankrate’s existing products and whatever comes next.

Under Pressure

When new leadership arrived at Bankrate, that meant rethinking the brand, tech stack, and how teams could ship faster.

Building Ledger involved:

1. Consolidating a sprawling mix of Laravel Blade, React, and Vue into a single stack built with shadcn and Next.js.
2. Expanding the system to support SaaS products and white-label experiences.
3. Launching Ledger alongside the rebrand and updating the site to reflect both.

All of it had to ship in 30 days. That meant translating the rebrand into Ledger, releasing its shadcn registry to product teams, and putting enough of the system in place for them to start building.

It was a pressure test for AI: could it deliver this quickly?

The System Is Systeming

I updated Treasury’s foundations to match the new brand. Bankrate’s design decisions were already expressed in the Tailwind config, so changing the values didn’t change the system’s intent.

For example, the colors were organized into perceptually uniform scales. I could swap the hex values in the Tailwind config while a heading still used gray-900, maintaining the same visual weight and contrast.

Across 500+ components and 10,000 pages, the change looked almost uneventful. Nothing broke.

Refactoring Bankrate’s previous system, Classy, into Treasury paid off. The systematic decisions I made years earlier carried the system through the rebrand without another rebuild.

Any Variable You Like

Shadcn makes it possible to theme almost everything, but that does not mean everything should be themed.

Treasury worked directly from Tailwind’s primitive color scale: blue-600, gray-400, red-200, and so on. That gave marketing room for expressive layouts and one-off design decisions. Ledger, on the other hand, prioritized white-label experiences with more of the design built in.

To see how far shadcn’s base variables could stretch across those surfaces, I built a sandbox of components and templates in code. I couldn’t determine that in Figma. I needed to see the system as a whole and make decisions that anticipated future product needs.

Shadcn’s base theme variables covered about 95% of Ledger’s needs. I didn’t love every aesthetic decision, but changing them would have added variables and maintenance without improving how the interfaces functioned. Variables can become a bottomless pit when every component, interaction state, and exception gets its own semantic variable.

To limit variable proliferation, I used semantic variables for white-label themes and primitive variables for expressive design.

Moving beyond the marketing site required more systematic interaction feedback, so I automated pseudo-states inside Ledger’s components instead of requiring engineers to define them each time.

For example, Ledger’s base button uses the semantic variable primary in its default state. The hover state applies an opacity modifier to primary. For the disabled state, I targeted the primitive variable gray-600 directly instead of creating a dedicated semantic variable. I chose not to style the active state separately, trading one layer of feedback for one less variable to define and maintain.

The goal wasn’t to automate every choice. The goal was to automate anyone who is not a designer out of a choice, while preserving designer agency where context requires judgment. Theming can save time, but once product teams start debating every design choice, it stops saving time.

Ledger’s API

With future product needs unknown, not every component or pattern could ship with Ledger at launch. I structured its API so product teams could extend Ledger as new needs emerged.

To keep Ledger “canonical” across products, I defined:

• shared rules for props, variants, sizes, and slots
• baseline options that stayed consistent across products
• product extensions that added to Ledger instead of overriding it

For example, Ledger’s base button shipped with three sizes: sm, default, and lg. If a product needed a smaller or larger button, the team could add xs or 2xl instead of renaming or redefining a shared size. That preserved Ledger’s API contract, protected the components and product experiences that already depended on it, and kept future updates compatible.

I documented similar scenarios across the API so engineers understood the difference between extending Ledger and overriding its baseline. This guidance gave product teams room to adapt Ledger without forking it.

Designing for agents

A design system’s primary consumers are usually designers and engineers. As a shadcn registry, Ledger is accessible across the org: a CTO, a product manager, or even an accountant can ask an agent to build something. The consumer is no longer a person, but the agent building on their behalf.

Agents range from IDE completions and CLI agents to wrappers like v0 or Figma AI. No two agents are the same: their behavior depends on the instructions and personality people give them, the information they can access, and the AI model they use. And new model updates seem to arrive every month, making consistency a moving target.

I wrote Ledger’s agent governance in .md files, turning unwritten design and engineering rules into explicit instructions and guardrails. That meant thinking consciously about what I do unconsciously, which is its own kind of mind game.

There’s no industry standard for testing agents reliably. My personal agents draw from 3 years of design system context, so they are not a representative baseline for how another agent would use Ledger. Between wrappers, agent setup, and model updates, it is difficult to isolate what causes an output to change or know where to intervene when it does.

Current state

At the time of this writing, Ledger is about 2 months old. Bankrate rolled out the rebrand and migrated its marketing site to a new tech stack in about 30 days.

I built Ledger’s shadcn registry in 1 week. It adapted the existing design system to the rebrand without breaking changes to the marketing site, extended it across Bankrate’s current product suite, and established the foundation for future products, both internal and external.

In that same week, I created a working sandbox to test components and hypotheses across possible product scenarios. I documented what worked as the system’s governance, including its design intent, how variables should be used, and how the API should be extended, so product teams and engineers could start implementing before the deadline.

Is that crazy work? Uh, yes.

The longer-term questions are still open. I hope Ledger helps product teams ship faster while keeping design output consistent with the rebrand. Over time, we’ll see how it responds to changing product needs and agent behavior, and whether shadcn holds up as the distribution model for a multi-design system.