What to check before you hire a Shopify developer
Seven things you can verify yourself before signing — using a developer's own past work, a browser, and about an hour. No technical knowledge required.
That is the short version. The rest of this is how to actually run each check, what a bad result looks like, and — the part most hiring advice skips — what each check cannot tell you.
Why this is hard, and why it is not your fault
Hiring a developer is the one purchase where the buyer usually cannot evaluate the thing being bought. You can taste food. You can sit in a chair. You cannot read a theme’s codebase, and the developer knows that.
So the category has drifted to proxies: years of experience, a portfolio of screenshots, a Shopify Partner badge, a confident call. None of those is evidence. A portfolio shows what a store looked like on launch day. It says nothing about whether the store still works, whether the merchant can edit it, or what happened when the first change was needed.
Before anything: ask for two stores, not a portfolio
Ask for two live stores they built, at least six months old. Not a gallery — URLs.
Six months matters. A store on launch day is a store nobody has touched yet. A store six months in has had products added, sales run, a homepage swapped, an app installed. That is where the build either holds or doesn’t.
Open the product page on your phone
Not the homepage. The product page, on your actual phone, on mobile data rather than your office wifi.
Run this yourself
The product page, on a phone
- Time until you can read the product name and see the price, from tapping the link. Over about three seconds on a normal connection means the page is doing work before it shows you anything. That is usually too many apps, uncompressed images, or scripts loading in the wrong order.
- Whether anything jumps after it appears — text shifting, an image pushing the button down. Movement after load means the page was built without reserving space for its own content. It is the single most common cause of a mis-tap on mobile.
- Whether the add-to-cart button is reachable with one thumb, without zooming. If you have to pinch or stretch, the page was designed on a desktop and checked on a desktop.
What this check cannot tell you. A slow product page might not be the developer’s fault. The merchant may have installed eleven apps since launch, or be running a review widget that loads 400KB of JavaScript. Ask. A developer who says “that store added four apps after we handed over, and here’s what that cost them” is telling you something better than a fast page would have: that they know, and that they warned.
Ask the merchant, not the developer
This is the highest-value check on this list and almost nobody runs it, because it feels awkward.
Email one of the two store owners. One question:
“Can your team change the homepage yourselves, or do you go back to the developer for it?”
| Criterion | “We change it ourselves” | “We ask them for anything” |
|---|---|---|
| What it says about the build | Content was made editable on purpose — sections, blocks and settings, rather than text baked into the theme. | Content was hard-coded where it could have been editable. |
| What it costs you later | A homepage swap is ten minutes of your own time. | Every small change is a paid ticket and a wait for availability. |
| What it says about the developer | They chose to reduce their own future billing. | They did not — though see the fair reading below. |
The honest version: The second answer is not automatically a bad sign. Some merchants ask for a hard-coded build because they have no team and do not want the editor to be breakable, and some briefs genuinely do not fund the extra work that flexible sections take. What you want is the reason. A developer who says ‘they wanted it locked down, here is why’ has made a decision; one who has never considered the difference has made a habit.
Most merchants will answer. It takes them ten seconds, and people are surprisingly willing to talk about a vendor they like — or one they don’t.
View-source, and you do not need to read code
Right-click any page of their work, choose View Page Source, and look at the shape of it rather than the content. You are not reading it. You are looking at whether a person organised it.
What you are looking for
- Indentation — does the structure step in and out in a regular pattern, or is everything jammed left?
- Comments — occasional lines in plain English explaining a section, or none at all?
- Chunks of inline styling repeated over and over, or a small number of stylesheet links?
- Search the page for 'TODO' or 'FIXME' — leftover notes to self that shipped to production
Messy source is not proof of a bad build. Shopify itself generates some of it, apps inject their own, and minified files are supposed to look unreadable. What you are checking is whether the human-written parts look like someone was paying attention.
Walk the checkout on a slow connection
Add something to the cart and go all the way to the payment step. Then do it again with your phone on a deliberately bad connection — turn wifi off, walk somewhere with one bar.
Run this yourself
Checkout, end to end
- Whether shipping cost appears before the payment step. Cost revealed at the last moment is the most expensive abandonment cause in ecommerce, and it is a build decision as much as a policy one.
- Whether the cart survives — close the tab, reopen the store. A cart that empties itself is a configuration mistake that silently costs sales, and nobody notices because the customer just leaves.
- Whether anything breaks or double-submits when the connection is slow. Most stores are only ever tested on fast office connections. Your customers are on trains.
The three questions, and what silence means
The checks above test the work. These test what happens after.
1 — “What happens in the first month after launch?”
You are listening for a defined period with a stated scope: what is covered, what is not, and for how long. A developer who says “just message me if anything’s wrong” is being friendly, not clear — and friendliness is not a commitment you can hold anyone to.
2 — “If I want to change this in six months and you’re unavailable, what does the next person inherit?”
The answer should involve documentation, a readable structure, and version control. The tell is whether the question surprises them. A developer who has thought about their own replaceability has thought about your interests.
3 — “What would you refuse to build?”
Anyone who has done this for a few years has a list — a pattern that breaks, an app that causes more problems than it solves, a request they now push back on. An answer of “nothing, whatever you want” is not flexibility. It means they have never been burned, or will not say so.
What this list does not cover
This article gets you a long way and stops well short of everything.
It cannot check accessibility properly — that needs testing with a screen reader, and eyeballing a page tells you almost nothing. It cannot tell you whether the theme’s structure will survive the next redesign, which is the single most expensive thing to get wrong and the hardest to see from outside. And it cannot judge whether an app was the right call, because that depends on what the merchant’s alternatives were.
Those are the checks that need someone who does this for a living — which is the honest reason this list is seven items and not thirteen.
But seven checks you can run yourself beats thirteen you have to take on trust. Run these before you sign, and you will have more evidence than most people have after their second meeting.