The Hidden Maintenance Cost of a DIY Design System

Building a component library is a project. Running a design system is an operation. Build-versus-buy usually prices the first one.

Someone in the meeting will say you could build this yourselves in a few weeks now.

They're right. Component scaffolding, token files, a docs site, a decent first pass at accessibility. Work that took a quarter two years ago takes an afternoon with an agent and a good engineer. If the question is whether you're capable of building it, that question got easier and it got easier in your favour.

It's also the wrong question. Almost nobody fails at building a design system. Teams fail at running one, and running one costs what it always did.

The components are the cheap part

Underneath the library sits a set of jobs that show up whether or not anyone budgeted for them.

• The token pipeline. Values leave the design tool, get transformed, and land in code in a shape each platform can use. Someone owns that transformation, and someone owns what happens when a designer renames a collection on a Thursday.
• Releases. Versioning, changelogs, a deprecation policy, and an answer for the four teams still on last quarter's version.
• Keeping documentation true. Writing it is a week. Keeping it matching a system that moves underneath it is forever.
• Knowing who uses what. Which products are on the system, which are on it correctly, and which forked a component eight months ago without telling anyone.
• Governance. What gets in, what gets deprecated, and who decides when two teams want opposite things from the same component.
• Context for agents. New this year, and the line nobody has costed yet.

None of it ships as a feature. All of it turns up the day after the library works.

Why DIY feels cheap for about a year

A subscription is a line item. It has an owner, a renewal date, and a number finance can point at. Being visible is also what makes it the first thing anyone questions.

The DIY version of that number is a senior engineer losing a day a week to token plumbing, a designer retyping the same component description in three places, and a staff engineer disappearing into a framework migration for a fortnight. None of that gets billed to the design system. It lands in roadmaps as slippage, in retros as "infra work," and in people's weeks as the thing they do before the job they were hired for.

So the comparison in the room is a real number against zero. The zero is fiction. It's just spread thin enough that nobody has added it up.

Eighteen months in, you can usually spot it. The system still exists and the components still work, but the pipeline belongs to someone who moved teams, and the documentation describes a version of the system that stopped being true in March.

Can't agents just maintain it?

They can do a lot of it. An agent can run a semantic pass over documentation, propagate a rename across pages, and flag where the design and the build have drifted apart. Any comparison that pretends otherwise isn't worth reading.

The complication is that agents cut the cost of making things far more than the cost of looking after them.

Generating a component is close to free now. Deciding whether it should exist, what it's called, how it relates to the four similar ones already in the library, and what happens to the products using the old one costs the same as it ever did, because none of that was ever a typing problem.

GitClear's 2026 analysis of 623 million code changes puts a number on the gap: duplicated code blocks rose 81% between 2023 and 2026 while function connectivity fell 35%, which they describe as "duplicative reinvention beating progressively-improved reuse." Cheaper creation gave teams more to maintain, not less.

Then there's the second thing, which is that your design system picked up a new audience. It now serves designers, engineers, and a growing number of agents that need the same information in a different form. Documentation written for people to read doesn't resolve into the token, variant and state an agent has to pick. Serving that audience is a new surface to maintain, and it arrived the same year the build cost fell.

Maintenance got cheaper per task. There are more tasks, for more consumers, and the headcount didn't change.

When DIY is the right call

Sometimes it is. A small system, a handful of consuming teams, one person who can hold the whole thing in their head: build it, and don't let anyone sell you a platform for it.

Four questions usually settle which one you're in.

• Who owns the token pipeline while that person is on leave? A name is a dependency. A process is a system.
• How would you find out a product forked a component? If the answer is that someone would probably mention it, you don't have an adoption signal.
• What does changing a naming convention cost you this week? Count the surfaces you'd have to touch, not the difficulty of the decision.
• What do your agents read? If it's a markdown file someone updates by hand, you're already maintaining a second copy of your design system.

Most teams are comfortable with two of those and uneasy about the other two. The uneasy ones are rarely about components.

What you're paying for

Not the components. Build those, own them, keep them.

What a platform sells you is the operational layer: a pipeline maintained by someone whose job that is, versioning and deprecation as product behaviour rather than team convention, adoption data that exists without anyone building a reporting tool, and agent context generated from the system instead of typed out beside it. That's the shape of what Supernova does, and it's why the ROI calculator asks about your team's time rather than how many components you have.

Worth being straight about it: this is a trade, not a saving. You swap a cost you can see for one you can't, and what you get back is that the invisible one stops landing on the three people least able to absorb it.

Back to the meeting

When someone says you could build this in a few weeks, agree with them. They've done the arithmetic and the arithmetic is right.

Then ask the next question. Who runs it in year two, what does that cost, and whose roadmap does it come out of? That number is real either way. The only thing you're choosing is whether it shows up on an invoice or inside your engineering capacity.

See what the operational layer looks like.