I Built a UI Kit - Just for Me.

I kept hitting the same wall.

I would open a new project, ask an agent to scaffold a screen, and get something that was technically fine. Then the next screen would have different spacing, different radii, and a different opinion about buttons. Not broken, not ugly, still frustrating.

That is when I built Couch Kit. It is my private UI kit, and yes, it is literally for me.

The UI Decision Tax Is Real

I am not trying to become a full-time designer. I am trying to stop re-deciding the same tiny UI details every week.

How much padding should this card have? Is this input too tall? Should this secondary button be outlined or quiet solid? These are small decisions, but they stack up, and they drain focus from the part I actually care about, which is product logic.

Coding agents made this better and worse at the same time. Better because they build screens fast. Worse because they can improvise visual style forever if you do not give them constraints.

I Can Kinda Sorta Design, And That Is Enough

My design goal is modest. I want someone to hesitate before saying, “an engineer definitely designed this.”

Couch Kit helps because I made the defaults good enough. If the default card, button, form field, and layout spacing are coherent, most screens already feel intentional before any special polish.

I did not build a giant public framework. I built a reusable set of opinions that reduces variance, especially when agents are writing first drafts.

Couch Kit Is My UI Memory

The simplest way to describe Couch Kit is this: it is stored UI memory.

It is a private package (@samuelcouch/couch-kit) with a finite vocabulary of primitives and patterns. I built it for Astro projects and Rails plus Inertia apps, because that is where I spend most of my time.

Under the hood, it has semantic tokens, shared typography choices, and a lot of reusable components that cover the boring-but-frequent product surface area. Things like buttons, form fields, cards, tables, dialogs, navigation, layout shells, and upload flows.

I also shipped two docs with the package: AGENTS.md and UI_PATTERNS.md. That part matters a lot. Components alone help humans. Patterns and rules help agents.

I Built It More For Agents Than For Me

Honestly, this is the real reason I built it.

When I gave agents open-ended prompts like “make this look clean and modern,” they produced decent screens that still drifted from screen to screen. Once I gave them a stable vocabulary, the output got calmer and more consistent.

After installing @samuelcouch/couch-kit in a consuming app, this is the command I run so local agent guidance is always in scope:

# app/frontend
npx couch-kit agents install --target app/frontend

That syncs Couch Kit guidance into the app and injects a managed block into local AGENTS.md, which means the agent stops inventing UI rules on every task.

I also changed how I write prompts. Instead of describing vibes, I describe constraints:

# prompt-template.txt
Build a contacts settings page using @samuelcouch/couch-kit.
Use DashboardLayout, Card, TextInput, Select, and Button.
Use existing spacing and radius tokens from the kit.
Do not create new component variants unless required.

That one shift changed everything. I stopped asking agents to “design” screens and started asking them to assemble known parts.

Private By Design, Useful By Default

“Private” is the feature. This kit does not need to satisfy every possible team, framework, or use case. It only needs to make my common workflows faster and cleaner.

That gives me freedom to keep it small, opinionated, and easy to evolve. If a component API is awkward, I fix it. If a pattern does not recur, I skip it.

The bigger point is compounding. A few hours spent encoding defaults saves a lot of future UI thrash. That is the same pattern I wrote about in Weird Knowledge Compounds.

Couch Kit is not a universal answer to UI. It is a personal operating system for building interfaces with agents, and it works.