Component Lab: a visual workspace for shadcn
A visual workspace for shadcn: browse, edit, or build from scratch. Four weeks of solo design and build, with AI as engineering partner.
Snapshot
- Role
- Designer & Developer
- Client
- Open Source / Personal Project
- Date
- Apr 2026
- Tools
Shadcn
Tailwind CSS
Visual Studio Code
Claude AI
Notion
Linear
GitHub
Netlify
Nextjs
Excalidraw
A note before diving in: this is a tool I built for myself, not a product designed for a wide audience. It's public and you're welcome to use it, but the user it was built for is me.
TL;DR
No visual layer for shadcn/ui. shadcn is the default for most Next.js projects now. Designers spec components they don't fully understand. Developers jump between docs, Figma, and IDE for prototypes that should take minutes.
Built solo, AI as engineering partner. Four milestones across four weeks. Browse any shadcn component, inspect how it's built, edit it visually, or build something new from scratch.
The thinking is what made it worth building. Planning, structure, UX principles, pushback when the AI drifted. AI made the execution faster; none of it would have been worth doing without the thinking first.
Context
Component Lab is what I wished existed.
Most of my work lives in shadcn now. Building anything custom meant starting from a blank file every time. That was the part I most wanted to fix.
Think Figma meets Webflow, built specifically for shadcn.
Working with AI
I treated the AI's environment as part of the design problem.
Locked stack, CLAUDE.md for persistent context, shadcn MCP for direct registry access. Linear held tickets with acceptance criteria upfront. Decisions documented as work progressed; lessons captured back into the AI's persistent memory.
CLAUDE.md
The half-day task that became a milestone
Every backlog item assumes a foundation that might not exist.
A small backlog ticket: copy a component as a starting point for a new one. Half a day, in theory. Scoping it revealed the tool needed to read any component's source and reproduce it exactly. Which meant the registry files needed to be current. Which meant upgrading React, Tailwind, and the entire shadcn registry first.
Half a day had become a foundation reset.
The right call was to follow it. A proper milestone was scoped for the upgrade. The original task was pushed to a follow-up. Several other backlog items unstuck themselves once the foundation was right.
One lesson from the upgrade: don't trust automated migration tools on your own source code. The official Tailwind tool handled config correctly, then made over 30 incorrect changes across 60 source files. Use them for config only.
The parser came after, with a strict quality bar: read any component file, reproduce it byte-for-byte on export. An automated test enforced it on every change. If a pattern wasn't recognised, preserve it exactly and move on. Reformatting would create silent problems downstream.
The false victory
Done means the old approach is gone, not that the new one is built.
After shipping a new parser and unified export flow, I called the next milestone done. Opened the app for the first time in hours. Parts of the interface were reading from the new parser. Others were still reading from a frozen snapshot of the old data. One panel showed eight size options for a component. The toolbar showed four. Two different products visible at the same time.
The honest diagnosis: I'd built the interesting parts and quietly skipped the tedious one. Getting the from-scratch builder onto the new structure. The milestone was called "Unified Editor." I had built a new engine. I hadn't unified anything.
The proper fix shipped the next morning. The done criterion was mechanical: a specific git grep had to return zero matches. When the criterion is mechanical, there's nothing to argue about.
Outcome
Four milestones shipped, all components passing round-trip fidelity.
A working tool with three modes: browse, edit, build from scratch. Exports follow shadcn conventions exactly. Live at comp-lab.netlify.app, source on GitHub. A fifth milestone covering polish, onboarding, and accounts is ongoing.
stat-card.tsx
What I took from it
The work for designers in 2026 is to set the AI up to do good work, then catch it when it drifts.
The decisions-before-code approach paid for itself; no time lost re-litigating mid-build. Design principles (Hick, Gestalt, Fitts) shaped how the editor surfaced complexity, not just how it looked.
The false victory above is the clearest example of catching drift. Define what done looks like before you start, not when you think you're finished.
