Quicknode design system
Two weeks instead of a year.
Quicknode had spent more than a year and hundreds of thousands of dollars on an unfinished system. We rebuilt it in two weeks as MeridianDS, and Q, Quill and Earn run on it in production.
Context
A design system that ships the product with the component. Designers review each component in a live catalog, engineers install it from a published package, and one contract carries web, desktop, chat and the marketing pages.
The company had already paid for the hard way. Roughly 10 people, more than a year and hundreds of thousands of dollars left it without a finished system. Accessibility and chat stayed unresolved, and every new product created another exception.
The decision
We bought the solved layer and built Quicknode's advantage
Common controls, buttons and dialogs were already solved on the market and were nobody's advantage. We spent the two weeks on what does set Quicknode apart: the brands, the technical icons, chat, motion, behavior at every screen size, and delivery.
One owner carried strategy, design, frontend, backend, package architecture, the catalog, the usage rules, the quality checks and the integration. That end-to-end ownership is what made the two weeks possible.
What we built
Two weeks, from a blank foundation to products in production
Week one, the foundation
The multi-brand repository, the six-package architecture, the visual foundations and the catalog.
Week two, the real work
Chat patterns, technical icons, motion, usage rules, accessibility checks and the first product integrations.
One component reaches four places
Every component is product code, a visible proof in the catalog, a written usage guide and a tested contract.
Accessibility as a release check
The previous system named no accessibility test at all. Here a component with no real proof does not pass.
Inside the product
Result
One owner, two weeks, a system already in production
A stalled year-long program became a multi-brand system with roughly 800 components and variants, six packages, usage guides, quality checks and three products in production.
The system can teach the next builder. The catalog shows the states it supports, the guides explain how each component is implemented, and the checks show where a product drifted from the system. It no longer depends on one person's memory.
- The MeridianDS core
- 2 weeks
- Products already on it
- 3
- Components and variants
- Roughly 800
- Published packages
- 6
The previous program had run more than a year and was still unfinished
Q, Quill and Earn run on the same foundation in production
The company's five product programs start from these instead of rebuilding them
Each one changes on its own without breaking the system into pieces
The catalog is the public reference. Private source and package access stay out.