Neobank Design-to-Code Pipeline

Context

A fintech startup building a neobank from scratch on two platforms: web (React) and mobile (React Native), with a cross-functional team of over 50 people. I joined as the lead designer of a two-person design team. One of my first priorities was establishing how design decisions would travel from Figma to production code without getting lost along the way.

Problem

Building a neobank on two platforms means every design decision has to land in two codebases. Tokens defined once in Figma need to reach both without manual translation. Without that, every platform drifts on its own. The challenge wasn't fixing something broken. It was building the right infrastructure from day one so the design system could scale alongside the product.

Constraints

Pre-launch pace. The team couldn't pause feature work to set up tooling for months. The solution had to plug into existing workflows: Figma for design, BitBucket for code. Two people on the design side meant low maintenance once running. And every token reaching production needed a quality gate.

Approach

I set up Token Studio as the bridge between Figma and code. Token structures followed the W3C Design Tokens Community Group (DTCG) specification, a platform-agnostic JSON format where each token has a name, value, type, and description. This meant tokens were not just Figma artifacts but a shared, standards-compliant contract readable by any tool or codebase. Colors, spacing, typography, shadows, all defined in Figma, exported as structured JSON, pushed to BitBucket.

The pipeline runs two-way with mandatory PR review. Designers push token changes from Figma. Developers can propose changes from code. Every change goes through a pull request. Both sides review, both sides approve. Nothing reaches production without sign-off.

From BitBucket, tokens feed into Storybook and are consumed by both the React and React Native codebases from a single source.

Collaboration

Running a two-way pipeline means both sides own the system. Designers propose token updates in Figma, developers review the PR. Developers flag inconsistencies in code, designers verify in Figma. The PR became the meeting point. Most alignment happened in BitBucket comments, not in extra syncs.

For the broader cross-functional team, Storybook served as the living reference. Product managers checked component states there. QA used it to verify what shipped matched what was designed.

Solution

A fully operational design-to-code token pipeline serving two platforms from one source of truth:

Token Studio (Figma) as the authoring layer. All design tokens defined, structured, and maintained inside Figma by the design team.

BitBucket as the sync and review layer. Token changes exported as JSON, versioned in git, and gated behind pull requests with mandatory review from both design and development.

Storybook as the verification layer. Components rendered with live tokens, visible to the entire team.

React and React Native as the consumption layer. Both codebases pull from the same token source, eliminating platform drift.

50+ components built on this pipeline, each consistent across web and mobile from day one.

Impact

The design system grew to 50+ components across web and mobile within the first eight months, all powered by the same token source. Designers and developers worked from one pipeline. A change in Figma propagated to both codebases through a single PR. New team members onboarded faster because the system was self-documenting: tokens in Figma, history in BitBucket, rendered output in Storybook.

The mandatory review process caught inconsistencies before they reached production. No silent drift between platforms. No "which value is correct" conversations.

Reflection

Infrastructure is a design decision. Setting up the pipeline early cost a few days. Not setting it up would have cost weeks of alignment across a growing team and two platforms.

The two-way flow was the part that mattered most. A one-directional push from design to code would have worked technically, but it wouldn't have built shared ownership. When developers can propose token changes and designers review them, the design system belongs to the whole team, not just the design team.

Sources

1. Token Studio, Design Tokens Fundamentals
2. W3C Design Tokens Community Group
3. All images courtesy of Token Studio