Most of what you would naturally screen a Shopify developer on has an expiry date, and several of those dates have already passed. The badge on an agency's homepage, the framework named on a CV, the checkout customisation someone is proud of shipping: each was current once. Some are not current now.

That makes Shopify unusual among developer platforms. Depth is normally hard to verify from the outside, which is why hiring managers reach for credentials. On Shopify the credentials are the part that broke first, and the platform publishes enough dated material that a non-technical buyer can check the important things without an engineer in the room. The job splits three ways underneath the title, into theme code, storefront code and app code. I take the credentials first, because that is the part a buyer can check today without help.

TL;DR: Shopify sunset the Experts brand in December 2023 and the Plus Partner programme in December 2024, and states plainly that these brands should not be used. Shopify Scripts stopped executing on 30 June 2026, and 26 August 2026 is the deadline for non-Plus merchants to upgrade their Thank you and Order status pages. Screen on what someone migrated and when, and treat "Shopify developer" as three kinds of work that happen to share a phrase.

The credentials most buyers screen on were retired by Shopify

If a vendor leads with "Shopify Expert" or "Shopify Plus Partner", they are quoting a programme that no longer exists. Shopify's own partner documentation lists three separate sunsets: "The Shopify Experts brand and corresponding Shopify Experts Marketplace was previously sunset in December 2023", "The Plus Partner program was sunset effective December 2024", and "The Plus Certified App Program (PCAP) and Technology Track tier (Plus, Premier, Platinum) brands were sunset in December 2025 in favor of the new Certified Technology Partner Program" (Shopify Help Center, About the Shopify Partner Program).

Then comes the sentence that turns this from trivia into a screening tool. On the same page, Shopify writes: "These program brands should not be used beyond the sunset dates above." That is not me interpreting a deprecation notice. It is the platform asking vendors to stop, in writing, on a page anyone can open.

I want to be careful about what this does and does not tell you. An old badge sitting in a footer nobody has edited is a housekeeping problem, and it says nothing about the quality of the work. What I check is whether the badge is doing work in the pitch. If it appears on the homepage, in the proposal, and in the first call as the reason to trust them, you are being sold a credential that Shopify retired in December 2023 and December 2024 respectively.

"Plus" now names four different things

The word carries opposite implications depending on which of four things is meant. There is Shopify Plus, the merchant subscription plan for selling in high volume. There is the Plus Partner programme, retired in December 2024. There is Plus, a live tier inside the current Partner Program. And there was the Plus Certified App Program, retired in December 2025.

So "we are a Plus partner" might mean a current tier placement, or a dead badge, or nothing at all. Ask which one, by name. A vendor who cannot answer that question about their own marketing is telling you something useful.

What the new tiers actually measure

The current Partner Program is tiered. All partners begin on the Registered tier and progress through Select, Plus, Premier and Platinum, and the Partner Directory sets its bar at "Earn Plus tier or above through commercial impact and credential achievement", though the same page notes that "A limited number of Registered tier partners are also eligible for a directory listing" (Shopify Help Center, Partner Directory eligibility).

Read that phrase carefully, because both halves measure the firm. Commercial impact means revenue Shopify attributes to the partner. Credential achievement is counted across the organisation: "A minimum of 10 Shopify Verified Skills attained across all active employees at your partner organization", with "At least 3 people at your partner organization must have earned at least one Verified Skill" (the same page). Those are real signals about a company. Neither half says anything about the individual who will write your Liquid.

This is the same gap I wrote about in hiring Salesforce developers, where certifications prove structured study without proving production judgement. The Shopify version is sharper, because the metric being measured is not even about the engineer.

Theme, storefront and app code run in three different places

Counting job titles gets you nowhere useful. What I sort candidates by is where their code executes, because that determines who can debug it at two in the morning.

Theme code is written in Liquid, "a template language created by Shopify" (Shopify Liquid reference), and it lives inside the hosted online store. Since Online Store 2.0 in June 2021, page types can be rendered from JSON template files, and "merchants can add sections to all pages, not just the home page" (Shopify Partners blog, June 2021). A theme developer whose mental model stops at editing .liquid files is working pre-2021 in practice.

Storefront code runs on infrastructure you choose and pay for. Shopify's own framework for that is Hydrogen, "a React-based framework for building custom storefronts on Shopify" (Shopify Storefront API docs). Hydrogen is optional: the headless documentation offers "Build your own stack" and invites you to "Build custom experiences with any language and any framework" (Shopify headless docs). So a headless hire needs a framework decision made before the search starts, and someone who has only used Hydrogen may be the wrong fit if your front end is already Vue or Svelte.

App code runs in Shopify's app runtime and talks to the Admin API. Shopify's template now uses React Router, and Shopify's own repository documents the lineage, describing the template as forked from the Shopify Remix app template "and converted to React Router" (Shopify app template repository). On the data side, "The REST Admin API is a legacy API as of October 1, 2024" and "All apps and integrations should be built with the GraphQL Admin API" (Shopify REST to GraphQL migration). That migration page published no final shutoff date when I checked it in August 2026, so treat it as a direction of travel.

Hydrogen moved off Remix, and that dates a CV to the month

In May 2025 Shopify announced: "With this release, Hydrogen is upgrading from Remix 2 to React Router 7" (Shopify developer changelog, May 2025).

That gives you an unusually precise instrument. A CV, capability deck or job specification that still says "Hydrogen (Remix)" was written against a stack Shopify moved away from in mid-2025. It disqualifies nobody, and a good engineer will have followed the migration without fuss. It does tell you when that document was last thought about. Dating a CV by the vocabulary in it is a habit I apply across platforms, and I have used the same trick on data engineers; Shopify just publishes an unusually clean date to anchor it to.

Shopify Functions run on WebAssembly, and Rust is not always optional

Functions are the exception to the three-way split above. They compile to WebAssembly, and Shopify describes their targets as injecting "code into the backend logic of Shopify" (Shopify Functions). Shopify's guidance on Rust there is easy to read as an absolute requirement. The page is more precise than that, and the precision is worth knowing before you narrow a shortlist.

Functions "support any language that compiles to WebAssembly (Wasm), such as Rust, Zig, or TinyGo", so Rust is not a platform-level requirement (Shopify Functions language considerations). But the same page then directs you to it in three named cases: "If your function targets a public app, expects to operate on a large number of line items, or is computationally complex, then choose Rust to stay within the Shopify Functions instruction count requirements." On JavaScript it says: "For prototyping ideas, JavaScript is a good starting point if you're familiar with the language", with the warning that you should "expect to run into instruction limits sooner than if you wrote the equivalent function logic in a language that compiles to WebAssembly directly, such as Rust".

So the useful screening question is which of Shopify's three conditions your function meets. If it is going into a public app, Shopify's own answer is Rust, and a candidate who reaches for that distinction unprompted has read the page you are both relying on.

Theme app extensions are the question that separates careful from cheap

Ask a candidate why they would build a theme app extension instead of editing theme code directly, and listen for whether they reach for the risk argument. Shopify's reasoning is explicit: apps built that way "don't edit theme code, which decreases the risk of introducing breaking changes to the theme, makes it easier to iterate on the content of the integration, and provides for a better merchant experience" (Shopify theme app extensions documentation).

I like this question because it has almost nothing to do with syntax. It tests whether someone thinks about what happens to your store six months after they leave, when you change theme and every hand-edited snippet disappears with it.

Shopify Scripts stopped executing in June 2026, and non-Plus checkout pages follow on 26 August

Shopify Scripts is gone. It was written in "a limited version of the Ruby programming language" and handled discount, shipping and payment logic (Shopify Help Center, Script Editor). Shopify's changelog gave two dates. On 15 April 2026, "Editing and publishing new Shopify Scripts will no longer be possible." On 30 June 2026, "All Shopify Scripts will cease to execute entirely" (Shopify developer changelog, 9 April 2026). The replacement is Shopify Functions.

Checkout went the same way, though without a single published date for the step pages: "checkout.liquid is now unsupported for the Information, Shipping, and Payment checkout steps" (Shopify checkout.liquid documentation), and the customisation route is now checkout extensibility, which Shopify announced in February 2023 as "a new foundation for checkout and accounts that is more secure, upgrade-safe, and customized using apps" (Shopify Help Center, checkout extensibility).

The post-purchase pages have a firm date, and it is 26 August 2026. Shopify's guidance for merchants who are not on Plus reads: "August 26, 2026 is the deadline for stores on a non-Plus Shopify subscription plan to upgrade their existing Thank you and Order status pages to the new version of those pages", (Shopify Help Center, upgrade guide). Read the auto-upgrade language carefully, because Shopify scopes it narrowly: a store that upgraded, then reverted, is told that "If you don't upgrade your pages again before August 26, 2026, then your Thank you and Order status pages will be auto-upgraded to the new pages" (the same guide). The same date appears on a second Shopify page, which records that script tags "are sunset for non-Plus stores on August 26, 2026" (Shopify checkout.liquid documentation).

What the upgrade costs is stated plainly: "your existing Thank you and Order status pages and any existing customizations on those pages are replaced with the new versions of those pages" (the upgrade guide). If you are reading this after the date and nobody owned that migration, the screening question turns backwards: ask a candidate to audit what survived on those pages and what quietly stopped firing.

Freelancer, agency or in-house is a question about who owns the next deadline

Every risk above is a maintenance risk, so the staffing question is really about who is watching the changelog in eighteen months.

A freelancer from Upwork, Fiverr or Toptal is usually the fastest route to a defined piece of work, and for a bounded brief with a clear finish line that is often the correct answer. The weakness is continuity: when the next deprecation lands, the person who understood your theme may have moved on, and nothing in the engagement obliges them to tell you. An agency buys you that continuity and a bench, at the cost of the badge problem above, and you should ask which named engineer does your work, then check that name appears in the contract. In-house only makes sense once the store changes often enough to fill a role. The honest test is whether you can name twelve months of work.

There is a fourth option I raise on most platform searches, which is a retained relationship with someone who is not the builder. The person who audits what a departing developer left behind does not need to be the person who wrote it.

Sometimes the answer is an app from the Shopify App Store

A share of what merchants brief as development work already exists as a configured app or a theme setting, and building bespoke where the ecosystem has solved it is the most reliable way to overpay on Shopify.

Before writing a specification, search the App Store for the category. Subscriptions, product reviews, bundling, loyalty, upsell blocks and back-in-stock alerts are all crowded categories where a configured app costs a fraction of custom work and stays maintained by someone else through the next platform change. If an app covers eighty per cent of the requirement, the honest conversation is about the remaining twenty, not about a build.

The test I apply is whether the requirement is genuinely specific to how the business works. Custom discount logic that reflects a real commercial model, a storefront that needs to live inside an existing application, an integration with a warehouse system nobody has written a connector for: those need an engineer. A countdown timer does not.

How to screen a Shopify developer

1. Ask which badge they mean. If "Shopify Expert" or "Plus Partner" appears in the pitch, ask which programme and which tier. Both brands were retired, and Shopify asks that they not be used.
2. Ask what they migrated off Scripts, and when. Scripts stopped executing on 30 June 2026. Anyone doing serious discount or shipping logic through that period has a migration story, and the shape of it tells you more than any certificate.
3. Ask about the 26 August 2026 Thank you and Order status deadline. A developer who knows which plans it applies to, and that customisations are replaced during the upgrade, is someone who reads the changelog. That habit is most of the job.
4. Ask them to describe Hydrogen's underlying framework. "React Router" is current. "Remix" dates their knowledge to before May 2025, which earns a follow-up question.
5. Ask which of Shopify's three Rust conditions your function meets. Public app, large line-item counts, or computational complexity. A candidate who treats Rust as dogma in either direction has not read the guidance.
6. Ask why a theme app extension beats editing theme code. Listen for breaking changes and theme swaps. Listen for whether they think past their own invoice.
7. Ask what they would not build. The best answer to a bespoke brief is sometimes an app from the store, and a developer who never says so is a developer who bills by the hour.

Every source above is Shopify's own published material, which is the right authority for what Shopify retired and deprecated, and worth knowing as you weigh it. The platform facts are Shopify's; the hiring judgements are mine, and those carry no citation because none exists.

The wider engineering hiring approach sits on my software engineering page, and the case for narrow screening over CV volume is in boutique versus volume recruitment.

Common questions about hiring Shopify developers

What does "Shopify Expert" mean now?

As a Shopify programme, nothing. The brand and its marketplace were sunset in December 2023, and Shopify's partner page states these brands "should not be used beyond the sunset dates above" (Shopify Help Center). Colloquially people still use it to mean an experienced Shopify developer, which is fine in conversation and misleading in a proposal.

Do we need a Shopify Plus developer?

Ask what the phrase is meant to convey first, since Plus names a merchant plan, a retired partner programme and a current partner tier. If you mean your store runs on the Plus plan, the relevant skills are checkout extensibility, Shopify Functions and B2B features, and each of those is testable directly. Hiring for the plan name alone tends to buy a price bracket.

Should we hire a freelancer or an agency?

It depends on who owns the next platform deadline. A freelancer suits a bounded brief with a clear finish line. An agency suits a store that keeps changing, provided you ask which named engineer does the work and not merely which tier the firm holds. Either way, settle the maintenance question in the contract, because the alternative is discovering it at the next deprecation.

What should we budget for a Shopify developer?

There is no methodologically sound public figure I can point you to. A number worth benchmarking against needs a named collecting body, a disclosed sample size, a disclosed collection window and a caveat about self-reported data, and the Shopify figures I can find on the open web carry none of the four. Benchmark against your own last two engineering offers, and against what candidates in live processes tell you they turned down.

---

If you are scoping a Shopify or wider e-commerce engineering hire and are not yet certain whether it is theme, storefront, app or Functions work, tell me about the role. I run two to four active searches at a time, which is why that scoping conversation happens before any CVs do.