EssayBy Taiki Noda / 野田大貴05 / 174 min read日本語版 →

Lean design systems as strategy: reading NN/g while running three micro SaaS alone

NN/g argues 2-to-5-person design-system teams aren't a constraint but a strategy. A solo author running three micro SaaS reads it back.

"Small design systems aren't a constraint, they're a strategy"

Nielsen Norman Group published a piece this morning arguing that 2-to-5-person design-system teams aren't a constraint but a strategic operating mode. Run small, move fast, don't build a giant in-house design-system department. The core of the argument, as I read it, is not "small is an acceptable option" but "small is the operating mode that wins under specific conditions." NN/g writes from an organizational angle, but I read it from a different one.

I run three products on the side — gpdf, gsql, renma — plus nadai.dev as the author hub that ties them together (I wrote about the reality of running multiple SaaS in parallel elsewhere). For a long time I assumed I had nothing that deserved the name "design system." When you stretch NN/g's framing from "2-to-5 people" down to "less than one full-time person," my situation starts to make sense.

My design system showed up after the fact, as the minimum shared ground

The honest description: what I actually maintain is "tokens for the lowest common denominator." A Tailwind preset with 6 colors, one font stack, four spacing steps. The same Button / Card / Container class combinations recycled across products. That is it. No Storybook, no Figma library.

This didn't start as strategy. While building nadai.dev as the author hub, I noticed that gpdf's landing page and renma's web would look unnatural unless they shared something visual. The cheapest way to keep visual consistency was to align tokens, so I unified them after the fact. The chronology, in my case, was "compromise first, retroactively shaped into something that looks like a strategy."

What NN/g lets me see is that there is nothing to be ashamed of in that state. If I look at this and think "this is not enough" and start investing in Storybook or a proper Figma library, my time budget collapses. The dividing line is whether you can keep it small — explicitly small — instead of upgrading on instinct.

The variant NN/g doesn't cover: "moonlight authors"

NN/g writes for in-house design-system teams. A 2-to-5-person team is small, but it still has dedicated business hours. For someone like me, running multiple products outside of a day job, that premise doesn't hold.

Concretely, my discretionary time after work is 15 to 20 hours per week, and most of it flows into feature implementation, OSS reviews, and writing posts (I described the day-shape of an OSS builder with a day job before). Design-system work alone gets less than one hour per week. When you compress NN/g's "2-to-5 people run as a strategy" down to less-than-one, the boundary where the principle holds shifts. In my case, I think design has to be treated as "a chain of disposable decisions" rather than "an asset to grow over time."

This is a constraint. I'm not yet confident that NN/g's frame can call it a "strategy" without modification. But just maintaining a deliberately minimal shared layer has the effect of making four products look like they came from the same author, which was a side effect I had not anticipated when I started. NN/g's framework targets in-house teams, but if you extract only the essence — making the explicit choice to stay small — it might import into moonlight authorship as well.

One specific failure worth recording: about six months ago I tried to introduce Storybook for the web UI around gpdf. I gave up after three weeks. Time spent writing component stories and time spent on actual product features pulled from the same discretionary pool, and Storybook lost every time. Since then, I have built "no dedicated hands for design" into the design system itself as a premise. NN/g's "small by design" reads, in my case, as a euphemism for the design choice of giving up on anything bigger.

What I plan to move next

If I were going to change something the day after reading NN/g, the first move is fixing the slight drift between buttons on gpdf.dev and nadai.dev. They are supposed to be tokenized, but I know there is a place where I wrote CSS directly six months ago. Next, I would normalize the heading line-height and color on renma's web and the gsql README page back to the nadai.dev preset.

When you run "small by design" with one person, the design system collapses unless you periodically take time to sweep up these tiny drifts. NN/g's piece implicitly assumes "dedicated hands" exist. With those absent, setting myself a monthly "drift sweep day" might be the realistic version. I'll find out whether the rule holds the next time I touch nadai.dev's docs. If I rewrite this post in six months on the same theme, it will probably be about why the "drift sweep day" failed to take hold. That's the more honest forecast.

Lean design systems as strategy: reading NN/g while running three micro SaaS alone

"Small design systems aren't a constraint, they're a strategy"

My design system showed up after the fact, as the minimum shared ground

The variant NN/g doesn't cover: "moonlight authors"

What I plan to move next

Other notable reads today