Shopify Web Designer vs Shopify Web Developer: What Is the Difference?
On most platforms this distinction is woolly. On Shopify it is unusually practical, because the platform draws a hard line between what the theme editor exposes and what requires opening the theme's files. That line is the answer to the question.
The Difference In One Paragraph
A Shopify designer works within what the theme allows. A Shopify developer changes what the theme allows. Everything else in this guide is a way of telling which of those two describes the job in front of you.
On most platforms that distinction stays blurry, because configuring and building differ only by degree. Shopify is different. The theme editor exposes a defined set of controls and everything outside it requires opening the theme's files, so the platform enforces the line rather than leaving it to interpretation.
Which gives the usual question a precise answer. Rather than wondering whether your job feels like design or development, ask something answerable: is the change you want available in the theme editor?
If it is, you want a designer, so the work is judgement rather than construction. If it is not, you want a developer, at which point the price and timescale change accordingly. Where that boundary sits, plus why it moved considerably in 2021, is set out in what a Shopify web designer is.
What A Designer Does
Six areas, all achievable on a modern theme without touching a file.
Layout within the section system. Which sections appear on which page, in what order, plus how each is configured. This is the largest part of the job and the part most people picture as design.
Colours and typography. Set through theme settings and applied across the store, so they stay consistent when new pages are added.
Imagery. What goes where, at what proportions, plus to what standard across a catalogue rather than on one page.
Navigation and collection structure. What the collections are, how they nest and what appears in the menu. Quietly the most valuable item on this list.
Product presentation. What appears on a product page and in what order, how variants are displayed and where the information that decides a purchase sits.
The mobile arrangement. Section order can differ on a phone, which means somebody has to decide what a shopper sees first in a single column.
The scope of this changed materially in 2021, when Shopify's Online Store 2.0 architecture made sections available on every page type rather than only the home page. Work that previously required a developer moved onto the settings side, which is why guidance written before then overstates how much code a Shopify store needs.
What Needs A Developer
Six kinds of request, described by what they are rather than how they are done.
Section types the theme does not have. Not rearranging what exists. Creating something that does not.
Functionality that does not exist on the store. A configurator where choices constrain each other, an unusual bundling rule, a calculator specific to what you sell.
Integrations with systems outside Shopify. Stock control, accounting, a supplier feed or anything else that has to exchange data.
Information held elsewhere appearing on the store. Anything the store does not currently know about a product has to be brought in and then displayed.
Behaviour no setting controls. Something happening in response to what a shopper does, perhaps a rule about when an element appears.
Changing how a section works rather than how it is configured. The distinction that catches people, since both are described as changing the section.
One question separates this list from the previous one reliably. Ask which setting controls the thing you want. If somebody can name it, you have a designer's job. If the answer is that no setting controls it, you have a developer's job. You have established that in a sentence rather than after a quote.
The Template Language In Between
Shopify themes are written in Liquid, the platform's own template language. You do not need to learn any of it. You do need to recognise the moment a request crosses into it, because that is the moment the job changes hands.
The mental model worth having is this. A section is a file. Attached to that file is a list of the settings it offers. The theme editor reads that list and shows you exactly those controls, which is why two themes can look similar while offering completely different options.
Which explains something that otherwise seems arbitrary. The settings you can see exist because somebody wrote them into the file. When a control you want is missing, it is not hidden and it is not a limitation of your plan. Nobody declared it. Adding it means editing the file.
That gives you a sentence to listen for. When somebody says they would need to add an option for that, the request has crossed the line and you are now discussing development work, whatever the person's job title is.
It applies in reverse too. If a theme already offers a setting, paying anybody to build it is paying for work the theme has done.
Apps As The Third Option
A great many requests are met by an app rather than by a designer or a developer. That possibility is frequently missing from the conversation entirely.
What you are trading. Speed against permanence. An app is installed in minutes where a custom build takes days. In exchange you accept a charge every month for as long as the store exists, a dependence on somebody else continuing to maintain their code, plus additional weight on your pages.
When an app is the right answer anyway. When the requirement is common enough that somebody has solved it properly. When you have no way of maintaining custom code afterwards. And when the thing you need is genuinely peripheral to what makes your store work.
When it is not. When one requirement needs several apps stitched together. When the app duplicates something the theme already offers, which happens more than store owners realise. And when the monthly charge, multiplied across three years, starts to resemble the cost of having built it once.
Ask what it costs in month one, then in month thirty six. A custom build and an app frequently swap places once the second figure exists.
Which One You Need
Ten requests we are sent, with the answer to each.
Move the reviews above the description. Designer. Section order.
Change our brand colours. Designer. Theme settings.
Add a size guide to product pages. Designer if it can be a linked page or a shared section. Developer if it has to vary by product.
Show a different banner to returning customers. Developer, else an app.
Add a collection and put it in the menu. Neither. That is store admin you can do yourself.
Make product images larger on phones. Designer if the theme offers the setting. Developer if it does not.
Connect our stock system. App first, developer if none fits.
Build a bundle builder. App first, for the reasons in block five.
Our store is slow. Neither, until somebody has looked. Usually app accumulation rather than anything either would change.
Restructure our collections. Designer. It is the highest value item on this list by a distance. It is also the one nobody asks for, because it produces no visible change on the day it is done.
The Hybrid Reality
Having drawn the line clearly, most people work on both sides of it. Plenty of Shopify designers edit theme files and plenty of developers make design decisions, which is why the labels help less than the boundary does.
Four ways to find out what somebody actually does.
Ask roughly what share of their recent work involved editing theme files. The number matters less than whether they can answer without hesitating.
Ask them to describe a request they turned down or passed on. People who know their limits have an example ready. People who do not will say they handle everything.
Ask which themes they have worked in most, since familiarity with a specific theme is worth more than general experience.
Then the best test. Take one request from block six and ask which side it falls on. Somebody who works on Shopify regularly answers immediately and explains why. Somebody who has watched a tutorial gives a general answer about it depending on the setup.
How To Brief Each
The two need genuinely different things from you. Giving the wrong one to the wrong person is where budgets go.
What a designer needs. What the page is for. Who buys from you and what they ask before buying. What the products are and how they differ. Examples of stores you like, with the reason attached rather than just the link. And your constraints, including anything that cannot change.
What a developer needs. Precisely what should happen. Under exactly what conditions. Using which information. And what should happen when it does not work, which is the part nobody specifies and the part that causes the argument.
The important difference is not the content of the brief. It is what vagueness costs in each case. The asymmetry is larger than people expect.
A designer working from a loose brief produces something you react to. Reacting is cheap, revision is expected and the loop is short. A developer working from a loose brief builds something. Building is expensive. Rebuilding it because the brief meant something else costs the same again.
So the rule is simple. Be approximate with a designer if you must. Never with a developer. If you cannot be precise yet, pay a designer to help you get there before anybody builds.
We will tell you
if it is a setting.
Send us the request and we will say which side of the theme editor it falls on before quoting anything. A fair number turn out to be settings you could change yourself in ten minutes. We would rather tell you that.
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 who does what. The rest of the series covers the role itself, how themes work and when custom is justified, free themes against paid, what makes a good Shopify store and what to ask before hiring.
