Nester
2024
Design System
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.
The Notion database in action — opening a single component to see its full migration record.
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.
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 same options-menu component in three different contexts — owners, contracts, and financial items.
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.
That Notion database was maintained with the help of a Notion AI agent, which helped structure and update component entries as new screens shipped — keeping documentation in step with releases instead of falling behind them.
Impact
+95% faster brand updates
A global brand update went from weeks to hours, thanks to a token-based foundation.
~70% faster screen design
A new screen went from 4–8 hours to 1–2, once components and patterns already existed.
80+ screens
Every existing screen in the product was rebuilt and systemized in Figma — not redesigned, extracted from what was already live.
20+ reuse contexts
One options-menu component reused across owners, contracts, incidents, and financial items.
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.
Every Nester case study since — Contract Templates, Digital Signature, Bank Reconciliation, Document Management — ships from this same foundation.
