What this covers
You’ll have a system your squads can use next sprint without asking for exceptions: shared tokens, a core component set with states, and a handoff that engineering can implement and keep up to date.
We’ll build a design system build that gives design and engineering one source of truth, with parts that ship in code without turning into a “police the library” job. Next, we’ll confirm what’s in scope and book the kickoff.
We start by naming what’s real in the product today, then we decide what becomes standard. We inventory screens, group patterns, and agree a token model and naming that matches how your engineers build. Then we ship a core set of components with states and accessibility spelled out, and we set up governance so new work lands in the system instead of beside it.
A bit about us
We’re Mango Court Studio, and we build design systems for product teams that need one set of decisions to travel across squads. We came to this work through the same failure most teams hit: a beautiful library that didn’t survive contact with engineering. We learned to start with inventory, name things the way code names them, and ship rules people can follow.
Teams pick us when they want something engineers will actually implement. We don’t stop at “components in Figma”. We write the states, behavior, and accessibility notes that answer the questions engineers ask in standup, and we set up a contribution path so squads add to the system instead of cloning it.
Meet the team
You’ll work directly with the people doing the build, and you’ll know who to go to for each decision.
Team
Megan Carlisle, Design systems lead. Megan leads the system structure, runs the naming and token workshops, and keeps decisions consistent across components and documentation.
Andre Navarro, UI designer. Andre builds the component library in Figma, including variants, responsive behavior notes, and the patterns teams repeat across screens.
Priya Desai, Accessibility specialist. Priya specifies accessibility, states, and interaction requirements, and she calls out what needs design or engineering changes to meet WCAG.
Caleb Whitman, Design technologist (Figma). Caleb is our Figma technologist. He sets up tokens, variables, libraries, and the reference site so handoff stays usable after launch.
Recent work
A few recent design system builds we’ve shipped, showing different products and what changed once teams had one source of truth.
Portfolio
SaaS UI inventory audit. We audited a mature SaaS app and reduced 28 button styles to 6, with a token model that kept spacing and color decisions out of one-off components.
Figma component library build. We built a core library of 42 components with documented states and variants, so squads could reuse patterns without recreating them per feature team.
Tokens and reference site setup. We set up tokens, naming, and a lightweight reference site so engineers could pull decisions quickly. Teams cut review churn by catching mismatches before QA.
“Engineering stopped guessing, and design reviews stopped reopening the same decisions.”
Product design lead, a SaaS team with multiple squads
UI inventory and audit deck
A categorized inventory of screens and patterns, with a clean list of what becomes a component, what stays a pattern, and what gets retired.
TOKEN MODEL AND NAMING SPEC
A token structure and naming rules your designers and engineers can both follow, with examples for color, type, spacing, radius, and elevation.
FIGMA COMPONENT LIBRARY
A built component library in Figma with agreed variants, responsive behavior notes where needed, and conventions teams can use without re-learning the system.
States and accessibility spec
A written spec for states, interactions, and accessibility requirements, including keyboard behavior and focus, so implementation matches design intent.
DEVELOPER HANDOFF PACKAGE
A handoff bundle that ties components to tokens and usage notes, so engineers can implement without hunting through threads or reinterpreting frames.
REFERENCE SITE SETUP
A set up and organized reference site that mirrors the system structure, with pages for tokens and components so the system stays easy to look up.
Pricing
Choose the tier that matches how many product areas need to land in “release one”, and how much governance you want us to set up with you.
Priced items
Get started
If you want to lock in the build window for your next release, the next step is to sign and book the kickoff.
1. Sign the proposal to confirm the design system build. 2. Pay the 30% booking invoice within 14 days. 3. Schedule the kickoff and invite design and engineering to the first workshop.
Signature
Fee summary
Are you building this for Figma, code, or both?
We build the source of truth in Figma, and we shape it around code constraints from the start. You’ll get token naming and component decisions that map cleanly to implementation, plus a reference site your engineers can use while they build.
WHAT DO YOU NEED FROM OUR ENGINEERS, AND WHEN?
We need an engineer in the token model and naming workshop, and a short review window each week for the core components as they land. We’ll collect constraints early, then keep questions batched so engineering is not context-switching daily.
How do you stop teams from making one-off variants?
We write rules teams can follow under sprint pressure: which props are allowed, what counts as a new variant, and where exceptions go. We also set up a contribution path, so “I need a new thing” becomes a request, not a fork.
WHAT DOES “DONE” LOOK LIKE FOR THE FIRST RELEASE?
Done means your next release can ship with a defined set of core components, tokens applied, and states specified, plus a handoff your engineers can implement without rewriting decisions. We’ll agree the “release one” list in the audit phase.
Payment
A 30% deposit is due to book the design system build when you sign. The remaining 70% is due when we hand over the finished work. Invoices are payable within 14 days of the invoice date.
Scope changes. If the design system build scope changes after the audit, we will write the change down with the impact on timeline and price. We will not start the added work until you approve it in writing.
What we need from you. We will need access to your Figma files and any existing UI guidelines at the start. We also need an engineer in the token model and naming workshop, plus a weekly review window for components.
Reviews and turnaround. We will batch questions and decisions, then send review items on a weekly cadence. When feedback sits longer than the agreed review window, the schedule moves with it so the work stays sequenced and buildable.
Ownership
Once the final invoice is paid, you own the Figma component library, token model and naming spec, states and accessibility spec, and developer handoff package we produced for the design system build.
Reference site setup. We will set up the reference site structure and publish the agreed initial content. Ongoing hosting costs and long-term site updates stay with your team unless we agree to a separate maintenance scope.
Accessibility. Priya Desai will specify accessibility requirements, states, and behavior in the system. Final compliance depends on implementation in code, so we treat the spec as the build target and review questions as they come up.
Cancellation. If you need to pause or cancel, tell us as soon as you can. Work completed up to that point is billable, and we will package what is finished so your team can pick it up without guesswork.
