Blueprint

The problem

Buildout had four products — Manage and Close, Showcase, Prospect, and the CRM — and each one had quietly invented its own idea of what a button should look like. Different colors, different heading sizes, different type scales from product to product. Every time a designer needed a color that didn't exist yet, they just added one.

None of that was anyone being careless. It's just what happens. Four teams, four codebases, four reasonable decisions made in isolation — and the sum of all those good decisions was four products that looked like they'd come from four different companies.

What V2 taught

V2 was the first attempt. It was built on Bootstrap 5.3 while the main platform was still on Bootstrap 3, and that gap turned out to be the whole problem. Something as simple as a new body font size would cascade into broken layouts across dozens of pages. We tried allocating 10% of the week to slowly converting pages over, but it was never going to be a clean swap. The foundations were too different.

What V2 taught me was that you can't design a system without also designing the migration. The components are the easy part. Getting four teams to adopt them without stopping their roadmaps — that's the real job.

The system

Blueprint ships as three packages. Tokens come first — a JSON file synced directly from Figma that generates the SCSS and CSS variables everything else builds on. The theme package is a custom Bootstrap 5.3 that consumes those tokens. The React component library sits on top of that. Change a token in Figma, and it flows through to the theme and into every component.

To keep adoption honest, Blueprint ships a lint rule alongside the components. When a developer reaches for a button or input from another UI library, the rule flags it and points to the Blueprint equivalent. No relying on developers to remember — the tooling does that for them.

For AI-assisted development, there's a Claude skill. Invoke it with /blueprint, or just mention a component or front-end task in conversation and it activates on its own. It looks up the available components, then dispatches a sub-agent to fetch the full API for whichever one is needed before writing a single line of code.

The proof

Prospect was the first product converted to Blueprint. That made sense — it was the most modern codebase we had, and it's where the early thinking behind Blueprint first took shape. It was also the real test. If Blueprint was as easy to adopt as it needed to be, Prospect would show it.

It was. The swap was clean. No cascading layout breaks, no weeks of one-off fixes. That's the moment Blueprint stopped being a proposal and became the plan for everything else.

The rollout

With Prospect as proof, the rollout to the other three products could happen with confidence. The strategy was the one V2 never got to use: start with the theme layer, push the tokens across all four apps in a single coordinated release, and keep the visual change gentle enough that users would notice the consistency without noticing the change.

That went live in 2026. Components migrate incrementally from there, app by app, as teams touch features. No flag day, no frozen roadmap — a lint rule quietly keeps everyone honest in the meantime.

Look back at the deal pipeline from the top of this case study. That's the clearest measure of how far the migration's come.

The outcome

All four products now speak the same language, the component library keeps absorbing the one-offs, and the launch shipped without a single fire. The plan to ease users in held.

The quiet win: design and engineering stopped re-litigating the basics. We argue about the right things now.