Shopify work
built like software
Smart-UI builds custom Shopify themes, migrates stores to Online Store 2.0, redesigns storefronts, and supports them for years afterwards. Themes live in Git and ship through review, speed and accessibility are measured rather than claimed, and integrations are built as app blocks and custom apps instead of Liquid left behind in your templates. Fixed price against a written scope, quoted within 48 hours.
Talk about your storeCurrent work: Completedworks, a London jewellery and homeware brand with over 1,000 products, and Fine Matter, a headless Shopify marketplace for 94 independent makers.
What does Smart-UI do on Shopify?
Smart-UI builds custom Shopify themes, migrates stores from vintage themes to Online Store 2.0, redesigns storefronts, and supports them for years afterwards. Themes are developed in Git with a preview theme per branch rather than edited in the browser on production, which is what makes a change reviewable and a bad release one revert away.
A Shopify engagement covers the whole storefront: custom design built as sections a merchant can compose, speed against an agreed Core Web Vitals budget, accessibility to WCAG 2.1 AA, apps and custom integrations on the Admin API, forms, payments and Checkout Extensibility, Shopify Markets for selling across countries, analytics and reporting, and the SEO work that keeps rankings through a replatform.
Current Shopify work includes Completedworks, a London jewellery and homeware brand with over 1,000 products, migrated to Online Store 2.0 and redesigned in the same release and supported since 2024, and Fine Matter, a headless Shopify marketplace for 94 independent makers, supported since 2022.
| Engagement models | Fixed price against a written scope, no retainer required |
|---|---|
| Typical duration | Theme rebuild 6-10 weeks, smaller work in days |
| Team shape | Shopify developer, front end, designer, QA |
| Stack | Shopify, Online Store 2.0, Liquid, JSON templates, metaobjects, app blocks, Admin and Storefront API, Shopify Functions, Markets |
| Markets served | United Kingdom, United States, Australia, European Union |
Everything in front of the checkout, and the checkout handled carefully
Shopify is excellent at payments, tax, fraud and the order record, and rebuilding any of that is a way to spend a year discovering why Shopify costs what it costs. Everything else is ours to build, and below is what that covers.
Custom theme development
A theme that belongs to the brand, not a template with overrides
- Built from a Figma design, not bought and bent into shape
- Every template a JSON template of sections with schema, so pages are composable
- Header and footer as section groups, which is the piece half-done migrations skip
- Settings written for the person who will use them, with sensible defaults and limits
- Theme connected to Git: branches, review, history, and a preview theme per branch
- JavaScript kept to what a section needs, with Alpine or Vue only where a section genuinely holds state
Theme change and Online Store 2.0
There is no upgrade path, so this is a rebuild done properly
- Vintage themes rewritten as sections and JSON templates, not patched
- Hardcoded content moved into metafields and metaobjects while every template is open
- App integrations re-done as app blocks, or replaced where no block exists
- Every app inventoried before work starts, because finding a gap mid-migration is how timelines slip
- Redirect map agreed before launch, never written after someone notices the traffic
- Old theme kept live and switchable until the new one is proven
Custom design and art direction
Designed so marketing can compose pages without a developer
- Product, collection and editorial pages designed as reusable sections
- A design system expressed in theme settings: type scale, spacing, colour, buttons
- Mobile first, because that is where most of the revenue arrives
- Photography-led layouts, lookbooks and campaign pages
- Variant pickers, size guides and swatches designed around the actual catalogue
- Prototyped in Figma and reviewed on a preview theme before a line ships to production
Speed and Core Web Vitals
Measured on real pages and real devices, not on the home page
- A performance budget agreed at the start and checked on every release
- Images sized and served in modern formats, with the right ones preloaded
- App scripts audited, deferred, or removed when the app is no longer earning its place
- Liquid rendering cost profiled: loops over large collections are the usual culprit
- A cap on sections per page, since sections everywhere makes a slower page easy to build
- Measured on product and collection templates, which is where shoppers actually land
Accessibility
WCAG 2.1 AA, tested rather than scanned
- Keyboard path through search, filtering, variant selection and add to cart
- Screen reader pass on the cart drawer, quick view, and every dialog
- Focus management when a drawer or modal opens and closes
- Contrast on real components, including hover, disabled and sale states
- Form labels and error messages that are announced, not only coloured red
- Reduced motion respected, and an axe-core sweep for the machine-checkable half
Apps, forms and integrations
Built so they can be removed again without archaeology
- App blocks and theme app extensions rather than Liquid edits inside templates
- Custom apps on the Admin API for anything off-the-shelf does not do
- Forms for bespoke enquiries, wholesale, repairs, waitlists and size requests, with spam control
- Form submissions delivered server side, so no token or inbox sits in the browser bundle
- ERP, PIM and 3PL synchronisation, with retries and a record of what failed
- Email, reviews, wishlist, loyalty and subscriptions integrated without four copies of the same script
Payments and checkout
The part to extend carefully and never rebuild
- Shopify Payments, additional gateways, and local methods per market
- Express wallets and Shop Pay configured and tested on real devices
- Checkout customised through Checkout Extensibility and UI extensions, not legacy checkout code
- Shopify Functions for discounts, shipping and payment rules that belong in the platform
- Shopify Markets for currency, tax, duties and market-specific catalogues
- B2B price lists and company accounts where the store sells to trade as well
Data, statistics and reporting
Numbers the team can act on, not another dashboard nobody opens
- GA4 with consent mode, implemented through the Web Pixels API rather than script injection
- Server-side events where ad blockers and browser limits make client tracking unreliable
- Merchandising reporting: what sells, what is viewed and never bought, what returns
- Custom dashboards built from the Admin API when Shopify reporting stops at the question you need
- Cohort and lifetime value views for brands with repeat purchase
- An agreed definition of each metric, because two dashboards disagreeing is worse than one
SEO and AI search visibility
Keeping the traffic through a rebuild, and being found by assistants
- Handles, collection structure and faceted navigation planned before the build
- Canonicals for variants, filtered collections and pagination
- Product, Offer, Breadcrumb and Organization structured data checked against the rendered page
- hreflang across markets, and robots and sitemap control through the theme
- Search Console coverage read after launch and every exclusion explained
- Content made legible to AI assistants, which is a growing share of how a store is found
Ongoing support
The years after launch, which is most of the relationship
- Seasonal campaigns, new sections and landing pages on a predictable turnaround
- Platform deprecations absorbed before they are urgent
- App updates reviewed rather than auto-accepted into production
- A staging theme that actually resembles production
- The same engineers, so the reason behind each rule in the theme is not lost
- Monitoring on the paths that carry money
What goes wrong in a theme change, and what prevents it
A theme change is a rebuild of the storefront with the business still trading through it. These are the six ways it goes badly, and what we do about each one.
- Risk
Traffic drops after launch
Handles and collection URLs changed, with redirects written afterwards from memory.
What we doThe redirect map is produced from a crawl of the old store and signed off before the cutover. Rankings are watched for six weeks after, not six days.
- Risk
The new store is slower than the old one
Sections everywhere makes it easy to stack a page, and every app adds its own scripts.
What we doA performance budget agreed at the start, app scripts audited, and the product and collection templates measured on each release.
- Risk
An app stops working halfway through
The app only ever existed as Liquid pasted into the old theme and has no 2.0 block.
What we doEvery app is inventoried before a line is written. Where no block exists we either build the integration or say so in the estimate.
- Risk
Content disappears
Copy, specifications and care details were hardcoded in templates nobody catalogued.
What we doContent is modelled into metafields and metaobjects as part of the migration, which is also the only time anyone will agree to do it.
- Risk
The team still cannot change anything
The theme was rebuilt on 2.0 but the sections have no settings worth using.
What we doSettings are designed with the people who will use them, and the handover ends with them building a page themselves while we watch.
- Risk
Nobody can tell what changed
The theme was edited in the browser, on production, by several people.
What we doThe theme is connected to Git. Changes are reviewed, history is readable, and a bad release is one revert away.
How a Shopify engagement runs
Fixed price against a written scope, with the store trading throughout. No retainer required to start.
- 01
Store review
A read of the live store and the theme: which apps are installed and what each one costs in scripts, where content is hardcoded, what the catalogue actually looks like, and how the store is found today. This is also where we say if the work you asked for is not the work you need.
- 02
Scope and fixed price
A written scope, a fixed price against it, and a date. Quoted within 48 hours of the brief. Anything we are not certain about is listed as an assumption rather than buried in a number.
- 03
Design and content model
Pages designed as sections, and a decision for every piece of content: section setting, metafield, or metaobject. Doing this before development is what stops a 2.0 theme from being a 1.0 theme with JSON on top.
- 04
Build in Git, preview per branch
The theme lives in a repository with a preview theme per branch, so every change is reviewable on a real store before it goes near production. The existing store keeps trading throughout.
- 05
Cutover
Redirects in place and verified, structured data checked against the rendered page, speed and accessibility measured against the budget, and the old theme kept switchable until the new one has proven itself.
- 06
Support
Campaigns, new sections, platform deprecations and app changes, handled by the same engineers who built the theme. Most of our Shopify work is this part: Completedworks since 2024, Fine Matter since 2022.
Frequently Asked Questions
Both, and the honest answer depends on the catalogue. A brand with a few dozen products and no unusual merchandising is often better served by a good theme configured properly. A store with a large catalogue, its own identity, or anything the theme was not designed for ends up fighting the theme for years, and a custom theme costs less over that period. We say which one we think you need before quoting.
There is no upgrade path, so it is a theme rebuild. Every Liquid template is rewritten as a JSON template of sections with schema, the header and footer become section groups, hardcoded content moves into metafields and metaobjects, and app integrations are re-done as app blocks. The visual result can be identical and the theme underneath is new, which is exactly why the redesign belongs in the same release.
Only if the redirects are written afterwards. We crawl the existing store, produce the redirect map before the cutover and sign it off with you, keep handles and collection URLs wherever possible, and check structured data against the rendered page rather than the source. Search Console coverage is read for six weeks after launch and every exclusion explained.
Usually, and most of the gain is not in the theme. App scripts, oversized images and Liquid loops over large collections account for most of what we find. We measure product and collection templates rather than the home page, agree a budget, and check it on every release. Where an app is costing more than it earns we say so.
We configure Shopify Payments, additional gateways and local payment methods per market, and customise checkout through Checkout Extensibility and UI extensions rather than legacy checkout code. Discount, shipping and payment rules go into Shopify Functions where they belong. We do not rebuild checkout, because that is the part of Shopify most worth keeping.
Fixed price against a written scope, quoted within 48 hours of a brief and a look at the store. A full theme rebuild with a redesign typically runs 6 to 10 weeks depending on the catalogue and the app estate; smaller work is days. There is no retainer required to start, though most of our Shopify relationships become long ones.
The United Kingdom, the United States, Australia and the European Union. The team sits in Spain and Ukraine, which gives a full working day overlapping London and mornings overlapping New York.
From the blog
All articlesMigrating a Shopify store to Online Store 2.0
What 2.0 actually changes, why the migration is a theme rebuild rather than an upgrade, and what it is worth doing at the same time.
Headless Shopify for a multi-brand marketplace
Four years on one jewellery platform: Shopify behind a custom storefront, a brand-facing dashboard, and what a long support relationship actually looks like.