Why I’m building Fenly, and the one rule it can’t break

Hi, I’m Felipe. I’m a product designer in Bogotá, and for the last 15 years most of my work has been SaaS products and the design systems behind them.

If you’ve kept a design system alive, you know the job. It isn’t the big launch. It’s the small, careful work after it. A token renamed here. A component fixed there. Docs that fall behind. A Figma library that slowly stops matching the code.

And most of us do that work on small teams. zeroheight’s Design Systems Report 2026 found that 61% of the design system teams it surveyed have five people or fewer, and 61% say they’re understaffed. That matches everything I’ve seen. The system is usually one or two people holding a lot of things together.

So I’m building Fenly: a design system manager for small teams. Tokens, components and docs in one place, with an AI agent called Pluto that does the drafting. This blog is where I’ll share what I decide, what I get wrong and what I learn about design systems along the way.

The rule

Here it is: Pluto proposes. A person approves.

Pluto never changes anything on its own. Ask it for a component, a contrast fix or release notes, and what you get back is a change request: the steps it took, the checks it ran and exactly what would change. Someone with review rights approves it, edits any value, or sends it back.

Why this rule

A design system is shared

When a token changes, every screen that uses it changes. An agent that edits a shared system directly is a fast way to lose the one thing a system needs: people trusting it.

Review is where the craft is

The tedious part of design system work is the drafting: finding every place a value is wrong, writing the fix in five places, checking contrast in Light and Dark. The valuable part is deciding. I want Pluto to take the first part and leave the second where it belongs.

Small teams can’t afford surprises

On a team of two, nobody has time to undo something an AI did quietly at 3pm on a Friday.

Two smaller rules come from the same idea. The credit cost of anything Pluto does shows before it starts, not after. And when credits run out, Pluto rests. It doesn’t lock your system.

Where Fenly is today

Fenly is in early access, and I’m opening it to small groups from the waitlist.

The first milestone is the core loop, and it works end to end:

1. Write a short brief, or start from a brandbook or a website.
2. Pluto builds the tokens and 12 starter components.
3. You review its change request and approve it.
4. You cut a versioned release and export it as CSS variables, a Tailwind theme, DTCG JSON or a React package.

Docs come next, then two-way Figma sync. Figma sync is the feature I’m most excited about, and it waits on purpose: sync only helps once the source of truth is solid. Syncing a shaky system to Figma just spreads the drift faster.

What’s next

Next on the blog: what a health score for a design system should count, and what it shouldn’t.

If you run a design system on a small team, I’d love to hear how you do it today. What’s the most tedious part of your week? Write to me, I read every message.