Shopify theme detector: a worked Shopify study

What you would do

A client says the theme is custom. You paste the store. Suppose the finder returns Dawn, from the Theme Store. The project is then the product template, the cart, and the section order, not a new theme. A theme renamed “Copy of Dawn” is still that answer. The finder does not show how many sections were edited, so the next hour is the theme editor in the admin, not a rebuild quote.

Suppose instead it returns custom. You would ask for the theme files before you name a price. The theme finder is the public half of that conversation. The app detector is the other half.

Before you change the store

These are examples. Run the tool on your own URL or your own costs. That result is the one to act on. Do not put an example in a deck as if it were your store.

Say the pitch calls it a custom theme

Say a salesperson, a supplier site, or a freelancer shows you a shop and calls the theme custom. The shop sells aluminium phone stand at 29. Say the sheet also shows a cost of 6. Say outbound ship is listed at 5. The page looks tidy: a gallery, a price, two finishes, a short story about the metal, a shipping line. Nothing on the page proves who built the theme. The claim is about the container. The page is about the product. You keep those apart on purpose.

You run the public theme check on that domain. Say the result names Dawn, and it labels the theme Theme Store. You now have a conflict you can write in a single line: the pitch says custom, the published storefront identifies as Dawn. You do not need to accuse anyone of a motive. Renames happen. Designers work inside Dawn and still feel they built something. The line is enough to reset the quote.

You do not invent a quality score from that line. Dawn can hold an excellent product page. Dawn can also hold a neglected one. The hypothetical stops at identity. You also do not invent a speed comparison between this shop and a custom build. Nobody timed either page in this exercise. If the pitch deck includes a load-time claim, you set that claim aside until someone measures the product URL with a method you accept.

Example of the note you write the same day: public theme Dawn, Theme Store. Pitch language was custom. Admin nickname unknown until we log in. Product in view is the stand at the stated price. Next step is the theme editor, not a new theme purchase. That note is the whole outcome of the detector. Everything after it is editor work.

Put the public name beside the quote

Read the quote again and underline every deliverable that depends on the word custom. Common ones: a unique section system, ongoing code maintenance, a claim that the shop cannot move themes later, and a price that assumes a from-scratch build. Next to each line, write whether Dawn already does that job with sections. A unique section system is the line that usually shrinks. Ongoing maintenance may still be real if they edited files. The detector did not open files, so maintenance of code stays unproven. You ask, you do not assume.

For aluminium phone stand, list the page jobs the buyer actually needs. See the stand. Read 29. Choose a finish. Add it to the cart. Understand the material. Understand delivery. Dawn product templates are built to carry the first four through the product form and the gallery. Material and delivery can be sections. If the quote proposes a custom theme so the price can sit near the photo, you are looking at a section setting, not a platform change.

Ask one question in writing: which theme files did you edit, and what breaks if we take a theme update? If the answer is none, the commercial word custom should come off the invoice. If the answer is a specific file, you still are not buying a mystery. You are buying those edits, and you can ask to see them in the code editor with the merchant account present. The detector result does not replace that viewing. It tells you the viewing is worth doing before you pay.

If they refuse the login and refuse to reconcile the Dawn name, you have a commercial problem, not a theme problem. You can decline. You can also keep Dawn, ignore the pitch, and hire someone to edit sections at a rate that matches section work. The hypothetical does not require a dramatic reveal. It requires the name and the quote to sit on the same page until the deliverable matches the name.

What you still verify inside the editor

Say you receive a staff login. You open Shopify admin, Online Store, Themes, Customize. You select the product template that aluminium phone stand uses. You expected Dawn sections, and you either see them or you see something that needs a question. The detector already said Dawn. The editor shows whether this product template still looks like a Dawn product template plus content. You might find extra sections. You might find an app block where the form should be. You write what you see. You do not go back and change the detector sentence. It was about the public theme, and it was right or wrong on that point only.

Say the form is the theme form. Title, price, variant picker, buy buttons are present. The two finishes are variants. You did not need a custom theme for that picker. Say a collapsible section already holds a materials blurb and someone duplicated the same blurb in an image-with-text section. The edit you recommend is deletion of the duplicate, not a rebuild. This is ordinary Dawn housekeeping. It looks like "custom work" only if nobody opened the template.

Say instead you find heavy file changes: the product template no longer matches what a fresh Dawn shows, and the freelancer can point at the files. The public name remains Dawn. Your brief changes from "this is a rename" to "this is Dawn plus these file edits." You still do not describe a percentage of the theme rewritten. You did not measure one. You name the files they showed you and the buyer-facing symptom, such as a picker that lost its label on small screens.

App embeds are the other editor check in this hypothetical. Say a review app and a chat app are enabled on the published Dawn and off on a duplicate called Brand custom. The duplicate looks quieter in preview. That quiet is missing embeds, not a superior design system. You write: do not judge Brand custom until embeds match, or until we intentionally disable them on both. The theme name on the duplicate may still identify as Dawn. The nickname Brand custom is the trap the pitch used.

A brief that stays inside the evidence

Example brief, which you can hand to a freelancer after this hypothetical: The shop publishes Dawn, Theme Store. The sales name custom is not the public theme name. Product to edit: aluminium phone stand, price 29, template as assigned in admin. Keep the product form. Add or tighten a materials section using Dawn sections. Do not install a page-builder app. Do not publish a different theme. Do not quote a speed improvement. File edits only if you first show the file and the reason a section cannot do the job.

The brief has exits. If the freelancer opens the template and the form is an app, they stop and tell you the app name. If the product uses an alternate template, they edit that template only. If they believe a theme change is required, they list the section Dawn cannot provide. "It would look better" is not a list. You are allowed to want it to look better. You are not buying a migration on a mood.

The brief also tells you how you will accept the work. You will open the live product URL, confirm Dawn is still the published theme if they were not hired to change it, click both finishes, and read the materials text once. You will not accept a screenshot of a preview theme with embeds turned off as proof. You will not accept a before-and-after speed number they produced on their own laptop as part of this scope.

Say the same shop had returned custom instead of Dawn. The brief would start differently: public theme does not match a Theme Store theme, so do not assume Dawn sections. First session is a template inventory on the product URL only. Still no speed number. Still no claim about how heavily files were edited until someone opens them. One hypothetical, two possible names, same discipline. The discipline is the point of writing the result down before the quote.

The morning after the pitch

The next morning you are not hunting for more theme names. You have Dawn on one line and the pitch on the next. You schedule the editor session. You pick aluminium phone stand as the only product in scope so the session cannot wander into the homepage. You ask whoever owns pricing to confirm 29 is the live price, so you do not art-direct a draft. If cost or ship sits on an internal sheet, it stays there. The theme brief does not need margin to decide whether the form remains the form.

You reply to the salesperson with the public name and a narrower ask. You want section work on the current theme, or you want them to show file-level changes. You do not ask them for a case study, a percentage, or a competitor teardown. Those requests invite invented numbers. You already have the only number this check produces, which is not a number at all. It is a name.

If they send a new preview theme, you repeat the public check only after it is published somewhere you can load, or you simply read the theme library with your login. Unpublished previews are judged in the editor, with the template dropdown on the stand, with embeds compared. You keep the original note. You add a second note for the preview copy. You never merge the two nicknames into one row.

When the editor session ends, the pitch is either a section invoice or a declined project. Both are clean outcomes. A muddy outcome is a "custom theme" line item that nobody can point to in Customize. The hypothetical exists so you recognize that line item the next time a renamed Dawn shows up with a new nickname and the same product form underneath.

Shopify questions