What Happens When You Optimize for Consistency Long Enough

Starting a new product should be exciting.

You have a new problem to solve, a domain to understand and customers to learn from. Yet somehow, a surprising amount of the first weeks is spent discussing things that have very little to do with the product.

Which component library should we use? Is it flexible enough? Does it have all the components we might need, even though we don't know what those are yet? How do we name colors? How do we structure text styles? What is a design-system component and what belongs to the domain? How do frontend and backend communicate? How do we keep API types in sync? How do we structure forms, state management, tables and pages?

I've had versions of these conversations on almost every product I've built.

And after a while I started asking myself a simple question:

Why are we starting from zero every time?

Something is easier to change than it is to create

This is one of the principles I use far beyond software development. If I'm going into a meeting where a group needs to create something, I try to bring a version one.

It doesn't have to be right.

When I had to prepare a customer presentation without having received the full briefing yet, I would still build a first version of the story before meeting with the team. Maybe half of it was wrong.

That's fine.

Three minutes into the meeting, we could already discuss something concrete instead of spending the first fifteen minutes creating a version one together. The worst possible outcome is that everything is wrong and we start from scratch.

But starting from scratch was the alternative anyway.

The same principle applies to building products. If frontend and backend need to decide how they communicate, I would rather enter the meeting with a document saying:

• we use RESTful APIs
• POST creates a resource
• PATCH updates a resource
• errors follow this structure
• these are our naming conventions

Then the conversation changes. Instead of asking:

we ask:

That's a much easier question to answer.

And that's one of the fundamental ideas behind Vuesion.

It is an opinionated version one.

The biggest bottleneck isn't writing code

Over the years, I became increasingly convinced that most of the friction in product teams comes from communication. Especially across disciplines.

Design makes a decision and presents it to engineering. Engineering challenges it. Design changes it. Product gets involved. Another constraint appears. The decision goes back.

Two or three round trips later, everyone finally agrees. The individual disciplines weren't slow. The translations between them were.

So I started trying to remove those translations. One of the first things I like to do with a new team is a domain workshop. We identify the important things in the domain, agree on what they are called and define how they relate to each other.

Without that, something surprisingly simple can happen: The CEO says "user" and means a customer of the platform. The designer says "user" and means the person operating the interface. The engineer doesn't have a User at all because the same concept is called Account in the system.

Everyone can have a perfectly reasonable conversation while talking about three different things. That's about as bad as it gets.

My ideal is the opposite: The label in Figma should have the same name as the column in the database.

Not literally in every possible situation, of course.

The principle is that every unnecessary mapping creates another opportunity for misunderstanding. Product, UX, frontend and backend should speak the same language wherever possible.

Start with the whole product team

The same principle applies to the design system.

At the beginning of a project, I like to get Product, UX and Engineering into the same room. We don't look at code. We open Figma.

First, we go through the foundation. Does the color palette cover what we need? Do the shades work? Do the semantic color tokens make sense for the product? Do the text styles give us what we need?

In the vast majority of projects, this takes about 30 minutes. Then we agree on how components work.

I use a simple distinction: A component has behavior and appearance.

If the appearance changes, we may be looking at a variant of an existing component. If the behavior changes, we may be looking at a new component.

Then we establish the difference between design-system components and domain components, how they are named and how new components enter the system.

Before introducing one, the people involved have a short conversation: Does the name make sense? Do the prop names make sense? Do the variants make sense? Do we have all the data the component needs?

Most importantly, everyone commits to using the same vocabulary afterwards.

What used to require days of exploration and separate discussions can often be established in a meeting of around two hours.

Combine that with a domain workshop during the first week and a team can start working on its first real feature in week two.

That's much more interesting to me than spending week two comparing component libraries.

Consistency is a feature

Designers have understood the value of consistency for a long time.

A design doesn't have to be extraordinary to feel good. If it is consistent, it will already be better than a surprising amount of what people use every day.

I wanted to see what happens when you apply the same idea to engineering.

My ideal codebase is one where you can't tell which developer wrote which part. It's not because developers shouldn't have individual ideas. It's because a product codebase isn't the place where every developer needs to express their individuality.

If we solve the same problem in ten places, I would rather solve it the same way ten times. Even if our solution later turns out to contain a mistake.

A consistent mistake is much easier to fix than ten individual versions of the same mistake.

Recently, for example, I changed a Prisma update type across roughly fifteen files in Vuesion. Because the pattern was consistent, I could search for it, write a regular expression and change every occurrence. The important part isn't the regex. The important part is that the mistake was identifiable. I didn't have to spend a day understanding fifteen different implementations first.

Consistency makes change cheaper.

But it also creates something even more valuable.

Consistency creates opportunities for automation

I have a simple rule for abstractions: If I've used something three times, I probably have enough information to understand the pattern.

And another rule for automation: If I have to do something repeatedly and it takes me more than a few minutes, I start wondering why I'm still doing it manually.

In a typical web application, the same structures appear again and again:

• CRUD APIs
• state-management stores
• forms
• field sets
• tables
• components
• pages

These are exactly the kinds of things Vuesion can generate.

Of course this saves typing. But saving keystrokes is the less interesting benefit. A generator encodes a decision.

It doesn't just create a form faster. It creates a form the way forms in this product are supposed to be built.

The next developer doesn't need to rediscover the pattern. The code review doesn't need to discuss the basic structure again.

A new team member gets another example that looks like all the existing examples. And when the pattern eventually changes, we know what we're looking for.

Automation and consistency reinforce each other.

The more consistent a system becomes, the more of it can be automated. And the more we automate, the easier it becomes to keep the system consistent.

Every project should make the next one better

This is how Vuesion evolved. It was never developed in isolation and then declared finished.

I built products with it. Something worked well. That became part of the foundation.

Something created friction. I changed it.

A team found a better solution. I learned from it.

The next project started with those lessons already built in. Then that project added another set of lessons.

The cycle has been the same for years: Build. Learn. Refine. Accelerate.

That's why I don't think of Vuesion as a collection of features. The individual pieces matter, but the accumulated decisions matter more.

The goal is that every new product starts further ahead than the one before it.

Then coding agents arrived

What's interesting is that AI didn't fundamentally change this philosophy. If anything, it reinforced it.

Vuesion's conventions were always designed to make a codebase easier to work with. Teams included senior engineers, junior engineers and people from other disciplines. The system needed to make the intended way of doing things obvious.

Early coding agents weren't fundamentally different from a very fast but inexperienced developer. They could produce code quickly. But they needed context. They needed examples. They needed clear boundaries. They needed to understand which of several possible implementations was the one this codebase expected.

So it wasn't particularly surprising to me that coding agents worked better with Vuesion than with less consistent codebases.

The things that help humans also help agents: Clear naming. Predictable structures. Existing patterns. Small abstractions. Generators. Tests. Explicit rules. A shared vocabulary.

In an inconsistent codebase, an agent can find five ways of solving the same problem and create a sixth. And it can do that remarkably quickly.

Coding agents don't make architecture less important. They make consistency more valuable.

This is also why I don't want Vuesion to generate as much code as possible. I want it to make the correct path obvious enough that both humans and agents can spend their time on the parts that actually require thought.

Writing code should come surprisingly late

I don't think the primary job of a software engineer is writing code.

For me, the priorities look more like this:

• Understand and enforce the domain.
• Understand the customer and the product.
• Organize and simplify the system.
• Write the code that is actually necessary.

Code is unavoidable. But every line we don't need to write is a line we don't need to understand, test, review, maintain or eventually remove.

That's why I prefer simple solutions. It's why I automate repetitive work. It's why I care so much about naming and consistency. And it's why I want Product, Design and Engineering making decisions together instead of throwing them over departmental walls.

Speed, quality and cost are often treated as unavoidable trade-offs. I don't think they have to be.

A lot of what makes software slow and expensive isn't quality. It's friction. Repeated decisions. Unnecessary code. Translation between disciplines. Inconsistent implementations. Maintenance of complexity that didn't need to exist.

Remove enough of that friction and you create room for quality without slowing down.

More importantly, you create room for the work that actually matters: Understanding what you're building and why.

That's why Vuesion exists.

It's not to help me write more code. It's to make sure I have to write less of it.

This is how I build Vuesion

These aren't just ideas I write about. They're principles I've been building into Vuesion for more than eight years.

See how Vuesion works →