Skip to content
Back to work

Client work · 2022 — 2024

Kubrick CMS & component library

E-learning platform, internal CMS, and the Storybook library between them

  • React
  • Next.js
  • Vue
  • Nuxt
  • Storybook
  • Apollo GraphQL
  • GSAP
  • Tailwind

The problem

Kubrick ran an e-learning platform and an internal CMS that were built by different people at different times, in different frameworks. The same button existed several times over, slightly wrong each time, and every new screen restarted that argument.

The approach

Treat the shared UI as its own deliverable. Components were built and documented in Storybook first, reviewed there by design, and only then composed into pages — which meant the conversation about a component happened once, in isolation, rather than repeatedly inside feature reviews.

The outcome

A component library both applications could draw on, with Storybook as the place design and engineering met. This is also where I started treating motion as part of the interface rather than a finishing touch, doing the interaction work in GSAP.

Architecture moves

  • Shared component library documented in Storybook as the review surface for design and engineering.
  • Features built across React/Next.js and Vue/Nuxt, depending on which application they landed in.
  • Apollo GraphQL for data fetching in the platform.
  • Tailwind for styling, with the component library owning the patterns rather than each page reinventing them.

Performance levers

  • Reusing reviewed components removed a category of layout and styling bugs before it reached QA.
  • Storybook made it possible to check a component's states in isolation instead of hunting for the page that reproduces them.

Engineering impact

  • Design handover became a conversation about a documented component instead of a screenshot.
  • Two applications converged on shared UI rather than drifting further apart.
  • Established the Storybook-driven workflow I have carried into every role since.

Challenges conquered

  • Building shared components for two different frameworks without letting the abstraction become the problem.
  • Retrofitting consistency into applications that already existed, which is mostly a negotiation exercise rather than a technical one.