Nester
Dec 2024
Design System: systemizing a live product without slowing it down
Nester had no design system. I built one from a live product — screen by screen — while the roadmap kept moving
Context
Nester had no design system, because it never had time to need one.
When I joined Nester, Figma barely existed. The product was built straight into code — no documentation, no component library, no single source of visual truth. I wasn't designing on a blank canvas. I was systemizing a product already in production, with real users, while the roadmap kept moving at its normal pace.
Challenge
A coherent system had to be extracted, not invented — inside a stack that couldn't change overnight.
Extracting order from chaos
The question wasn't "how do I design the ideal system." It was: how do I pull a coherent system out of something that was never meant to be one — without stopping a single sprint?
Designing inside Bootstrap 4
Everything I documented had to survive the current stack. No components it couldn't support without a major rewrite. More than once, that meant documenting the pattern that was "correct given what already works" — not the ideal pattern in the abstract, knowing that trade-off was temporary.
Approach
Every screen already contained the system. Nobody had named it yet.
Rebuilding the product, screen by screen
I didn't have the luxury of pausing the product for two months to define foundations first. So I went the other way: I rebuilt every existing screen in Figma, one by one — over 80 screens — extracting the real patterns as I went: which spacing repeated, which colors were actually in use, which button variants existed even if no one had named them.
Over 80 screens, rebuilt one by one — not redesigned, extracted.
Mapping what already existed in code
Alongside that, I built a Notion database mapping every component already living in code — what it was, and where it lived.
Building for what was coming, not just what existed
I reviewed the upcoming product roadmap directly, to anticipate what the system would need before it became an urgent request — including the migration we knew was ahead, from Laravel to Next.js.
Tracking every component's migration status — not just documenting it.
Solution
One options-menu component. Twenty different contexts.
Foundations built to scale
Colors, sizes, and spacing are organized as a real scale, not one-off values. Most components carry their full set of interaction states — hover, active, disabled — built in from the start.
Color and typography foundations — the base scale every screen pulls from.
Full interaction states built in from the start: hover, active, disabled, error — across three sizes.
Same discipline applied to buttons — hierarchy, color, and every state matrixed out.
Proof at the product level
The Owners module: list, create, edit, detail, and sub-views, over ten screens, all built from the same pieces. The component library itself is master components with real variants, organized by domain — one single options-menu component reused across more than 20 places in the product: owners, contracts, incidents, remittances, financial items.
The Owners detail view — assembled entirely from reusable cards.
Documentation that keeps pace with shipping
Every time a new feature shipped, the Notion database got updated too — every component, every modal, every view, documented as it was built, not after the fact. That file documents each release and generates the mocks I hand off to developers at every kickoff, where the spec gets tested screen by screen so nothing gets lost between design and code.
Reflection & what's next
Not every corner is polished. That's a decision, not an accident.
Living with visible debt
Some pages grew as flat lists, as I needed them. Some frames are duplicated where component instances should be — the cost of iterating fast, alone, without time to formalize every piece. It gets reorganized when the next big shift arrives.
What comes after Bootstrap 4
The migration from Laravel/Bootstrap 4 to Next.js is already underway, and the next chapter is shadcn/ui — more flexible and consistent than what Bootstrap 4 allows today. That shift is also the moment the system stops being a file I maintain alone, and starts having more hands on it.
Key Takeaway
The system was already there. It just needed a name.
Building a design system for a product that's already alive is different from building one from scratch. It's not about imposing the "correct" system — it's about finding the pattern that already exists, scattered and unnamed, and naming it. The discipline wasn't getting it perfect on day one. It was keeping it alive, release after release.
