Figma to Shopify: what a build actually involves

What "pixel-accurate" can and cannot mean

A Shopify build from a finished design should look like the design. That is the easy part and it is not what makes builds go wrong.

What makes them go wrong is everything the design did not say. A Figma file shows one state of one screen at one width. A storefront has to handle the product with a fourteen-word title, the collection with three items and the one with three hundred, the variant that is out of stock, the discount code that fails, the customer whose browser is 320 pixels wide, and the moment the marketing team adds a fourth navigation item.

A good build makes decisions about all of that. A cheap one guesses, and you find out which is which about six weeks after launch.

What a developer actually needs from the file

If you are commissioning a design that someone else will build, these are the things that decide whether the build is execution or invention.

• Both widths drawn. Mobile at 390 and desktop at 1440, at minimum. If only desktop exists, the mobile layout is being designed by the developer, at build rates, without a review.
• A type scale and a colour system, not a set of one-off values. Twelve text sizes that are almost the same is twelve decisions someone has to reconcile.
• The states. Hover, focus, disabled, loading, empty, error. Empty and error are the ones always missing and always needed.
• Real content, or at least realistic content. A product card designed around a three-word name will break on your actual catalogue.
• The awkward pages. Cart, search results, 404, and the account pages. They are unglamorous and they are where buyers get stuck.

Anything on that list which is missing gets decided during the build. That is not automatically bad — it is bad when nobody knows it happened.

Sections, or you will be back

Shopify's theme editor lets a merchant reorder, edit and remove parts of a page without a developer. Whether your store actually works that way is a build decision.

A build that hardcodes the homepage is faster to produce and cheaper to quote. It also means every future copy change is a ticket. A build where each block is a section with proper schema costs more up front and hands you a store you can run.

Ask which one you are buying. The answer is rarely in the quote.

The performance budget is a build constraint, not a later project

This is the part most worth insisting on.

Speed is far cheaper to build in than to retrofit. The decisions that decide whether a store is fast — how images are sized and served, whether fonts are self-hosted, how much JavaScript runs before the first screen, whether the mega-menu is in the initial HTML — are all made during the build, and unwinding them afterwards costs more than making them correctly did.

So the budget belongs in the scope: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, measured on the delivered theme. Ours does, and it says so on the services page.

One honest caveat, which belongs in any such promise: those numbers hold on the theme as handed over. Apps and scripts installed afterwards can undo them, and no builder can be accountable for what gets added in month four. A quote that guarantees the numbers forever has not thought about it. There is more on what actually breaks them in why your Shopify store is slow.

What "handover" should mean

At the end you should hold, in your own accounts:

• the theme, published, on your store
• the repository, transferred to your organisation
• the Figma file
• documentation of anything custom, written for whoever maintains it next

If any of that lives in the agency's account, you are renting your own storefront. Ask before you sign, not at the end.

There is a related point about timing. Work built on a duplicate or unpublished theme and published at final payment is normal and protects both sides. Work that is published and then invoiced is a favour the studio is doing you, and one it will eventually stop doing. What matters is that the sequence is written down.

Where the money actually goes

A build quote is mostly a function of three things: the number of distinct templates, how much of the store is editable without a developer, and how much of the design was left to the build to decide.

That last one is why "we already have a design" sometimes makes a build more expensive rather than less. A file that is 60% finished has to be finished by someone, and doing that during a build is the most expensive moment to do it.

Ours is Figma → Shopify, from €2,500, in five to seven days when the design is genuinely finished, and a full store build from €6,000 when design and build should be one engagement rather than a handoff. Both scopes publish what they exclude, which is the column worth reading first.

If you are not sure which you need, the Store Teardown will tell you what the store is actually losing before you commit to rebuilding it — and sometimes the answer is that a rebuild is not the highest-value thing you could do this quarter.