Shopify Theme Development

A theme is a merchandising tool, not a skin

The mistake that produces most of the rebuilds we are asked to quote is treating the theme as a visual layer applied to a store. It is not. It is the interface your own team uses to run the business — the thing they open on a Tuesday morning when a supplier is late and the homepage needs to say something different by lunchtime.

You can see which assumption a theme was built under within about five minutes. Open the theme editor and try to build a page the design never anticipated. If the sections are named after the pages they first appeared on — “homepage banner 2”, “collection promo new” — the theme was built as a set of screens. If they are named after what they do and can be placed anywhere, it was built as a system. The first kind sends every change back to a developer. The second is why some stores can run a campaign in an afternoon and others need three weeks and a purchase order.

That distinction is what Online Store 2.0 made possible and what a great many 2.0 themes still do not deliver. JSON templates, sections available on every template, app blocks, and metafields as a first-class part of the data model. Used properly, it moves the boundary between what marketing can do and what engineering has to do a long way in marketing’s favour, permanently.

What we build

Custom theme architecture. Tokens first — colour, type scale, spacing, motion — then components, then templates that compose them. Sections designed for the person merchandising the store, with settings that make the wrong layout hard to build. Metafields and metaobjects designed as a content model up front, because retrofitting one onto three hundred live products is an order of magnitude more expensive than getting it right before launch.

Figma to theme. How the file is built changes what it costs, and it is worth being direct about that. A file with real variables, components and stated breakpoints becomes a token layer and a component inventory almost mechanically. A file that is a stack of full-page images at 1440 needs someone to infer the system from it first — what the type scale actually is, what happens at 768, what the component does when the text is twice as long. That inference is design work. We quote it as design work rather than hiding it inside the build and discovering it in week three.

Shopify Plus builds. Multi-store and multi-market architecture, B2B catalogues and company-level price lists, and the checkout customisation that only Plus permits. Where checkout logic is involved, that part is app work — Checkout UI extensions and Shopify Functions — and it is scoped alongside the theme rather than pretended to be part of it.

Migrations and replatforming. WooCommerce, Magento, BigCommerce, or an older Shopify theme that has been extended past the point of safe updating. The product import is the easy half and the half every proposal talks about. The half that decides whether the migration went well is the URL structure, the redirect map, the structured data, the filtered collection pages, and the plugin logic with no Shopify equivalent.

Performance rebuilds. Sometimes the right recommendation is to keep the theme you have. See below.

The migration is a redirect project wearing a design project’s clothes

When a merchant tells us traffic dropped after a replatform, the cause is essentially always the same. A URL pattern changed — /product/ became /products/, or the category structure was reorganised, or the blog moved — and nothing redirected the old pattern. A few hundred indexed pages started returning 404s on cutover day. The rankings took four to eight weeks to visibly fall, by which point the launch was considered finished and nobody connected the two.

The prevention is unglamorous and it works. Build the redirect map from the live site’s actual indexed URL list rather than from a crawl of what you think exists. Keep the patterns explicit instead of writing a catch-all rule that will eventually swallow a route you add next year. Verify every line after cutover, not before. Watch Search Console’s coverage report for a month, not a day.

We treat that map as a named deliverable, verified line by line, because it is the single artefact that decides whether a migration was worth doing.

When a rebuild is the wrong answer

Most merchants who come to us saying the site is slow do not need a new theme.

When we measure, the largest share of the problem is usually not theme code. It is six apps loading on the product page, two of which nobody uses. It is hero images shipped at 3000 pixels wide to a 390-pixel phone. It is three font families, one of them loading render-blocking from a third-party host. It is a review widget that inserts itself above the fold and shifts the layout half a second after paint.

None of those are fixed by a rebuild, and all of them are fixed in a fraction of the time a rebuild takes, on whatever theme you already have. That work is days, not months, and the merchant keeps a store their team already knows how to run.

The honest case for a custom theme is different, and it is a good case when it is true: the design or the merchandising model cannot be expressed in the current theme, and every campaign is now a workaround stacked on the last one. If that is your situation, a rebuild pays for itself in what your own team stops having to route through a developer. If it is not, we will tell you, and the audit that says so costs a fraction of the project that was quoted.

Performance, concretely

The targets are Google’s Core Web Vitals thresholds — Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1 — measured on field data from real visitors, not on a lab score from a laptop on office wifi. Lab scores are a debugging tool. Field data is the thing that correlates with revenue.

Getting there on Shopify is not mysterious. Render on the server with Liquid and ship JavaScript only where interaction genuinely needs it. Serve responsive images at the sizes the layout actually uses, in a modern format, with width and height declared so nothing shifts. Self-host fonts, subset them, and give every face a real fallback. Keep third-party script out of the head. Place app scripts on the templates that need them and nowhere else. Reserve space for anything that loads late.

The last one is worth stating on its own, because layout shift is the vital that merchants tolerate longest and that customers hate most: a control that moves under a thumb mid-tap is not a metric problem, it is a lost order.

What you get, and who owns it

The theme lives in your Shopify admin and in a repository you own, with a staging theme and a documented release process rather than edits made live at four on a Friday. You get a section and block inventory that says what exists and where it is meant to be used, a token layer mapped to your design file, structured data on the templates that need it, and before-and-after field measurements rather than an assertion that it is faster.

And you get a guide to the theme editor written for the people who will use it — in their language, about their store. If your team cannot rebuild the homepage without calling us, we did not finish the job.