The cleanest way to split the two roles: a Shopify designer owns what the shopper sees, a Shopify developer owns what the merchandiser can change without calling anyone. That's the line we draw on every theme build. Everything in the shopify designer vs shopify developer argument comes back to it. The comp, the type scale, the empty-cart state, the order in which a mobile PDP stacks: designer. The section schema, the block limits, the metafield definitions, the breakpoint where a five-item nav collapses: developer. Get that boundary wrong and you end up with a beautiful homepage that nobody on your team can edit, or an editable theme that looks like a template with your logo dropped in.
The difference between a Shopify designer and a Shopify developer, in one paragraph
A designer produces artefacts you can look at: wireframes, comps at two or three widths, a component library, states for hover, loading, error and empty. A developer produces artefacts you can deploy: Liquid sections, JSON templates, schema settings, CSS, JavaScript that doesn't block the main thread. The designer decides that the collection page shows four products per row on desktop. The developer decides whether that number is hard-coded or a range setting in the schema, and what happens when the merchandiser sets it to six on a 1280px laptop. Same feature, two different kinds of decision.
The part founders underestimate is that the second decision costs more over a year than the first. Design is a fixed spend. Schema is the thing your team lives inside every week.
What a Shopify designer actually does on a live build
Not just picking colours, obviously. On a real project the designer is doing five things:
- Information architecture. What goes on the PDP, in what order, on a 360px screen. This is the single highest-leverage design decision on an Indian D2C store, because most of your traffic is one-handed on a mid-range Android.
- A component system. Buttons, cards, form fields, badges, spacing scale. If the designer hands over 11 button variants, the developer builds 11 and the CSS doubles.
- States. Sold out, low stock, COD unavailable for this pincode, coupon rejected, size chart open. Designers who skip states create three days of guesswork during build.
- Copy layout. Not writing it, but reserving space for it. Hindi and Arabic run longer than English. A button designed for "Buy Now" breaks at "اشترِ الآن" plus RTL mirroring.
- The handover file. Named layers, a spacing token list, exported assets at 2x, and a note on what is fixed versus what the merchandiser should control.
A UX designer and a Liquid developer are not interchangeable even when the deliverable looks similar. The UX person is optimising for the shopper's next tap. The Liquid person is optimising for render time, theme editor usability and the fact that Shopify's section rendering API will be called on this block from three different templates. Ask a strong UX designer to write Liquid and you get working code with a nested loop over all variants inside a collection grid. Ask a strong developer to design a homepage and you get something competent and forgettable.
The handover: who owns which half of the theme
This is the list we actually run through at kickoff. Ownership means "this person decides and is accountable", not "this person is the only one in the room".
Designer owns
- Section layout, hierarchy and visual design at a minimum of two widths, 360px and 1440px.
- The component library and design tokens. Colours, type scale, spacing, radii, shadows. One source of truth.
- Interaction intent. What the drawer does, how the filter panel opens on mobile, whether the variant picker is swatches or a dropdown.
- Which settings a merchandiser should be trusted with. Designers usually want fewer. They're right.
- Empty, error and loading states, including the ones nobody remembers: zero search results, out-of-stock variant preselected from a shared link, failed payment return.
- Accessibility decisions that are visual: contrast ratios, focus ring style, tap target size.
Developer owns
- Section and block schema. Setting types, defaults, max block counts, conditional visibility, presets. This is the contract between the theme and your marketing team.
- Metafield definitions. Namespace, key, type, validation, and whether it's a product metafield or a metaobject. Getting this wrong is expensive because you can't change a metafield type later without re-entering data.
- Breakpoints between the comps. The designer gave you 360 and 1440. The developer decides what a 4-column grid does at 900px and whether the nav collapses at 1024 or 768.
- App blocks and app embeds. Where they're allowed, which theme sections accept them, and what happens to your layout when the merchant installs a review widget that injects 140KB of JavaScript.
- Performance budgets. Image sizes and formats, lazy loading below the fold, deferring third-party scripts, keeping the critical path small enough that LCP stays under 2.5s on a throttled 4G connection.
- Everything checkout-adjacent: Shopify Functions for cart discounts, checkout UI extensions on Plus, Razorpay or Shiprocket integrations, COD eligibility logic by pincode.
- The accessibility that isn't visual: keyboard order, ARIA on custom dropdowns, announcing cart updates to screen readers.
Shared, and the source of most arguments
- How many settings a section gets. A designer's ideal is four. A merchandiser asks for twenty. Twenty means the theme editor becomes unusable and someone eventually sets the heading colour to a slightly different hex on one page. We cap most sections at six to eight settings and expose the rest through a global theme setting.
- Responsive behaviour that changes the design, like a three-column feature row that has to become a horizontal scroller on mobile. That's a design decision the developer usually spots first.
- Content modelling. Whether "ingredients" is a rich text metafield, a metaobject with repeatable entries, or just a section block. Depends equally on how it looks and how ops enters it.
Who builds custom Shopify theme sections
Both, in sequence, and the sequence matters. The designer specifies the section: layout, states, which parts are editable. The developer builds the Liquid, writes the schema, sets sensible presets and adds it to the templates where it belongs. Then the designer QAs it inside the theme editor, not in Figma, because the theme editor is where it will actually be used.
Skipping that last step is the most common failure we see on inherited themes. The section renders fine on the homepage the developer tested. Drop it into a collection template with a different container width and the padding collapses.
Can a Shopify developer do design work?
Some can, and it's worth knowing which kind you've hired. A developer who can design is usually excellent at extending an existing system: you have a design language, you need six more sections that look like they belong, they'll do it faster and better than a designer-plus-developer pair because there's no handover. What they generally cannot do is create the system. Brand direction, art direction, the photography style, the reason your store feels different from the other 40 stores selling the same category, that's a different skill and not one that comes free with Liquid fluency.
The reverse is rarer. Designers who write production Liquid exist but most "designer who codes" claims mean HTML and CSS inside an existing section, which is genuinely useful and not the same as owning schema and performance.
Do I need a designer or a developer for Shopify? And which one first?
Three situations, three answers.
You're launching and have no brand system yet. Designer first. Buy a good paid theme, have the designer define the visual system inside that theme's constraints, then bring in a developer for the five or six things the theme can't do. Paying for a bespoke theme before you have product-market fit is money you'll want back.
You have a theme that looks fine but doesn't do what you need. Developer first, and possibly only. Pincode-based COD rules, a bundle builder, a gifting flow, a B2B price list, live pricing, a filter system that handles a 3,000-SKU catalogue. None of that is a design problem. Hire a designer for it and you'll get a mockup of something that still has to be built.
You're replatforming from WooCommerce or Magento. Both, but the developer scopes first, because data structure determines what design is even possible. We've had migration projects where the whole visual design had to shift once we found that the old catalogue used configurable products in a way Shopify's variant limits wouldn't take.
What a Shopify theme designer costs, with the arithmetic
Indicative India agency rates, which is the market we quote in most often: design runs roughly ₹1,200–2,000 an hour, Liquid development ₹1,500–2,500. A single custom section that isn't trivial, say a comparison table with three editable columns and mobile-specific behaviour, takes about 4 hours of design and 10 to 12 of build.
So one section at the middle of those ranges: 4 × ₹1,600 = ₹6,400, plus 11 × ₹2,000 = ₹22,000. Call it ₹28,400. A build with nine genuinely custom sections lands near ₹2.5 lakh for section work alone, before templates, integrations, QA and launch. Which is why a full bespoke theme rarely comes in under ₹4–6 lakh and why most brands at under ₹2 crore GMV are better served by a strong paid theme plus targeted custom work. We break the line items down further on what Shopify development actually costs in India.
Design-only engagements are cheaper than they look and more dangerous than they look. A ₹80,000 set of comps that ignores Shopify's section model will cost ₹2 lakh to build. Always have the developer review the design before you sign off on it.
The awkward cases
A few things that break the neat split:
Multi-location inventory. The moment you have two warehouses and store pickup, the PDP needs availability logic the designer probably didn't draw. That's developer-led, and the design has to change to accommodate it.
App blocks you can't restyle. Plenty of third-party app blocks render inside their own markup with limited styling hooks. The designer's comp shows the review stars matching your type scale. The app renders its own. You either accept the mismatch, override with CSS that breaks on the next app update, or rebuild the feature yourself. We'd rather have that conversation in week one than week six.
Festive traffic. A design that's fine in August can fall over during a Diwali sale, because the one section carrying a countdown timer and a live stock counter is doing a Liquid loop over every variant. Load-test the theme, not the server.
RTL for the Gulf. If you're selling into the UAE or Saudi with an Arabic storefront, mirroring is a build concern and a design concern at once. Icons that indicate direction have to flip. Icons that don't, mustn't.
Short answers to the rest
Can one person do both?
On a store under a certain complexity, yes, and it's often the better buy. Above that, no. The tell is your section count: past roughly a dozen custom sections plus integrations, the developer needs to be full-time on code.
Who owns the theme editor experience?
Developer builds it, designer defines what should be editable, and whoever runs merchandising signs off. If your content team can't rebuild a landing page on their own by week two after launch, the schema is wrong.
How do I scope the split in a brief?
List every unique section, then mark each one D, Dev or both. Anything marked "both" needs a conversation before quoting. That single exercise removes most scope disputes.
What about ongoing work after launch?
Mostly development, with design pulled in for campaigns. A retainer that's 70/30 developer-to-designer is about right for a store shipping regularly. If you need to hire a Shopify developer in India for that kind of ongoing work, hire for schema thinking and performance instinct, not for how many themes they've touched.
Where to start this week
Open your theme editor, pick your three most-edited sections, and count the settings in each. If a marketer has to ask a developer to change a headline, or if there are so many settings that two campaign pages have drifted out of alignment, the problem isn't design taste. It's ownership, and it's fixable without a rebuild. Send us the store URL for a free audit and we'll tell you which half needs the work.