Shopify Website Design Services: The Hidden Line Items

What “Shopify website design services” actually means

The phrase covers two different jobs that get quoted as one. The first is theme customisation: starting from Dawn or a paid Shopify theme and changing its sections, colours, and layout inside that theme’s existing structure. The second is a custom theme build: a Liquid codebase written from a design with no starting template, giving full control over every interaction at the cost of longer timelines and ongoing maintenance the theme’s original author no longer owns for you.

Most quotes don’t say which one they’re pricing. A merchant reading “Shopify website design services, from $X” assumes a finished, working store. What’s usually being sold is a build fee: the design and development labour. Everything the design depends on to run is priced separately and disclosed later, if at all.

The distinction matters most for stores doing $3M–$30M in revenue on Shopify Plus or a paid subscription plan. Below that floor, a theme swap with light customisation is the right scope and this level of scrutiny is overkill. At this scale, the site carries enough traffic and enough campaign pages that the gaps in a cheap quote become visible within the first quarter — as support tickets, as inconsistent landing pages, or as an app bill nobody budgeted for. A store weighing a full platform move rather than a redesign should read /blog/shopify-migration first — moving platforms and redesigning the front end are different projects with different failure points.

What a proper engagement includes

A Shopify website design engagement that is actually scoped, not just quoted, covers five stages, and each one should appear as its own line in the proposal rather than being folded into “design and build.”

UX and information architecture. Before any screen is drawn, someone reviews your current analytics (bounce points, search terms visitors use on your own site, which collection pages actually convert) and maps the new site’s navigation and page templates against that data, not against what looks good on a moodboard.

Design system. A documented set of components (buttons, product cards, typography scale, spacing tokens, form states) that every template pulls from. Without one, every new landing page a marketer builds six months after launch looks slightly different, because nobody who built it had a system to follow.

Build. The actual Liquid, CSS, and JavaScript work: theme customisation inside an existing template, or a custom theme from scratch. This is the part most quotes are actually pricing, even when the proposal implies it covers everything else too.

QA. Cross-browser and cross-device testing, checkout flow verification, accessibility pass, page-speed check. Skipping this is how a site that looks correct on the designer’s laptop ships broken on an older Android device or fails on Shop Pay’s one-page checkout.

Launch. DNS cutover, redirect mapping from the old URL structure, app reinstallation and reconfiguration on the live theme, and a rollback plan if something breaks during the switch.

If a proposal names only “design and development” as its scope, ask which of these five it covers and which it doesn’t. The answer determines whether the quoted price is the whole cost or the first third of it.

The pricing models, and what each one hides

Three pricing structures cover most Shopify design engagements, and each creates a different hidden cost.

Fixed price quotes one number for a defined scope. It protects your budget against overruns, but every request outside the original scope document becomes a change order. And “the original scope document” is where disputes happen, because it’s usually the vaguest part of the proposal.

Hourly bills actual time against an estimate. It protects the agency from under-quoting complex work, but leaves your total cost open until the final invoice, and gives no one an incentive to work efficiently once the estimate is exceeded.

Milestone-based fixed price: payment tied to phases (discovery, design approval, build, launch) with change orders defined upfront, gets closest to predictable cost without the incentive problems of pure hourly billing. It requires the proposal to name the milestones and what triggers a change order, which is exactly the detail thin proposals skip.

None of these three models is wrong. What matters is which one you’re actually being quoted, because a “fixed price” proposal that doesn’t define scope in writing behaves like hourly billing the moment you ask for anything not explicitly listed — you just don’t find out until the change order arrives.

The line items the published price omits

These five line items are what a quote’s headline number rarely shows, because none of it is the design or build labour — it’s what the finished design depends on to keep running.

The theme licence. A paid Shopify theme is bought from the Theme Store or a third-party marketplace, billed to your own Shopify account, not the agency’s invoice. If the design is built on a premium theme, that licence is yours to buy and yours to keep paying for if the theme has ongoing update fees. Ask which theme the design assumes and who pays for it.

The apps the design was built around. A page-builder section, a reviews widget, a bundle-and-upsell app, a size-chart tool: each is a separate monthly subscription the design depends on to look and work as demoed. The build fee covers installing and configuring them once; it does not cover their ongoing cost, and that cost compounds as you add more apps for more features. Get the full app list with its combined monthly total before signing, not after launch when removing one breaks a page.

Content production. Someone has to write the home page copy, the collection descriptions, the product template text, the about page for every template the design creates, not just one. Unless copywriting and photography are named line items with a deadline attached to the client, this falls on your team, usually discovered mid-project when the designer asks for copy that doesn’t exist yet.

Revisions past the agreed rounds. Two or three structured rounds (on wireframes, on the built site, on a final polish pass) is typical. A fourth round, or scope creep inside an existing round (“just move this section” on every page), is usually billed hourly once the agreed rounds are used up. Confirm what counts as one round before you start using them.

Post-launch support. Most contracts include a short free window (usually 30 days, though the exact term varies by agency) before support moves to an hourly rate or a retainer. Ask what breaks the day after that window closes, and who fixes it.

Stacked together, these five items regularly add up to as much as the build fee itself over the site’s first year. Not because any one of them is unreasonable to charge for, but because none of them appears in the headline number a merchant compares across proposals.

How to brief a designer so the quote can’t hide these costs

A brief that forces disclosure does more work than any amount of negotiating after the fact. Before requesting quotes, put in writing: your current analytics summary (top pages, conversion rate by template, known drop-off points); the exact list of apps the current site runs and which ones must carry over; whether content and photography are in scope or a client deliverable, with a date; and the number of revision rounds you expect, stated as a question to the agency rather than assumed.

Then ask every agency quoting the same three questions: what theme is this priced on, and who owns the licence; what is the full monthly app cost once the build is live; and what happens on day one after the support window ends. A proposal that answers all three in writing is comparable to another proposal that does. One that answers none of them is a number, not a quote.

Red flags worth walking away from

A single total with no phase breakdown is the first sign the quote is a placeholder, not a scope. No named theme, and no stated licence status, means you’ll find out what you’re actually building on after the contract is signed. No app list means the real monthly cost of the site is unknown until launch, when removing an app the design depends on breaks a template.

No stated revision limit is a negotiation deferred, not avoided. It will happen mid-project, at the point of maximum leverage for the agency. And no answer to “who owns the code and the Shopify admin” is the one red flag worth treating as disqualifying: a build you can’t move to another team if the relationship ends is not a website, it’s a dependency. This is also why agency selection deserves its own scrutiny before a design contract is signed. See /blog/shopify-plus-agency for the questions to ask before committing to any single team.

When it stops being worth paying for design services

A full engagement (UX review, design system, custom or heavily customised build, QA, launch support) stops being the right spend once the site’s problem isn’t the design. If conversion is flat because checkout is abandoned at payment, because product data is wrong across channels, or because a support team is buried answering “where’s my order” instead of higher-value work, a redesign changes how the store looks without touching why it’s underperforming.

That’s an operations problem before it’s a design one, and it’s usually better solved by the workflows behind the site than by the template in front of it: the returns process, the inventory sync, the automated response that answers a repeated question before a human sees the ticket. Merchants comparing app costs for that kind of automation will run into task-based pricing (Zapier, Make) versus execution-based pricing (self-hosted n8n); the current terms for each are worth checking directly on the vendor’s pricing page rather than assumed from an old quote, since limits and unit definitions change.

That’s the work Pointerflow does as AI agents and automation, not as a design engagement — building the workflows that run inventory sync, order exceptions, and support triage on your own infrastructure, so the fix addresses the process losing revenue rather than the paint on top of it. See /services/ai-agents for how that scope is defined.