Five questions to ask before you pay for a Shopify theme

You cannot read Liquid. That is fine, you should not have to. But you are about to pay someone thousands of pounds for a theme, and "it looks good on the staging link" is a thin basis for judging whether the work is solid.

There are a handful of questions that tell you a lot, and they are answerable by a developer in a sentence each. None require you to understand code.

Why "it works" is not the same as "it is well built"

Two themes can look identical and behave identically on launch day, and be worth very different amounts over three years.

The difference shows up when things change. A new Shopify feature. A staff member editing content. A second developer picking it up. A theme update. At each of those moments, a well-built theme absorbs the change and a badly built one produces a bill.

The good news is that the practices which separate them are visible from the outside, if you know what to ask.

Question 1: "Do you run Theme Check?"

Shopify publishes a free tool called Theme Check. It reads a theme and reports problems: deprecated syntax, broken references, accessibility failures, performance patterns that will cost you.

It is free, it is Shopify's own, and running it takes seconds.

A developer who runs it has a theme with no known issues at handover. One who does not is shipping whatever happens to be there. There is no cost argument against it, so "no" is a genuine signal.

Follow-up worth asking: "Can I see the output?" A clean report is a one-line answer.

Question 2: "Does it run automatically, or when you remember?"

This is the one that actually matters, and it is where the honest answers diverge.

Running a check manually before handover means it was clean once, on that day. Running it automatically on every change means it stays clean, including six months later when someone makes a small edit under time pressure.

The automatic version is called continuous integration. In practice it means the check runs by itself every time code changes, and problems are caught the same hour rather than at the next audit.

You do not need to know how it is configured. You need to know whether it happens without someone choosing to do it.

Question 3: "How do you know a change did not break something else?"

Themes are interconnected. A change to a shared snippet affects every template that uses it. The failure mode is not a crash, it is that a section quietly stops rendering on one template nobody checked.

Reasonable answers: automated checks across all templates, a documented manual pass over the key ones, a staging store where the client reviews before anything goes live.

Unreasonable answer: "I test the page I changed."

Question 4: "What do I get on launch day?"

The list you want:

The full source, readable and commented. Not minified, not a page builder's proprietary format, not under a licence. Yours, outright, so any competent Shopify developer can maintain it.

Repeating content built as blocks. So your team can add a fourth testimonial without calling anyone. Test this yourself in the theme editor before you sign off.

A performance number in writing. "It will be fast" is not a commitment. A Lighthouse target with a re-test date is.

Somewhere the decisions are recorded. Why a thing was built the way it was. This is what a second developer reads first.

Question 5: "What happens when Shopify changes something?"

Shopify ships two API versions a year and continually adds theme features. Liquid tags get deprecated. Nothing is dramatic, and it accumulates.

The answer you want acknowledges this exists and names a rough cost. "A few hours a year, and here is what we would look at" is a real answer. "It will just keep working" is not, and the person saying it will not be the one fixing it.

What poor practice actually costs you

Not the build. The build is the same price either way, sometimes cheaper without the discipline.

The cost arrives later:

Every content change is a support ticket. Because repeating content was hardcoded rather than built as blocks. At a modest rate and one change a fortnight, that is thousands a year for things the theme editor should handle.

The next developer charges a premium. Or refuses. Undocumented, unchecked code takes longer to work with and everyone competent knows it.

Small changes cause unrelated breakage. With no automated checks, a change to a shared file breaks a template nobody looks at, and you find out from a customer.

Theme updates become archaeology. Custom code pasted into theme files disappears when the theme is updated, so someone has to work out what was there and put it back.

None of it appears on the original quote. All of it appears eventually.

The five questions, together

1. Do you run Theme Check?
2. Does it run automatically on every change?
3. How do you verify a change did not break another template?
4. What exactly do I receive on launch day?
5. What is the maintenance cost when Shopify changes something?

You do not need to evaluate the technical detail of the answers. You are listening for whether they are specific. A developer with good practices answers all five quickly, because they are describing what they already do. Vagueness on three or more is the signal.

And the cheapest test of all, which needs no developer at all: open the theme editor on the staging store and try to add a fourth testimonial. If you can, that tells you more than most of the questions.

---

Every theme we build runs Theme Check automatically on each change, ships with full source handover, uses blocks for repeating content so your team is not dependent on us, and carries a written performance target with a re-test date. Custom themes ship in 5 to 7 business days.

Commissioning a theme and want a second opinion on a quote? Book a free 30 minute call. Or see how we build themes.