How to hire a Shopify developer without getting burned

To hire a Shopify developer without getting burned, judge them by live stores they’ve built and by calls with their past clients. Ask how they handle themes, apps, performance, accessibility and mobile design. Before work starts, get code ownership, your own admin account and the handover written into the contract.

A lot of the store owners who come to me have been burned by an earlier hire. Often the developer was competent but didn’t ask the right questions at the start. Or the store went live carrying app subscriptions the owner is still paying for every month.

If you’ve never hired a developer before, the checklist in choosing a technical partner applies here too. This guide is the Shopify version.

Five questions to ask first

Five questions rule out most of the market before a second meeting. Ask them in this order.

1. Do you build custom themes, or start from a marketplace theme? The answer tells you whether the store will be built around your brand and products, or be a ready-made theme with your logo on it. Both have their place, but they differ a lot in cost, speed and how far they can be changed.
2. Do you build custom apps, or reach for paid apps first? Hardly anyone asks this. A cheap build can end up costing more in monthly app subscriptions than it saved, for as long as the store runs. One custom app can often replace several paid ones for a one-off cost.
3. How do you measure performance, and what’s your target? “We make it fast” isn’t an answer. You want a page-weight budget, a target for Largest Contentful Paint (how long the main content takes to appear), and an explanation of how theme decisions affect Core Web Vitals, Google’s three page-speed measures.
4. How do you handle accessibility? A good developer has an answer, and the usual baseline is WCAG 2.2 AA. If they don’t have one, expect a store that people using a screen reader can’t buy from. The Equality Act 2010 expects UK businesses, online shops included, to make reasonable adjustments for disabled customers.
5. What’s your mobile-first process? Your analytics will show how many of your shoppers are on phones. A developer who designs for desktop first and squeezes it down is designing for the wrong screen.

Why most Shopify stores are slow and expensive

Two things slow down more Shopify stores than anything else: bloated themes and app stacking.

A marketplace theme is built to look fine with any product, image and copy. So it loads JavaScript you don’t use, CSS for features you’ll never switch on, and section options you don’t need. It’s a car sold with every optional extra fitted, whether you wanted heated seats or not. The store ends up heavy on its first load, and slow on a phone signal before your products appear. Much of that weight can come back out with Liquid and theme optimisation, if the developer knows where to look.

Then come the apps. Every third-party app loads its own script, often one that holds up the page while it loads, and often from a server you don’t control. Each one delays the moment your shoppers see the main content. The build is paid for once, but the app bill arrives every month. Most slow Shopify stores are slow for this reason, and it usually starts with the choice of theme.

A developer worth hiring will question an app-first approach. “Do we need an app for this, or can it go into the theme?” is the question they should be asking on your behalf.

What the Shopify Partner badge means

You’ll see the Shopify Partner logo on a lot of developers’ websites. It tells you less than it seems to.

Shopify Partner is a free programme anyone can join by filling in a form, which takes a few minutes. There’s no vetting, portfolio check, interview or technical review. The badge says someone has signed up. It says nothing about the quality of their work.

The Shopify Partner Directory, once the Shopify Experts marketplace, works differently. Developers can’t simply sign up: Shopify invites them once they reach a partner tier, and the tiers are set by the revenue and the number of stores they’ve brought to Shopify (Shopify Help Center). That filters out hobbyists. It also makes a listing a measure of sales: it tells you a developer has brought Shopify a lot of business.

Many hiring guides tell you to start with the Partner Directory. I’d treat it as a list of names at most. The proof that’s harder to fake is this:

• Live stores you can visit and buy from. Screenshots and case-study PDFs don’t count. You want real addresses where you can load a product page, add something to the basket and see how it feels. Where a client asked to stay anonymous, as in my Shopify jewellery case study, ask the developer to show you the live store on a call.
• References from previous clients. Phone calls with people who’ve paid them, rather than testimonials on the developer’s own site.
• A portfolio of problems solved. What did the store do before, what does it do now, and what changed and why?
• A writing trail. Blog posts, talks or open-source work, anything that shows how they think.

Red flags to walk away from

People and process

• Senior pitch, junior delivery. Two senior developers sit in the sales meeting. Once the contract is signed, the work goes to a junior you’ve never met, with no one reviewing it. Ask in writing who will do the work, and get names.
• No discovery. If a proposal arrives before they’ve asked about your customers, products, delivery and systems, it was written for a template.
• No references. A developer whose clients are happy will put you in touch with them.

Skill and proof

• No live stores in the portfolio. Designs, mock-ups and “we worked on this” with no link. A developer who has built stores can show you them.
• Can’t explain Liquid in one sentence. Liquid is Shopify’s templating language, and it runs the whole storefront. A Shopify developer can say what it does.
• Promises to do everything. SEO, branding, copywriting, ads, email, development, apps and fulfilment. A specialist will tell you what they don’t do.

Commercial terms

• One quote with no detail. A proper proposal breaks the work into discovery, design, theme development, custom app work, integrations, testing, launch and support after launch. A single “all in” line leaves everything you didn’t specify out of scope.
• No milestones. Staged delivery against milestones you sign off is the norm. Paying for everything up front leaves you carrying all the risk.

Scope, ownership and handover

Most contract problems sit here, and they have nothing to do with the build itself.

Fig. 01 Ownership rest

Who owns the code

Under UK copyright law, a contractor owns the code they write for you unless a written contract assigns it to you. That matters on the day the relationship ends and you want to take the store to someone else. Before you sign, ask for a clause that assigns all custom code, custom apps and theme changes to you on final delivery. A licence isn’t enough. You want an assignment.

Who owns the Shopify admin

Your store should be registered under your email address and billed to your company. If a developer sets the store up under their own account and adds you as staff, they can lock you out at any time. Check this on the first day.

What’s in the handover

When the work ends, you should have:

• All the theme’s source files, including the Liquid templates and the sources behind the compiled CSS and JavaScript.
• The Git history for every custom app. A developer who doesn’t use Git should at least document the code in full, and the missing history is worth asking about.
• Admin access to every third-party service set up for you, such as Klaviyo, Gorgias or Judge.me.
• A written runbook for the integrations, webhooks and scheduled jobs unique to your store.
• A documented handover of passwords and keys, rather than credentials sent in chat messages.

What’s included after launch

Get the period after launch in writing. Two weeks of warranty fixes is common, and anything broken during launch should be fixed without a new contract. Keep that separate from maintenance and new features, which belong to a different arrangement.

Agree all of this before work starts. Adding it at the end of a project is where most disputes begin.

What changed on Shopify in 2026

Ask any Shopify developer you’re considering whether they’ve moved a store off Shopify Scripts. A developer who worked on Shopify this year will have done it.

Scripts, the old way of customising checkout in Ruby, stopped running on 30 June 2026 (Shopify developer changelog). Shopify Functions and Checkout Extensibility replaced them. Stores that hadn’t migrated lost what their Scripts did: discount logic, shipping rules and payment method filtering.

It was a platform-level change that reached every store with real checkout customisation. A developer who hasn’t handled it is working from an older playbook.

The same goes for Online Store 2.0 sections, metaobjects, Storefront API changes and headless builds for larger stores. Your developer doesn’t need to be an expert in all of it. They should know which parts apply to your store.

Does it matter if your Shopify developer is local?

Not for skill. A Shopify developer in Manila and one in Liverpool can do work of the same quality. Being close buys you other things:

• Accountability. A developer in your time zone can’t disappear behind a twelve-hour time difference when something goes wrong.
• Shared working hours. Launches and urgent fixes happen during your working day, with someone there while they happen.
• Meetings in person. Not every project needs them. Some do.
• Legal recourse. If a dispute escalates, chasing someone through another country’s courts isn’t a realistic option.

For most small businesses, hiring locally is about having someone you can hold to account. Hiring remotely can work well too, as long as you’ve weighed what you give up.

Working with me

I build and look after Shopify stores for retailers in Liverpool, Chester and across Cheshire. The first conversation is about your current store: what it does well, which app subscriptions you could drop, and whether it’s worth rebuilding or fixing.