Why I Built Bezel

I've spent much of my career at the intersection of design and engineering. I've always loved both: the technical challenge of building software and the creative satisfaction of seeing a visual system come to life.

Throughout that career, my teammates and I noticed a recurring pattern.

Companies would invest enormous amounts of time and talent into building design systems, yet much of what they ultimately created was remarkably similar.

Buttons still needed to be accessible. Forms still needed predictable behavior. Components needed consistent APIs. Products needed typography, spacing, colors, borders, radii, and other constraints.

The implementations varied tremendously from organization to organization, but many of the underlying problems did not.

My teammates and I kept wondering:

Why are we rebuilding so much of this from scratch?

The cost became impossible for us to ignore.

My teammates and I saw the problem most clearly during the eight years I spent at my previous company.

At one point, we spent roughly two years building and integrating a design system. Building the components was only part of the work.

Teams had to be onboarded. Developers needed to learn how components should be used. Contribution models had to be established. Documentation and conventions needed to be communicated. Existing applications had to migrate.

It required coordination across designers, engineers, and teams.

Then, after all that work, the system was replaced.

And later, it was replaced again.

Components changed. Colors changed. APIs and usage patterns changed. Teams migrated again.

Each time, work we thought was finished suddenly became work that needed to be done again.

That experience stayed with us.

Acquisitions made the problem even more obvious.

The company was also highly acquisition-focused, averaging roughly one acquisition per quarter during periods of my time there.

An acquired product couldn't simply continue looking and behaving like a completely different company. We wanted customers to experience it as part of one cohesive product portfolio.

That could mean taking an application built with Angular or Vue and integrating it into an organization primarily building with React.

Components had to be recreated. Interfaces had to be rebranded. Design conventions had to be translated. Sometimes entire front ends effectively had to be rebuilt.

And the expectation could be to accomplish all of that within a quarter.

My teammates and I kept thinking there had to be a better abstraction.

What if the design language itself were portable?

Instead of every application owning an isolated interpretation of the brand, what if there were a shared source of truth that could describe the system independently of any particular application or framework?

Then AI changed what was possible.

AI has dramatically reduced the time required to create software.

But it has introduced another problem.

An AI agent can generate an interface incredibly quickly, but without meaningful design context, it's making decisions on your behalf.

Which color should it use? Which radius? Which spacing scale? Which typography? Which component? How should that component behave? What makes this interface distinctly yours?

Without that context, AI guesses.

And when thousands of people use similar models, component libraries, defaults, and prompts, those guesses can start producing remarkably similar results.

I don't think the answer is simply making AI a better designer.

AI doesn't need to become your designer. It needs a design system it can understand.

The design system should come before the agent starts building.

I see Bezel as a missing precursor to today's AI development workflow.

Before asking an agent to build an application, you should be able to establish the design language it's going to build from.

Colors. Typography. Spacing. Borders. Radii. Components. Tokens. Constraints. Brand decisions.

And you shouldn't need weeks of design work just to find out whether those decisions work together.

With Bezel, the goal is to import or create a system, adjust its constraints, and immediately see those decisions applied across real interfaces.

Try another direction.

Change the typography.

Change the colors.

Explore a completely different visual language.

Instead of spending weeks creating one direction before seeing it come together, I want people to be able to explore dozens of possibilities quickly.

This changes design experimentation from something expensive into something you can do continuously.

This is the part I love.

One of my favorite things about building Bezel is simply seeing the output.

I love watching colors transform an interface. I love seeing typography change its personality. I love seeing an entirely different visual identity emerge from a system of constraints.

More importantly, I love what becomes possible when experimentation isn't prohibitively expensive.

A direction that might never have been explored because it would have taken days to prototype can now be tried almost immediately.

You can compare it with another direction. And another.

Instead of asking, "Is this idea worth spending a week prototyping?" you can ask, "What happens if we try it?"

Making experimentation inexpensive creates room for more creativity—not less.

A design system shouldn't become outdated the moment you use it.

There's another problem with AI-generated code that I think is going to become increasingly important.

The minute code is generated, it starts moving toward being out of date.

Your organization keeps changing.

Someone updates a color. Typography evolves. A token changes. A component API improves. A new scale is introduced.

The generated code doesn't automatically know that.

Now you have drift.

Multiply that across applications, teams, repositories, and AI-generated interfaces, and today's incredible development speed can become tomorrow's technical debt.

I don't want Bezel to produce another static artifact developers have to maintain manually.

I want the design system to remain connected to what was built from it.

When the system changes, agents should be able to understand those changes, update implementations, run the appropriate tooling, and prepare the necessary code changes.

The developer's job becomes reviewing the PR—not manually finding and rebuilding every affected implementation.

Why I decided to build Bezel

The idea had been sitting in the back of my mind for years:

Something like this should exist by now.

At one point in my career, I was leading around 20 engineers across three teams. My teammates and I saw firsthand how much capable engineering talent could be consumed by necessary but repetitive UI migrations, integrations, and design-system work instead of differentiated product features.

My teammates and I experienced the problem from both sides of the design and engineering relationship. For me, it also touched the work I love most: design, frontend engineering, and the space where those disciplines meet.

Eventually, I decided to go full-time on the project I was most passionate about.

I had the conviction, time, and motivation to try to solve a problem my teammates and I had been thinking about for years—not just for one company or the teams I happened to lead, but for anyone facing the same problem.

That's why I built Bezel.

What I want Bezel to become

I want Bezel to give established organizations a way to maintain a common design language across teams, products, acquisitions, and technology stacks.

I want developers spending more of their time building valuable product features and less of it repeatedly migrating the same visual infrastructure.

I want designers to be able to experiment more freely without every change creating a costly downstream implementation project.

And I want a solo founder without a design organization behind them to be able to create something intentional, distinctive, and unmistakably theirs.

Brand shouldn't have to be something founders fix after validating their product.

AI has made it possible for one person to build at a scale that previously required a team. I want Bezel to help give that person some of the design-system infrastructure that previously required a team as well.

The future I see isn't one where AI makes design systems obsolete.

I think the opposite happens.

As more software gets built by agents, design systems become more important because humans and machines need a shared language from which to build.

Build the system once. Let everything else build from it.

Explore the Bezel blog →