How I enabled start-up founders to scale design/development

Founders don't have time to build what they know they need.

The founders of UY understood design systems. They'd seen them work. They knew exactly what the absence of one was costing them in dev time and QA cycles. But knowing the solution and having the runway to build it are two different things — and for a small founding team, the product always wins over the infrastructure.

That's the gap I fill. Not design leadership, not feature design — infrastructure. The part that gets perpetually deferred because it's important but never urgent enough to justify pulling a founder away from the product.

Starting with a full inventory, not a redesign

Before touching a single component, I scoped the work. The founders needed to understand what existed, what needed to change, and what the handoff would look like — in a format they could track alongside their other priorities. I built the full project plan in Notion so they had visibility without needing to be in Figma every day.

The inventory phase covered every component in the existing Figma file: naming, usage, duplication, and whether it matched what was actually in the codebase. That audit became the prioritization layer — what to consolidate first, what to leave for later, and what could be deprecated entirely.

Documenting two systems to create one

The type audit was one of the first concrete deliverables — and one of the most clarifying. I documented every typeface, size, weight, and line-height in use across the product, mapped to the screens where they appeared. The goal wasn't to pick a winner arbitrarily; it was to show the founders exactly what they had and make the consolidation decision obvious.

Once the audit was documented, the path forward was straightforward: one canonical type scale, applied consistently, built into Figma styles so designers couldn't accidentally introduce a third system.

Building the library the team would actually use

A design system is only as good as its adoption. I structured the Figma library around how the team already worked — components named to match what developers called them in code, variants surfaced the way designers reached for them, and coverage prioritized by what shipped most often.

Before publishing, I synced naming conventions with the development team. This step is often skipped when designers build systems without engineering alignment, and it's the source of most implementation drift. We agreed on a shared vocabulary up front so the component names in Figma matched the component names in the codebase exactly.

A consistent product the team could move fast in

The system shipped into a live, revenue-positive product — so it had to work immediately. The mobile screens below reflect the consistency that became possible once the library was live: typography rendering uniformly, components behaving predictably, and no more visual drift between screens designed by different team members.