Start with a theme. Move to a custom build only when a specific business requirement can’t be met by configuration — not when the theme feels generic. Most stores that pay for a custom build are paying to solve a design problem, and a well-chosen theme with real design work behind it solves that problem for less.
The distinction that matters is structural versus presentational. Presentational problems are almost always cheaper to solve inside a theme. Structural ones are what custom builds are for.
There are three options, not two
The question is usually framed as theme versus custom, which hides the middle and misrepresents the extreme.
A theme, customised. You start from a published theme and modify its Liquid, add custom sections, and restructure templates. The theme’s author continues shipping updates, though heavy modification makes those updates harder to take.
A custom theme. You build Liquid templates from scratch, often starting from Dawn as a reference rather than a base. You own every line, including the parts nobody wants to own: image handling, cart behaviour, accessibility, responsive logic.
Headless. The storefront is a separate application consuming the Storefront API, with Shopify handling commerce and checkout. This isn’t a bigger version of a custom theme. It’s a different system with its own hosting, deployment, and failure modes.
Most conversations that start with “we need something custom” end correctly at the first option.
What a theme already gives you
A production theme is not a template you’re settling for. It’s a set of solved problems: cart behaviour, responsive breakpoints, accessibility basics, responsive image handling through Liquid’s image_url and image_tag filters, and compatibility with platform changes you don’t control.
Building those from scratch means re-solving them, then maintaining them. That cost doesn’t appear in the quote. It appears eighteen months later, when Shopify ships a change and nothing in the store was built to absorb it.
What a custom build does not buy you
This is where most decisions go wrong, so it’s worth being specific.
Checkout. Checkout is not part of the theme on any plan. It was, through checkout.liquid, and that era is over — the file is unsupported for the Information, Shipping, and Payment steps, and was sunset for the Thank You and Order Status pages in August 2025. Customising checkout now runs through checkout UI extensions, Shopify Functions, and Web Pixels, and building your own extensions requires Shopify Plus. No amount of custom theme work changes this.
Discount and shipping logic. This lives in Functions, not in the theme. Shopify Scripts stopped executing entirely on 30 June 2026, and Functions replaced them. Again, plan-gated, not theme-gated.
Filtering. Collection and search filters are configured in the Search & Discovery app, not written into the theme. The theme’s job is to support the filtering API and render the result. A custom theme doesn’t remove Shopify’s limits — 25 filters per store, one filter per source.
Speed. Custom builds are not automatically fast. Most Shopify performance problems come from third-party JavaScript and unoptimised images, and both survive a rewrite.
If a client’s reasons for wanting custom fall into this list, the rebuild won’t deliver them. That conversation is worth having before anyone quotes.
Four questions that decide it
Is the constraint merchandising or presentation?
If your catalogue needs a browsing model the theme can’t express — configurable products, made-to-order, bundles with dependencies between options — that’s structural. If the complaint is that the sections feel like everyone else’s, that’s presentation, and it’s solvable without a rebuild.
How large is the catalogue, and how do products differ from each other?
A small catalogue of considered purchases puts the weight on the product page. A large catalogue puts it on collection and search, where Shopify’s own filter limits start to bind before the theme does. Themes handle the second case well by default. The first case is where custom sections tend to earn their cost.
Who maintains the store after launch?
A custom build the client’s team can’t edit becomes frozen. Every change becomes a ticket. If the merchandising team needs to run a campaign without a developer, that requirement should shape the build before anything gets designed. Custom sections with well-designed schema settings are what make this work — and they’re available in every option above.
What happens at the next platform update?
Themes get updated by their authors. Custom builds get updated by whoever is available. Headless storefronts need updating for framework changes as well as platform ones. Decide who that is before you commit.
When a custom build is right
There are real cases:
- The purchase flow isn’t a standard product-to-cart sequence — quotes, multi-step configuration, subscriptions with rules
- B2B pricing and catalogue logic that varies by company location
- A merchandising model that doesn’t map onto collections and filters
- Integrations that drive the interface rather than sit behind it
- Content requirements heavy enough that the storefront is closer to a publication than a catalogue
What these have in common is that the requirement is functional. Someone can describe what the store needs to do, and no theme does it.
Signs you’re about to overspend
- The stated reason is that the brand wants something unique
- Nobody in the conversation can name a functional requirement a theme fails to meet
- The comparison set is competitors’ aesthetics rather than competitors’ behaviour
- The decision is being made before anyone has looked at the catalogue
- The expected benefit is on the list of things a custom build doesn’t buy you
None of these are bad instincts. They’re just answered by design work, not by architecture.
How to decide in one pass
Write down what the store has to do that a theme can’t. Remove from that list anything that’s actually plan-gated or app-gated rather than theme-gated. If what remains is empty, you need a theme and a designer. If it has items on it, price the custom build against those items specifically — not against the whole store.
The goal isn’t to spend less. It’s to spend on the part that changes the outcome.