Web design · Shopify
Shopify storesbuilt to merchandise.
Theme, catalog structure, and the apps that are allowed to touch the cart. Checkout stays on Shopify.
The short answer
When Shopify is the store.
Shopify is the right build when a merchandiser should run products, collections, and discounts without a developer, and you want checkout, tax, and payments on a platform that ships those updates. It is a weak fit when the site is mostly long-form publishing with a tiny catalog, or when B2B price lists are the actual requirement. We inventory every app before we promise a date. A new theme on a pile of overlapping apps is a second store you already pay for.
When Shopify
Hosted checkout, and an admin people will use.
Choose Shopify when the catalog is the business and the team editing it is not a developer shop. Collections, metafields, and a section-based theme let a merchandiser change a grid without opening code. Markets, languages, and multi-currency belong in scope only if you already sell that way. We do not turn them on as decoration.
Pass on it when the content team lives in WordPress and the guides are the reason people buy. That may be WooCommerce. Pass on it when wholesale price lists, customer-specific catalogs, or a complex product model are why you are replatforming. That may be BigCommerce. Write the reason down before anyone picks a theme.
- A merchandiser will edit products, collections, and navigation.
- Checkout, tax, and payments should stay on the platform.
- The app list can be named, and each app has one job.
Theme and apps
An unpublished theme, then a catalog that matches it.
Edits happen on an unpublished theme. The live theme is not the scratchpad. Templates cover collection, product, cart, and the landing pages ads will actually use. Metafields hold specs that should not be pasted into a description as a wall of text. Navigation is the way people shop, not a dump of every product.
Apps are scoped like features. Reviews, subscriptions, bundles, and upsells each have to earn a slot, because each one can inject a script into the theme or the checkout. We remove duplicates before launch. Customer accounts are on only when reorder, wholesale, or a real order history needs them. Guest checkout is the default otherwise.
- Section-based templates a merchandiser can rearrange inside rules.
- Product metafields for specs, materials, and care, rendered on the template.
- A written app list, including the ones we are removing.
App pile
Checkout scripts and a theme edited live.
Stores collect apps the way desks collect cables. Two review apps, a currency app the platform already covers, and a popup that covers the add-to-cart button. The theme looks slow and nobody knows which app to blame. We start with an uninstall list, not a new app to 'fix performance.'
The second failure is design inside the published theme, with no copy of the code anywhere you can roll back. A bad save is the release. We also see replatforms that turn the old store off before redirects and the catalog check are done. The new theme cannot recover a URL you already dropped.
- No second app for a job Shopify or an existing app already does.
- No edits on the published theme as the only copy.
- No forced account creation unless the business model needs it.
Merchandiser test
Can someone on your team merchandise Tuesday.
The test is operational. A merchandiser adds a product, sets a variant, places it in a collection, and previews it on the unpublished theme. If that takes a developer, the build missed. We watch that rehearsal before launch, not as a slide in the handoff.
After launch we watch theme publishes, the app list, and whether ads land on a collection or product URL that exists. Speed is checked on those templates, on a phone. A homepage score that ignores the product page is the wrong test for a store.
- A merchandiser can publish a product without a ticket.
- App count, with the job of each app still true.
- Collection and product templates checked on a phone.
Example engagement
A specialty retailer moving off a brittle theme.
Specialty retailer, a few hundred SKUs, already on Shopify. The published theme had been edited live for two years. Three apps offered overlapping upsells. Collection pages were screenshots of the homepage with a grid underneath. The merchandiser waited on a freelancer for every badge and spec.
We built the new templates on an unpublished theme and cut the app list to the jobs the store actually used: reviews, subscriptions on two products, and shipping rules. Specs moved into metafields the product template rendered. The old theme stayed available until redirects were checked. The merchandiser added a product on the new theme before we called it launched.
One theme
Work happened on an unpublished theme, then published
Named apps
Each remaining app had one job on the list
The example uses anonymized results from a Quorum engagement. It is one account, not a benchmark you should budget against.
Questions
Shopify questions.
Will you customize checkout?
We work inside what Shopify allows: branding, fields you truly need, and scripts that do not have to be there. A fully custom checkout is how wallet support and platform updates get lost. If that is the request, we say so before design starts.
Can the blog live on Shopify?
Yes, when the articles support the products and someone will edit them in the same admin. A large editorial site with a small catalog is often a poor use of the theme. We will say if the content wants a different platform.
Do we need a headless front end?
Usually no. A section-based theme covers most catalogs. A separate front end is a different project, with its own preview and deploy path. We only propose it when the theme cannot express the catalog you actually sell.
How do you handle an existing app stack?
We list every app, what it claims to do, and whether the theme or another app already does it. Removals happen on staging before launch. An app the store depends on stays, and it is named in the handoff so the next person does not delete it by accident.
Is a new theme the same as a replatform?
No. A theme project keeps the catalog, the customers, and the checkout. A replatform moves those from somewhere else and needs a parallel run. We price and schedule them as different jobs, because the risks are different.
More in this lane
Other Web Design platforms.
Talk through shopify.
One conversation. A diagnostic. A plan you can kill if it is not the work.