From your designers' Figma to a fast Next.js storefront

Components with variants, not pages drawn as flat frames. Auto layout on anything that has to stretch, because it tells us how a product card behaves between breakpoints instead of leaving us to guess. Variables, or a Tokens Studio export, for color, type and spacing, so the code uses the same names your designers do and a palette change is one edit. Frames at a 375 px phone width and a 1440 px desktop width at minimum, plus tablet wherever the layout genuinely changes. Dev Mode access saves a round of screenshots and measurements. The part files most often skip is the states, and every missing state comes back to your designers as a question or gets improvised by a developer, which is worse.

• Empty cart, a search with no results, and a category holding a single product
• Out of stock, on sale, and a variation that cannot be bought
• Checkout and login errors drawn, not just the happy path
• Loading states for filters and add-to-cart, so nobody invents a spinner

Agree the targets with the client before the build starts: Google's Core Web Vitals thresholds of LCP under 2.5 seconds, INP under 200 ms and CLS under 0.1, measured at the 75th percentile of real visits, on the templates that carry revenue. Then the build is held to them, and a design choice that threatens one surfaces while it can still be changed. That conversation goes better with a number attached. A full-bleed hero video that pushes LCP past 2.5 seconds on a mid-range Android is a design decision, not a developer complaining, and so is a third web font or a scroll animation on the product grid. A budget agreed after launch is a renegotiation, and it is usually lost the week the client's marketing team adds its tags. Core Web Vitals covers what is being measured and where the field data comes from.

Fidelity is reviewed per component before it is reviewed per page. Each component lands in Storybook with its variants laid out, next to the Figma frame it came from, so a designer approves the product card once. Chromatic or a similar visual diff then flags any later change that moves a component nobody meant to touch. Page-first review is the slower order: the same card defect gets reported six times, once per template, and fixed in six places. We agree up front what counts as a defect. A value that does not match its token is one; a sub-pixel difference between Figma's renderer and Safari is not. Where the browser genuinely cannot match the frame, such as a title set on a fixed height in Figma meeting a real product name that runs to three lines, you get the case and a proposal instead of a quiet compromise. Rebuilding a client's existing design faithfully is a different job with its own method, covered on keeping your design when you migrate.

Every pull request gets its own preview deployment on Vercel or Netlify: a URL your designers open on their own phones, comment on and compare against the frame. Rounds run in a fixed order. Component library first, then the templates that carry revenue (home, category, product, cart), then the full flow on staging with the client's real catalog, which is where a sale badge meets a 90-character product title for the first time. The number of rounds per template goes into the scope. When the file arrived final, two rounds cover it. A product page heading into a third round is almost always a design still being decided, and that is cheaper to settle in Figma than in code. Book the review time into the studio's calendar as well, because a preview that waits four days for comments moves the launch by four days.

Your design replaces the theme layer and nothing behind it. The Next.js storefront reads the catalog from WooCommerce and runs the cart through its Store API, while the client keeps WordPress for products, stock, orders, tax and payments and their team keeps the admin it knows. That boundary is what makes the proposal saleable to a cautious client; the staged switch is described on WooCommerce headless migration.

Redirect mapping, metadata and structured data parity, and Search Console coverage monitoring after launch are part of the build, because a redesign that loses organic traffic is blamed on the agency however good it looks. A client whose traffic is entirely paid and whose site has under 50 indexed URLs is not carrying that risk, and pricing SEO parity into that project is padding.

The repository goes to your GitHub organization or the client's, never ours, and Storybook goes with it as the working reference for every component and state. Designers get the most out of that. The next campaign page can be drawn from components that already exist in code, and a new variant becomes a small ticket instead of a new build. Deployment configuration lives in the repository with every environment variable documented. Next.js is MIT-licensed open source, and nothing in the build needs a runtime license or a component library only we can compile. A partner who leaves your client unable to change a heading without a purchase order is a cost the agency pays when that arrangement sours.

Fixed price against a written scope, an audit priced first wherever the client's setup is unknown, your margin on top, and our published pricing starting at $1,999. NDAs, staying invisible to the client, and who answers the Friday-evening email when checkout is down are set out on white label WooCommerce development.

If the client needs a simple brochure store on a modest budget, a well-configured theme is the right answer and we will say so. If the design is not finished and the timeline assumes it is, the build surfaces that gap at the most expensive moment. A studio that wants to hand over the file and move on to the next client will also struggle here: the review rounds above need a designer answering within a day or two, and without one the build either stalls or guesses. And if the client's real problem is demand rather than the storefront, a fast site changes very little, which is worth establishing before anyone signs.