What does Figma to React conversion actually involve?
Figma to React conversion is the job of turning static design frames into working React components that render the same interface, respond to users and load real data. Done well, it produces a small library of building blocks plus screens assembled from them.
The difference from plain HTML work is state. A Figma frame shows one moment; a React component has to know what happens before data arrives, when the list is empty, when a field is invalid, when a user without permission opens the page. Most of the real effort sits in those in-between moments, which designers often draw only once or not at all.
A sensible Figma to React project therefore moves in three layers. First, tokens: colours, spacing, typography, radius and shadows taken from Figma variables and styles. Second, components: each reusable element built once, with props for every variant. Third, screens: pages that arrange components, fetch data and handle routing. If a proposal jumps straight to the third layer, expect duplicated code and styling drift within a few months.
- Tokens are named values such as
color-surface or space-4. - Components are reusable pieces like
Button, DatePicker or DataTable. - Screens are routes that combine components with data and navigation.
Can AI tools convert Figma to React automatically?
AI and plugin tools can turn a Figma frame into React code in minutes, and the output often looks right in a browser. What they usually cannot do yet is decide which parts are reusable, name them well, and handle states that were never drawn.
Figma itself shows autogenerated code snippets in Dev Mode, and Figma’s help centre notes that Dev Mode is on paid plans and needs a Full or Dev seat. Third-party plugins and AI assistants go further and emit whole components. Treat their output as a sketch. Typical issues we see when cleaning it up: every frame becomes its own component with hard-coded colours and pixel values, layout relies on absolute positioning that breaks on other screen widths, buttons are div elements with click handlers, and nothing is shared between screens.
A practical middle path works well: let a tool produce a first pass for a complex layout, then have a developer rebuild it against your token file and component library. We are happy to start from an AI export you already have; the quote will say honestly how much of it survives.
AI export is fine for
Clickable prototypes, pitch demos, internal experiments and layouts you expect to redesign soon.
Hand-built components pay off for
Products with many screens, several developers, a long roadmap, accessibility requirements or a brand that will be restyled later.
How should a React component library from Figma be structured?
Mirror the Figma file’s own structure where it is sensible: primitives, then composed components, then page sections, with screens kept outside the library. When the folder tree matches the design file, designers and developers can find the same thing by the same name.
We usually set it up in four folders. tokens holds the generated variables. primitives holds the smallest pieces such as Text, Icon, Button, Input and Badge. patterns holds combinations like FormField, SearchBar, Card, Tabs and DataTable. sections holds larger blocks such as a pricing grid or an app sidebar. Screens live in the app’s routes and import from the library, never the other way round.
Each component gets its own folder with the component file, its styles if not using Tailwind, a Storybook story and a small test. Props are typed with TypeScript so a variant can only be one of the values the designer defined. If you run more than one product, the library can become a private package that each app installs; for a single app, a folder inside the repository is simpler and we recommend starting there.
Turning Figma variables into design tokens for CSS and Tailwind
Export Figma variables into one tokens file, then generate CSS custom properties from it, and point Tailwind’s theme at the same values. Every colour and spacing value in the codebase should trace back to a named token rather than a copied hex code.
Figma’s variables support values such as colours, numbers and strings, and modes let one variable hold different values for contexts like light and dark themes. That maps cleanly to code. A variable called color/surface/default becomes a CSS variable such as --color-surface, with a different value under a dark-theme selector. Spacing and radius variables become --space-* and --radius-*.
If you use Tailwind CSS v4, its documentation explains that theme variables defined with the @theme directive decide which utility classes exist, and that Tailwind also generates regular CSS variables for them so tokens can be used in inline styles and arbitrary values. So a token like --color-brand-500 gives you bg-brand-500 and text-brand-500 automatically. Our Tailwind CSS developer page goes deeper on theme setup. If you prefer CSS modules or plain CSS, the same variables work without Tailwind at all.
The table further down shows how a handful of Figma variables travel through to CSS and Tailwind.
Figma component variants become React props
Every Figma variant property should become a typed React prop with the same name and values. When a designer adds a new variant, the developer adds one value to one type, and TypeScript flags every place that needs attention.
Take a button with Figma properties Type (primary, secondary, ghost), Size (sm, md, lg) and State (default, hover, pressed, disabled). In React, type and size become props: variant and size. Hover and pressed are not props at all; they are CSS states the browser handles. Disabled becomes the native disabled attribute so it works for keyboard and assistive technology too. Loading, which designers often forget, becomes an extra prop that shows a spinner and blocks double submission.
This translation step is where much of the quality lives. A converter that copies every Figma state into a prop ends up with components that fight the browser. A developer who understands both sides keeps the API small: few props, sensible defaults, and composition for the rare cases. If your Figma file uses Code Connect, Figma notes that this feature is available on Organization and Enterprise plans and lets teams show their real component code inside Dev Mode, which helps once the library exists.
Why document Figma to React components in Storybook?
Storybook gives every component a page where designers, testers and new developers can see and try each state without clicking through the app. Its own documentation describes it as “a frontend workshop for building UI components and pages in isolation”.
For a Figma to React project, Storybook becomes the living counterpart of the design file. Each story shows one state: the primary button, the disabled one, the table with no rows, the form with three validation errors. Designers review stories instead of hunting through staging for an empty state that is hard to trigger. When a token changes, everyone can see the effect across the library in one place.
We deploy Storybook to a private URL you control, add controls so reviewers can change props live, and write short usage notes on components with rules, for example “use Dialog for confirmations, not for forms longer than five fields”. Storybook also makes visual and accessibility checks easier to automate later. It is optional on a five-page marketing site, but on an app with more than a dozen components it pays for itself in review time alone.
How much does Figma to React cost per screen?
There is no honest single price per screen, because screens vary more than tenfold in effort. With us, a marketing site from Figma starts at ₹10,000 (US$150), an ecommerce front end starts at ₹50,000, and a web app front end with API wiring starts at ₹60,000 (US$900).
Quotes from different developers vary widely. Rather than comparing totals, compare what each quote says about these drivers:
- Unique components: 15 well-defined components versus 60 near-duplicates.
- States drawn in Figma: are empty, loading, error and permission states designed, or left to guesswork?
- Complex widgets: data tables, date ranges, drag-and-drop, rich text, charts.
- Responsive frames: mobile and desktop both designed, or desktop only?
- Data wiring: static screens versus live API calls, forms and validation.
- Documentation: Storybook, usage notes, test coverage.
- Accessibility target: basic keyboard support or a formal WCAG level.
For a feel of how front-end work fits inside a whole product budget, see web application development cost. Every number on this page is a starting price; your itemised quote shows the real one.
How long does a Figma to React project take?
A marketing site of a few pages takes about two to three weeks; an app front end of 20 to 40 screens usually takes six to twelve weeks. The component library takes the first chunk of time, after which screens go quickly.
Here is the rough shape. Week one: read the Figma file, list components and states, flag gaps, set up the repository, tokens and Storybook. Weeks two to four: build primitives and patterns, reviewed in Storybook. From then on: assemble screens, connect the API, handle routing, authentication and edge cases. Final week: cross-browser and device testing, accessibility checks, performance, handover.
Two things stretch timelines more than anything: a Figma file that changes heavily after components are built, and a backend that is not ready when screens need it. We plan around both by agreeing a design freeze for each component group and by using mock data that matches the API contract, so the front end is never blocked waiting. General delivery ranges for software are also covered in how long it takes to build a website.
Preparing your Figma file for React: a designer’s checklist
A tidy Figma file can cut a Figma to React quote noticeably, because the developer spends less time guessing. The most valuable fixes take a designer a day or two.
You do not need a perfect design system. You need consistency and a few frames showing what happens beyond the happy path. If some of this is missing, we list the gaps in the quote rather than silently inventing answers.
- Colours, spacing and type set as variables or styles, not typed by hand per layer
- Buttons, inputs and cards built as components with variants, not detached copies
- Auto layout on frames so we can see how things stretch and wrap
- At least one mobile and one desktop width for each key screen
- Empty, loading and error states for lists, tables and forms
- Real-length sample content, including long names and Hindi or regional text if used
- Icons as components or an icon set name, not flattened images
- Notes on interactions the static frames cannot show
Where the Figma file stops: state, data and API wiring
A Figma file describes what the interface looks like; it does not say where data comes from, what is cached, or what happens when two users edit the same record. Those decisions belong in the Figma to React scope, or the screens will look finished but do nothing.
We agree the data contract early. For each screen, we write down which API endpoints it calls, what shape the data has, and which user roles can see what. That becomes TypeScript types shared by the components and the fetch layer. For server data we typically use a query library that handles caching, retries and background refresh; for local UI state, plain React state or context is usually enough, and we avoid heavy global stores unless the app genuinely needs one.
Forms deserve their own mention. A form in Figma is a set of boxes; a form in React needs validation rules, server error messages, disabled states while submitting, and protection against double submission. If your backend does not exist yet, one of us can build it too, or another of us can set up the hosting and database, but that is quoted as its own section so the front-end price stays clear. The freelance API developer page covers backend work.
Accessible React components from a Figma design
Accessibility is decided at the component level, which is good news: fix the Dialog once and every modal in the app behaves. Figma rarely shows focus rings, keyboard behaviour or screen-reader labels, so the developer has to add them.
Our baseline for every component: use the native element where one exists (a button is a button, a link is a link), show a visible focus style that matches the brand, support keyboard use for menus, tabs, comboboxes and dialogs, trap and return focus correctly in modals, and give icon-only buttons an accessible name. Colour contrast is checked against the token values, so a low-contrast grey is flagged before it spreads across fifty screens.
For complex widgets, building from scratch is rarely the right call. Well-tested headless libraries provide keyboard and ARIA behaviour for comboboxes, date pickers and menus, and we style them with your tokens so they look exactly like the Figma frames. If you need an audit against a specific WCAG level, say so up front; our website accessibility audit page explains how that is scoped.
Figma to React in Next.js or Vite, and what it means for SEO
Choose Next.js or a similar server-rendering framework for public pages that must rank; choose Vite for logged-in apps where search engines never go. Both can use the same component library.
A plain client-side React app sends a mostly empty HTML page and builds the interface in the browser. That is fine for a dashboard behind a login. For marketing pages, product pages and blogs, you want HTML with the real text delivered from the server, correct title and meta tags per page, fast loading and clean URLs. That helps Google and Bing, and it helps AI assistants that summarise pages, because they read text in the HTML.
A common setup we build is one repository with two apps: a Next.js marketing site and a Vite or Next.js product app, both importing the same components and tokens. The brand stays identical across both, and a colour change in Figma flows to both through the tokens file. If you are already on a client-only React app and need the public pages to rank, see React to Next.js migration. Nobody can promise rankings, but server-rendered, fast pages remove the technical obstacles.
Who owns the code after Figma to React conversion?
You do, from the first commit. The repository, Storybook deployment, hosting and any package registry sit in accounts you control; we work inside them.
At handover you should receive the component library with typed props, the tokens file and the script that regenerates CSS from it, the deployed Storybook, the assembled screens, a README covering setup, scripts and deployment, and a short guide for adding a new component the same way. If your in-house developers will take over, we can walk them through the structure on a call and review their first few changes.
After launch, two months of maintenance are free, covering fixes and small adjustments. After that, care starts at ₹8,000/mo a month for dependency updates, React and framework upgrades, and small additions. We do not lock anything to our own accounts, so you are free to hand the codebase to anyone later.
Red flags in a Figma to React delivery
The biggest red flag is a delivery where every screen has its own copy of the same button. It looks finished today and becomes expensive the first time the brand colour changes.
Before paying the last milestone, spend thirty minutes checking. Search the code for hex colour values; there should be almost none outside the tokens file. Press Tab through a form and a modal; focus should be visible and move logically. Resize the browser from wide to narrow; nothing should overflow sideways. Open Storybook; each component should show its variants and states. Ask how to add a new variant to a button; the answer should be short.
- Colours and spacing hard-coded in hundreds of places
- Clickable
div elements instead of buttons and links - No empty, loading or error states anywhere
- Absolute positioning copied from the Figma canvas
- No TypeScript types for props or API data
- Code living only in the developer’s own repository
Working on Figma to React with a team in India
Figma to React work runs well remotely, because the whole job lives in shared files: Figma, a Git repository, Storybook and a staging URL. Reviews happen in comments and short calls; there is nothing to visit in person.
For Indian clients, we share your working hours, reply on WhatsApp seven days a week and discuss in English or Hindi. Payments go by UPI or bank transfer in milestones, with nothing billed before written approval. Two India-specific points often shape the components: many users are on budget Android phones with limited memory, so we keep bundle size and re-renders in check; and forms may need Hindi or regional-language labels, Indian phone number formats and PIN code fields, which should be part of the design system rather than one-off fixes.
Overseas clients get quotes in USD and pay by Wise, bank wire or PayPal. Our IST day overlaps with European mornings and US evenings, which suits a review-then-build rhythm. More on this in hiring Indian developers.
Worked example: a hypothetical logistics dashboard from Figma to React
Suppose a freight startup in Nagpur has a Figma file with 32 screens for a shipment-tracking dashboard, designed by a freelance designer, and a backend team building the API in parallel. This is a hypothetical scenario to show scoping, not a past project.
We would start by auditing the file. Say it has 11 button styles that are really 3 variants with sizes, 4 slightly different table designs that can become one DataTable with options, and no empty or error states. The quote would list 24 components, a tokens file with light and dark modes, Storybook, and screen assembly, plus a note asking the designer for the missing states.
The build would use TypeScript, Vite for the logged-in app and Tailwind with theme variables generated from the Figma tokens. Screens would run on mock data matching the agreed API contract, so work continues while the backend catches up. The shipment table would support sorting, filters and pagination on the server, and the map view might use a mapping library inside a component with a list fallback for low-end phones.
A scope like this would typically be quoted from the custom web app band, starting at ₹60,000, with the component library and each screen group as separate lines.