How Do Shopify Themes Work and When Should You Go Custom?
On Shopify the theme is the design. Almost every visual and structural decision is a theme decision, which means choosing one well matters considerably more than most buyers realise and going custom matters far less than most agencies suggest.
What A Shopify Theme Actually Is
A Shopify theme is not a layer of styling applied over a store. It determines the layout of every page type, which page types exist at all, how the store behaves on a phone and, most consequentially, which settings you will ever have access to.
That last point is the one worth sitting with. The controls in your theme editor are not a Shopify feature set. They are a list your theme declares, which is why two stores on the same plan can offer their owners completely different amounts of control.
On some platforms a theme sits on top of a system and can be swapped without changing what the site does. On Shopify the theme largely is the storefront. Changing it changes what your store can do rather than only how it looks.
Which produces the mismatch this whole page exists to address. Choosing a theme is the single largest design decision in a Shopify build. It is routinely made in an afternoon by scrolling through thumbnails and picking one that looks close to the intended feel.
The Section System
Modern themes are assembled from reusable sections. Each is a self contained component with its own settings. A page is a stack of them in an order somebody chose.
The significant change came with Shopify's Online Store 2.0 architecture in 2021, which made sections available on every page type rather than only the home page. Before that, rearranging a product or collection page meant editing files. Afterwards it meant dragging something in the editor.
What that lets an owner do without any code. Rearrange the product page so specifications sit above reviews. Add explanatory content to a collection page. Assemble a new landing page from components that already exist. Change what appears where when a season turns, then change it back.
Shopify's own theme documentation now goes a step further, describing themes that support theme blocks, including its Horizon family, as a newer architecture again beyond Online Store 2.0.
Two consequences follow, both of which cost money when missed. Guidance written before 2021 overstates how much a Shopify store needs a developer, while a good deal of agency pricing still assumes that older model. And a theme predating the section system carries a much lower ceiling than its owner realises, which makes our theme is a bit old a more serious statement than it sounds.
Settings, Content And Code
Everything about a Shopify store lives in one of three places. Knowing which matters more than it first appears.
Settings. Everything the theme editor exposes. Colours, typography, which sections appear on a page, their order and the options each one offers. Immediate, reversible and available to anybody.
Content. Your products, collections, pages, images, written copy and any additional product information the store holds. This lives in the Shopify admin rather than in the theme.
Code. The theme's own files. Everything not exposed as a setting sits here.
Now the part that makes the distinction worth learning. Content survives a change of theme. Settings do not. Code customisations certainly do not.
Products, collections and the information attached to them belong to your store and carry across to any theme you move to. The arrangement of sections, the configured options and anything written into the theme's files belong to that theme and are lost with it.
So the balance between the three is a prediction of what a future theme change will cost. A store where most of what matters lives in content can move themes in days. A store where a great deal has been written into theme files is facing a rebuild whenever it moves, which is the trade block five describes.
What A Theme Cannot Do
Five things sit outside any theme. Recognising them prevents a purchase you must reverse.
A theme cannot provide a page type it does not have. It cannot offer a setting nobody wrote into it. It cannot display information your store does not hold. It cannot behave differently for different visitors. And it cannot alter what Shopify itself fixes, including the checkout limits and the address structure covered in what a Shopify web designer is.
How to find the ceiling before buying rather than after. Four checks, none of which needs technical knowledge.
List the page types your store genuinely needs and confirm the theme has each one, rather than assuming a page type exists because most stores have it.
Write down five changes you expect to make in your first year of trading, then confirm each is a setting. This single exercise catches most mismatches.
Read the theme's own documentation for its list of sections, which tells you what it can assemble.
And check what it does with a catalogue like yours. A theme built to show twelve beautiful products behaves quite differently when given four thousand with technical specifications. Nothing on its sales page will tell you that.
The mistake this prevents is the common one: buying on appearance, then discovering the ceiling after the catalogue is loaded.
Customising A Theme, And The Update Problem
Customising a bought theme means editing files that belong to somebody else's product. It works, immediately and well. The difficulty arrives later.
The mechanism. Theme developers release updates carrying fixes, performance work and changes that keep the theme working as Shopify itself changes. An update replaces files. Where those files have been edited, the update either overwrites the work or refuses to apply cleanly.
Three outcomes exist. Only one is chosen deliberately.
Reapply the customisations after each update, which means paying somebody a little each time and remembering to do it.
Stop updating, which most stores do without anybody saying so out loud. The store then quietly falls further behind its own theme until the gap is wide enough that updating becomes a rebuild.
Or keep the customisation in sections added alongside the theme rather than in edits to its existing files, so updates continue to apply. Not always possible. Possible considerably more often than it is done, because it takes longer to build that way.
The reason this becomes a surprise rather than a decision is simple enough. At the point a quote is written, the customisation is the thing being sold. Its maintenance consequence two years out is nobody's immediate problem. Ask which files will be modified and what happens at the next theme update, before agreeing anything.
What A Custom Theme Is
A custom theme is one built for a single store, either from nothing or from a deliberately minimal starting point, rather than bought and adapted.
What it gives you. Exactly what was specified, with no code supporting features you will never use, plus no compromise with assumptions somebody made about a different kind of business. On a store with genuinely unusual requirements that is worth a great deal.
What it costs. Substantially more to build. The ongoing position also changes completely. There is no theme developer releasing improvements. There is no documentation anybody outside the project has read. There is no community of other users who have solved the problem you are about to hit.
Who maintains it. You do, through whoever built it, else through whoever you find afterwards, who will need time to understand a system they have never seen.
Then the part that rarely gets said. It is the mirror image of block five. A custom theme has no update problem because it has nothing to update. You have not solved the conflict between customisation and updates. You have removed updates from the arrangement entirely.
That is a good trade for a business with somebody responsible for the store permanently. It is a poor one for a business that will have nobody looking after it in eighteen months, since a custom theme with no maintainer cannot be handed to a theme developer for a fix.
When Custom Is Genuinely Justified
Four situations, stated directly, because vagueness here costs buyers a great deal of money.
Products no theme anticipates. Configurable items assembled from interacting choices, made to order goods, perhaps products needing technical presentation that standard layouts cannot carry.
A functional requirement no theme meets and no app solves. Established by checking rather than assumed, which means somebody has actually looked.
A business large enough to employ or retain a developer permanently. Where the maintenance position in block six is already answered.
A brand where the storefront genuinely is the product, where the budget to keep it maintained exists alongside the budget to build it.
Outside those four, most businesses proposed a custom theme do not need one. That is not a criticism of the agencies proposing them, since a custom build is more interesting and more valuable work. The burden of proof simply sits with the proposal.
The tell is in the justification. Wanting something unique, wanting not to be limited and wanting to stand out are all preferences rather than requirements. If the reason for a custom theme cannot be stated as a specific thing your store must do that no theme does, no requirement has been identified yet.
The Middle Path
A well chosen bought theme, configured properly, plus a small number of sections built specifically for your store. It is the right answer far more often than either extreme and it is rarely the option a buyer is offered.
Why it works. You keep the theme's update path, because the additions sit alongside its files rather than inside them. You keep its documentation and its support. And you get the specific things your store needs, built as proper sections that then appear in the theme editor beside all the others, configurable by you afterwards.
That matters more than it sounds. A purpose built section is not a fixed piece of a page. It is a component your store owns, which somebody can add to other pages and adjust without asking anybody.
Why it is rarely proposed. Two reasons, neither sinister. A custom build is a larger and more interesting project to sell. And this arrangement requires a supplier to say openly how much of your requirement the bought theme already covers, which is a conversation that reduces their own scope.
If you take one thing from this page into a conversation with a supplier, make it this. Ask what the theme already does before discussing what needs building. Ask specifically which of your requirements are already covered.
How To Choose A Theme
What to establish before buying, in rough order of how much each will matter later.
How it handles a catalogue like yours. Variant heavy, specification heavy, very small or very large. This decides more than appearance does.
How much is editable without code. Read the settings each section offers rather than looking at the pictures.
Whether the sections you need already exist, checked against the five changes exercise in block four.
Speed, tested rather than claimed. On the demo store, on a phone, on mobile data.
Whether it is actively maintained. A theme with no recent updates is a theme whose developer has moved on. Block five explains why that matters.
What support exists, from whom, at what speed.
The warning, which catches nearly everybody. Themes are sold against demonstration content assembled by a designer with perfect photography, an unusually tidy catalogue and precisely the right number of products to fill every row. Your store will not look like that.
Seeing past it takes two minutes. Open the demo on a phone, find a product with a long name, then picture your worst photograph in the largest image slot. That is the realistic preview.
Cost And Time
Compared in shape rather than figures, since any number here would describe somebody else's project.
A bought theme configured properly. The fastest and the lowest, with the range driven almost entirely by how much setup, structure and content work the store needs rather than by the theme itself.
A bought theme plus purpose built sections. Moderate, scaling with the number of sections rather than in steps. Each addition is a discrete, quotable piece of work.
A custom theme. Considerably the highest and the longest. Unlike the other two it does not stop at launch, because the maintenance position described in block six continues for as long as the store trades.
What drives the difference between them is worth being explicit about, since buyers consistently look at the wrong number.
The theme licence is the smallest figure in the entire project. Whatever a paid theme costs, it is trivial beside the work of setting up the store, structuring collections, preparing product information and writing content. Buyers routinely deliberate for a fortnight over the theme price and approve the setup cost without discussion, when the second is many times the first.
How the free and paid options compare is taken up in free Shopify themes against paid Shopify themes.
We will check the theme
before quoting a build.
Most requirements we are sent are already covered by a well chosen theme. We will tell you which of yours are before proposing anything. Where something genuinely has to be built, we build it as a section you can use afterwards.
What Shopify work covers:
Ongoing management afterwards sits inside our fixed monthly fee. Build work is quoted per project.
Six guides.
One platform.
This page covers themes. The rest of the series covers the role, who does what, what good looks like on Shopify, free themes against paid, plus what to ask before hiring anybody.
