Vy for Bachable.io
Building a Design System for Faster Design to Shipping
Design Systems
UI Design
Design-Dev Collaboration
Component Library
Problem Description:
Bachable.io is a browser-based music notation tool. Write, collaborate, and publish professional sheet music with no local setup. The UI is complex: score editors, playback controls, export flows, real-time collaboration.
A good design is only as good as the product that is launched. I built a design system from scratch using shadcn/ui to give the team a shared foundation from day one: fast to use, consistent in output, and directly connected to the codebase. This project demonstrates my strength in collaborating with technical stakeholders to ship products in a fast and scaleable way.
About Bachable.io
Browser-based music notation powered by LilyPond. Publication-quality scores, instant preview, multi-format export. No installation required.
Context
The Team
A tiny cross-functional team of 1 designer and 1 developer. With limited resources, speed and consistency were both non-negotiable.
The Tech Stack
React, Tailwind CSS, and shadcn/ui. The techstack that enables small teams to ship beautiful and usable products fast.
Challenges
No shared foundation from day one
Without a system in place, designer and developer risked solving the same UI problems independently and diverging as the product grew.
Scaling Design with a Small Team
The team needed to design and ship new screens quickly without rebuilding the same patterns each time.
Project Overview
1. Foundation
Starting from scratch meant making the right decisions upfront. The first step was scoping what the system needed and how it would connect to the dev workflow.
Developer alignment: Spoke with the developer early on how they wanted to consume components, so the system would feel natural rather than imposed.
Choose the base: Selected shadcn/ui: aligned with the React and Tailwind stack, zero adoption friction, and components developer can own and modify directly.
2. Design Token Architecture
Tokens map semantic decisions (colors, type, spacing, radii, etc) to Tailwind CSS variables. Every choice in Figma maps (to the extent possible) to code. Each color has a role, not just a value. Designer and developer uses the same name, so no back-and-forth needed.
Designer in Figma
Developer in Code
Color token name
color/fg-primary
Color reference
fg-primary
Color token name in Figma
color/fg-primary
Color referenced in code
fg-primary
Primary color
Component name
Button/variant=primary
Component reference
<Button variant="primary">
Component name in Figma
Button/variant=primary
Component referenced in code
<Button variant="primary">
Primary button
3. Implementation
New screens were assembled from components, not designed from scratch. Design-to-code required minimal interpretation.
1×
Each decision made once, reused everywhere
0
Back-and-forth on "what shade of orange is this?".
Any
Screen built from the same source of truth