The Minimum Design System That Keeps a Solo Founder's App Consistent

Somewhere around screen fifteen of my last product, I noticed the buttons had stopped agreeing with each other. Some were 8px radius, some were 6px, one was fully rounded because I had copied it from a landing page component and never checked. The spacing between form fields drifted from 16px to 20px to 12px depending on which day I built the screen. Nothing was broken. It just looked like four different people had worked on it, and there was only ever me.

My first instinct was to fix it by going big. Set up a proper design system. Tokens file, a component library, maybe Storybook so I could see everything in isolation. I got about two hours into that before I noticed what I was actually doing: building infrastructure for a team that did not exist, to solve a problem that a much smaller thing could solve just as well.

The full design system is solving someone else's problem

Design systems like the ones design teams write about, with token tiers, component governance, contribution guidelines, versioned releases, exist to solve a coordination problem. When you have ten designers and forty engineers touching the same product, you need a shared source of truth or everyone quietly reinvents the button. The system is a treaty between people who do not talk to each other every hour.

You are one person. You do not have a coordination problem. You have a memory problem. You built the primary button with a certain shadow and radius in March, and by August you have forgotten the exact values and eyeballed a new one that is close but not identical. The treaty you need is with yourself, and it does not require a components package, a design tool file with fifty linked variants, or a review process. It requires you to write the four or five decisions down somewhere you will actually look again.

This matters because building the heavy version has a real cost beyond time. A token system with too many options gives future-you more knobs to misuse, not fewer. If your spacing scale has eleven values, you will use all eleven inconsistently. If it has five, you physically cannot drift very far.

The real problem is drift, not the absence of a system

Name the actual failure mode and the fix gets obvious. It is never that screen one looks bad. Screen one always looks fine, because you designed it fresh with full attention. The failure is that screen forty does not match screen one anymore, and nobody, including you, can say exactly when it stopped matching.

Drift happens for boring reasons. You are moving fast and you eyeball a value instead of looking it up. You copy a component from an old screen but forget one property. You add a new feature that needed a new pattern, invent one on the spot, and never go back to reconcile it with the old pattern. Each individual decision is reasonable. The sum is a product that reads as unpolished even though every screen, taken alone, is fine.

This is also exactly the failure mode that gets worse, not better, once you start using an AI agent to build screens for you. An agent has no memory of the decision it made on screen one when it is generating screen forty, unless you give it that memory explicitly. Left alone, it will invent a slightly different shade of grey and a slightly different border radius every single time, because nothing is stopping it from having an opinion in the moment. Speed without a memory is a drift machine.

The minimum viable system

Here is what I actually use now, on every product, including the ones I build with an agent doing most of the typing. It fits on one screen and takes about twenty minutes to write the first time.

• A spacing scale. Multiples of 4, five or six values total. Every margin, padding, and gap comes from this list. Nothing in between.
• Three or four type sizes. A large one for headings, a body size, a small one for captions and labels. Maybe one more for a hero if you need it. Pick weights too, usually just regular and semibold.
• One accent color. Used for the one or two things per screen that need it: the primary action, an active state. Everything else is your neutral scale.
• One border radius, one shadow. Reused everywhere, not re-decided per component.
• A written rules file. Not a components library. A short document that states the above in plain language, plus two or three sentences of taste: what the product should feel like, what to avoid.

That last item is the one people skip and it is the one that matters most once an agent is in the loop. A components library is something you consult. A rules file is something an agent, or a future version of you, reads before generating anything. It is closer to a CLAUDE.md for your interface than it is to a Figma library. Short, direct, and read every time, not browsed occasionally.

DESIGN.md, starter values

Spacing scale (px): 4, 8, 12, 16, 24, 32
  - use only these, no in-between values

Type sizes:
  - 28px / semibold, page titles
  - 16px / regular, body text
  - 14px / regular, secondary text, labels
  - 12px / medium, captions, meta

Color:
  - 1 accent color, used only for primary actions and active states
  - neutrals: 3-4 grays, from near-white to near-black
  - no other colors unless the data requires it (status, charts)

Shape:
  - border-radius: 8px, everywhere, no exceptions
  - shadow: one soft shadow, used for elevated surfaces only

Rules:
  - every number above is chosen once and reused, never eyeballed
  - if a new pattern is needed, add it here before using it twice
  - product feels: quiet, direct, no unnecessary color or motion

Notice what is missing. No component variants matrix. No dark mode token layer unless you actually ship dark mode. No versioning. No naming convention for tokens beyond what is in the file itself. Every one of those things is legitimate at a certain size, and a waste of an afternoon below it.

Enforcing it is the part that actually matters

Writing the rules file is the easy twenty minutes. The part that actually keeps you consistent is making sure it gets read every single time a new screen gets built, not just the first time. A rules file you wrote once and never open again is decoration.

This is where having an AI agent in the loop is a genuine advantage over doing it by hand, not just a shortcut. A person gets tired of re-reading their own style guide on screen thirty. An agent does not get tired, and if the rules are attached to every generation instead of living in a tab you forgot to open, they get applied every time instead of most of the time.

That is the actual gap Krit is built to close. It is the design layer for agent-built apps: an infinite canvas where an AI agent designs real, interactive screens, and your brand rules get captured once and applied to every screen after that, so screen forty follows the same spacing scale and the same accent color as screen one without you having to re-explain it. You describe what you need, the agent builds it against the rules you already set, and you review the result instead of re-litigating the radius value for the tenth time. When you are ready, it exports to HTML and CSS, React, Next.js, or Vue.

The mechanism is the same whether you use a tool like that or just discipline and a markdown file open in a second tab. The rules have to be present at the moment something new gets built, not consulted after the fact when the inconsistency is already shipped.

When to graduate to a real system

The minimum system is not a permanent state, it is a starting state sized correctly for where you are. There is a real point where you outgrow it, and it is worth naming so you do not either graduate too early, wasting time on infrastructure, or too late, watching the product visibly fracture.

The signal is not revenue or headcount round numbers, it is coordination. The moment a second person is regularly shipping UI, whether that is a hire, a contractor, or an agency you brought in, your rules file stops being a note to yourself and starts being a contract between people. That is when it earns real tokens, a components package, maybe a linter that flags an off-scale value. Before that point, you are paying design-system tax for a design-system problem you do not have yet.

A second, quieter signal: your product surface gets wide enough that you genuinely cannot hold it in your head. If you have forty screens and a handful of flows, five spacing values and four type sizes are plenty to remember. Past a certain size, real tooling starts paying for itself, and that is a good problem, it means the product grew.

The short version

A full design system is built to solve a coordination problem between people. As a solo founder you have a memory problem, and the fix is a short, written set of constraints, not a components library. Pick a spacing scale, three or four type sizes, one accent color, one radius, one shadow, and write it down somewhere it actually gets read every time you build something new. If you are working with an AI agent, that rules file is the difference between a product that looks like one hand built it and one that visibly did not. Graduate to a real system when a second person is shipping UI regularly, not before.

If you want the fuller version of how I brief an agent day to day, I wrote that up in how to build UI without a designer. And if the next problem after consistency is getting people to actually visit the thing you built, what makes a landing page convert is the natural next read. If you are comparing tools for this, see Krit vs Figma, and if you want a running start on prompts that keep an agent inside your rules, there is a library at /prompts.