A defined piece of work
Project
Fixed scope, fixed priceTwo weeks to three months
- Written scope before any code
- A named engineer for the duration
- Weekly written progress, not status calls
- Best for a build with a clear finish line
Hire a Shopify Developer
Not a marketplace profile and not a rotating pool. The same engineers who build and maintain five published Shopify apps, available on contract, retainer or by project.
- Apps live on the Shopify App Store
- US, UK and Europe overlap hours
- You own the code from day one
Most Shopify hiring goes wrong before the interview. The job is scoped as "a Shopify developer" when what is actually needed is a theme specialist, an app engineer, or someone who can do both — and those are different people. This page is about telling them apart before you commit.
Which developer do you actually need?
The situation you are in, and who solves it
"Shopify developer" covers at least four distinct skill sets. Hiring the wrong one is the most common and most expensive mistake in this market — the work looks similar from the outside and is not similar at all.
| Your situation | Who you need |
|---|---|
| The storefront needs to look and behave differently | A Shopify theme developer. Liquid, Online Store 2.0 sections, the theme editor. Someone who thinks in merchandising as much as code. |
| You need functionality Shopify does not have | A **Shopify app developer** — see Shopify app development. OAuth, webhooks, the Admin API, billing, App Store review. A different discipline from theme work, with a different failure mode. |
| Shopify has to talk to your ERP, PIM or warehouse | A full-stack developer with Shopify experience. The hard part is rarely Shopify — it is the system on the other side and the sync between them. |
| The storefront is slow and nobody knows why | A performance-focused theme developer. This is usually a two-week engagement, not a hire — why storefronts load late. |
| You need all of it, occasionally | A retained team rather than an individual. Most brands under $10m do not have enough continuous work to keep one specialist busy, let alone three. |
| You have a developer and they are overloaded | Augmentation. Someone who works inside your repo, your process and your standards rather than running a parallel project. |
Engagement models
Three ways to work with us
Most Shopify work does not need a full-time hire, and most agencies will not tell you that. Pick the shape that matches the work rather than the one that matches a contract.
Ongoing work, no full-time hireMost common
Retainer
Monthly block of hoursRolling, one month notice
- A named engineer who learns your store
- Priority on anything urgent
- Unused hours roll one month
- Best for a store that keeps needing changes
You have a team, it is short-handed
Augmentation
Day rateWeekly, scale up or down
- We work in your repo and your process
- Your standards win, not ours
- Your review process, your branching model
- Best for adding capacity without hiring
Rates depend on the engagement and are quoted after the technical call — not before it, because a number produced by guessing is either padded or wrong.
What our developers work on
Every engineer here works across client projects and our own published apps. That is deliberate — running your own software on the App Store teaches things client work never does, starting with what breaks at 2am.
What hiring us includes
The things that should be standard and usually are not
Every point below is something we have been asked to promise by a client who had been burned by an agency that did not.
- Your repository, from day oneCode lands in your GitHub, not ours. There is no handover event because there is nothing to hand over.
- Commits you can readSmall, described, reviewable. Not one 4,000-line commit at the end of the month.
- Comments that explain whyOur code explains decisions, not syntax. Whoever inherits it — us or your next developer — can tell what we were thinking.
- Direct access to the engineerYou talk to the person writing the code. No account manager relaying technical questions in both directions.
- Overlap hours you can rely onAsync-first with scheduled overlap for US, UK and European time zones. Agreed before we start, not negotiated later.
- An honest noIf what you are asking for is the wrong solution, we will say so before you have paid for it.
- Staging before productionTheme changes on a duplicate theme, app changes on a development store. Nothing goes live untested.
- A defined exitYou can end an engagement and keep working. Nothing depends on us continuing.
How hiring works
From first message to first commit
No sales process. The first conversation is technical, because it has to be — we cannot scope work we do not understand.
- Tell us what is broken or missingA paragraph is enough. Store URL, what you need, and any deadline. We reply within one business day.
- A technical callThirty minutes with the engineer who would do the work. We ask about your stack, your team and what has been tried already.
- A written scopeWhat we would do, in what order, what it costs, and what we would not do. If we think you need less than you asked for, that is in writing.
- Access and setupCollaborator access to your store, a repository, a staging theme or development store. Usually a day.
- Work starts, visiblyCommits from the first day. Weekly written updates. You see progress rather than hearing about it.
What we work in
The stack, grouped by where it does its work
Not a badge wall. Four layers — the Shopify platform, the extension surfaces, the application behind it, and the data underneath — because a Shopify developer works in all four and the interesting problems live where they meet.
Shopify platform
Liquid, Storefront API, Admin GraphQL, webhooks
The storefront is Liquid, CSS and JavaScript. Everything behind it is the Admin GraphQL API and webhooks. We work against the current API version rather than a pinned one — deprecations land on a date, not on an upgrade.
- Liquid
- CSS
- Sass
- JavaScript
- Shopify Storefront API
- Shopify Admin GraphQL
- Shopify Webhooks
- Metafields
- Metaobjects
- sections/product-bundle.liquid01
- extensions/app/blocks/widget.liquid02
- app/routes/webhooks.orders.paid.jsx03
- app/graphql/themeFiles.js04
Extension surfaces
Theme, checkout and post-purchase
Theme app extensions for the storefront, checkout UI extensions and post-purchase extensions where the platform allows them. Never script tags — Shopify stops running those on 1 March 2027.
extensions/checkout-ui/src/Checkout.tsxApplication layer
Node, Remix, TypeScript, React
Shopify's own app frameworks with Polaris and App Bridge, so an embedded app behaves like part of the admin. Next.js and Tailwind for storefronts and custom applications around the store.
const { admin } = await authenticate.admin(request);Data and messaging
Postgres, MongoDB, Prisma, Redis, RabbitMQ
Relational where the shape is stable, document where it evolves. Redis for caching and rate limits, RabbitMQ for the work a webhook must not do inline.
await queue.publish('inventory.sync', { shop, sku });Before you hire
- It depends on the engagement rather than the hour. A defined project is quoted as a fixed scope. A retainer is a monthly block of hours with a named engineer. Augmentation inside your team is usually a day rate. We quote after the technical call, because quoting before it means guessing — and a number produced by guessing is either padded or wrong.
- Yes. A performance audit, a Shopify API version upgrade or an app review submission are all short, well-defined pieces of work. Not everything needs to be a project, and we would rather do two useful days than invent a two-month engagement.
- Yes — that is the most common augmentation arrangement. We work in your repository, follow your branching model and go through your review process. If your standards differ from ours, yours win; it is your codebase to maintain afterwards.
- We work async-first with scheduled overlap. In practice that means a reliable window with US Eastern, UK and Central European teams. Overlap hours are agreed before an engagement starts rather than discovered during it.
- You keep the code, the repository and the documentation, and you can continue with another developer or in-house. There is no lock-in, no proprietary framework and nothing that only we can maintain.
- We work on Plus stores. The parts that are genuinely Plus-specific — checkout extensibility, higher API limits, multiple storefronts on one catalogue, B2B — are the parts worth talking about on a call, because whether Plus is solving your actual constraint is a question worth asking before you pay for it. Our theme, rebuild or headless piece covers where that line sits.
- Mostly continuity and accountability. A marketplace optimises for finding someone quickly and cheaply, which works well for bounded tasks. It works badly when the work needs someone who will still be reachable in six months, who understands why a decision was made, and who takes responsibility when something breaks in production.
- Frequently, and it is worth being honest that this is harder than starting fresh. We would begin with an audit — what exists, what works, what has to be replaced — and give you that in writing before proposing any work. Sometimes the answer is that the existing code is fine and only needs finishing. See our work for builds we have inherited and finished.
Still deciding?
Send us the store URL and what you are trying to do. If the honest answer is that you do not need to hire anyone, we will tell you that instead.
Our talk
Tell us what you need
A paragraph is enough. Store URL, what you need built or fixed, and any deadline. A developer reads it and replies within one business day.
