One reproducible bug
A cart drawer that will not close on iOS, a variant selector that drops the second option, a form that silently fails.
We are a New York Shopify team you can buy in small blocks of hours, with no contract, no minimum monthly spend and no notice period. Buy five hours, get one job finished, owe us nothing next month. Hours cover theme fixes, Liquid changes, app configuration, integration debugging, Core Web Vitals passes, accessibility fixes and urgent breakages on a store that is already trading.
You buy a small block of senior Shopify hours, we write an estimate for each ticket in that block, we do the work on a duplicate theme, and when the hours run out the relationship ends cleanly. No contract, no minimum monthly spend, no notice period, no hours held hostage on exit. The smallest block is five hours.
The sequence is short on purpose. You send the ticket. We reply with an hour estimate and a range, usually within two business hours. You approve. We schedule the work into the next open slot, do it on an unpublished copy of your theme, and send you a preview link plus a written change note.
Hours come out of the block as they are used, and you can see the running balance any time you ask. Anything left over stays valid for twelve months. There is nothing to cancel, because there is nothing running.
This page exists because the usual agency answer to "can you just fix this one thing" is a discovery call, a proposal and a three month minimum. For one bounded job on a store that is already trading, that is the wrong shape and everybody knows it.
If what you actually want is a named senior engineer attached to your roadmap month after month, you want the other page. Hire Shopify experts covers retainers and embedded seats, where continuity, context and a standing SLA are the point. This page is the opposite trade: you give up continuity, and in exchange you give up the commitment.
A billed hour is not sixty minutes of typing. Roughly ten minutes goes on reading the store, thirty on the change itself, twelve on cross-device QA, and eight on the write-up and the preview link. Buyers who expect sixty minutes of typing are the ones who end up disappointed, so here is the honest split.
Open the theme, find the section or snippet, check which apps inject script on that template, reproduce what you reported.
Edit on a duplicate, unpublished theme. Never on the live one. Liquid, CSS, JavaScript, a metafield definition, an app setting, whatever the ticket needs.
Mobile Safari, Chrome, one tablet width, keyboard focus order, and the one adjacent template most likely to break.
Preview link, a plain change note saying what moved and why, and the exact files touched so your next developer is not guessing.
A cart drawer that will not close on iOS, a variant selector that drops the second option, a form that silently fails.
Install, configure, place the embed where it belongs, remove the leftover script from the last app that did the same job.
One existing theme section reworked to accept new settings, so your merchandiser can edit it without opening code again.
Find what is actually hurting Core Web Vitals on one template, fix the cheap wins, write down the expensive ones.
A webhook that quietly failed, a feed rejecting products, an email flow firing on the wrong trigger since someone renamed a tag.
The eight thirty-minute jobs that have been sitting in a spreadsheet since spring because none of them justified a project.
Those ranges are typical, not promises. Every one of them is re-estimated against your actual store before you approve anything.
Every ticket gets a written estimate with a low and a high number before work starts. We stop at the high number and message you rather than keep billing. Nothing above the estimate reaches an invoice without your written approval first. That is the whole mechanism, and it is the one thing hourly buying lives or dies on.
Two numbers, never one. A single number on an unfamiliar store is a guess dressed up as a commitment, and the gap always lands on the buyer.
At the top of the range the developer stops, even mid-change, and sends you what is done plus what is left. You decide whether to spend more.
If the overrun comes from us misreading a ticket we could have understood, the first hour of that overrun is not billed. If it comes from the store being different from the brief, we stop and requote.
The first hour of any ticket is billed whole. After that, time is drawn down in fifteen minute increments. A twenty minute job costs one hour, and we will tell you that before you buy.
Some jobs cannot be estimated from the outside. "Checkout converts badly on mobile" is a symptom, not a ticket. "Orders sometimes do not reach the warehouse" could be six different things. For those we sell one investigation hour, hand you a written finding, and only then estimate the fix. Occasionally the finding is that the fix is a project, not an hour, and we say so.
A standard hourly block gets a first reply inside two business hours and a scheduled start inside three business days. A rush block starts same or next business day and costs more, because it displaces work somebody else already booked. Hourly buys you a place in a queue, not an on-call rota.
| Lane | First reply | Work starts | Use it when |
|---|---|---|---|
| Standard block | 2 business hours | within 3 business days | The job matters this month, not this afternoon. |
| Rush lane | 1 business hour | same or next business day | A promotion goes live Friday and something on the template is broken. |
| Investigation hour | 2 business hours | within 2 business days | You know something is wrong but cannot yet write the ticket. |
| Store is down | as fast as we can | no guarantee | Read the honest note below this table before you rely on this row. |
We will always try to help a merchant whose store is down. But an hourly block carries no on-call obligation, no out-of-hours rota and no penalty on us if nobody is free at nine on a Saturday night. If a stopped store would genuinely hurt you, buy cover, not hours. Shopify maintenance is what that looks like priced honestly.
Business hours are the overlap window across our New York, London and Delhi desks. Tickets landing outside it are picked up at the start of the next window.
Seven things. A staff account with the right permissions, an unpublished theme copy, a reproducible ticket, your app list, the state of your theme code, a named approver, and a staging store if checkout is involved. Missing any of them and the first hour goes on chasing rather than fixing.
Create a staff account from your Shopify admin with Themes, Apps and whichever order permissions the ticket needs, and revoke it when the block closes. Do not send anyone your own password, including us. Shopify documents how.
All work happens on a copy. If you have not made one, we will, and it takes about five minutes of your block. Publishing back to live is your call and your click, unless you tell us otherwise in writing.
What you see, what you expected, the exact URL, the device, the browser, and one screenshot or screen recording, which our free recorder makes in the browser with nothing uploaded. A ticket written like that routinely halves the estimate, because the first ten minutes of the hour stop being detective work.
Apps that inject script into the theme are the single most common reason an estimate is wrong. Tell us which are installed, which are abandoned, and which one you added the week the problem started.
Is it a stock theme, a stock theme edited in the admin for two years, or a custom build under version control? Each answer changes the estimate substantially. Nobody is judged for the middle answer. Most stores are the middle answer.
Hourly work dies in approval limbo. One person who can say yes, and a rough idea of when they read messages, keeps a five hour block from stretching across three weeks of calendar.
Anything touching checkout, payments, discounts or Shopify Functions gets tested somewhere that is not taking real orders. If you do not have a development store, setting one up is part of the estimate.
If items are missing we say so before billing anything, and you decide whether to spend block hours on us gathering them or go and gather them yourself. Most clients do the second, which is cheaper.
Hourly is the right buy for one bounded job with a testable outcome. It is the wrong buy for anything that needs architecture, continuity or a guaranteed response at three in the morning. The column on the right is longer than most agencies would print, which is precisely why it is here.
If your situation sits between the columns, ask anyway. The reply costs you nothing and it points at a door, even when the door is not ours.
The same senior people do all three. What changes is who carries the risk of the work taking longer than expected, and how much of your future you are committing today. Read the row that matters to you and buy accordingly.
| Hourly block | Retainer or embedded | Fixed scope project | |
|---|---|---|---|
| Commitment | One purchase, nothing after it | Monthly, rolling | One signed scope |
| Who carries overrun risk | You, capped by the stop line | Shared inside the monthly hours | Us |
| Continuity of people | Not guaranteed | Named, and kept | Named for the project |
| Response guarantee | Queue position, business hours | Contractual SLA | Project timeline |
| Best for | One bounded job, a stale backlog, a trial run | A roadmap somebody has to own | A defined build with a deadline |
| Where to go | This page | Hire Shopify experts | Shopify development |
Plenty of merchants run two of these at once: a project for the build, a block for everything that lands while the build is in flight. Nothing stops you moving between them, and there is no penalty for doing so.
Blocks are one-time purchases, not subscriptions. Nothing renews, nothing auto-charges, and unused hours stay valid for twelve months. Rate depends on the seniority the work needs, and we quote it before you buy rather than publishing a number that flatters the easy jobs.
One bounded job, or a short list of small tickets. The smallest thing we sell, and the usual way people start with us.
Room for a real job plus the follow-up round that always appears once somebody sees it working on a preview link.
A stubborn backlog, a performance pass across several templates, or cover while your own developer is out for a month.
Same or next business day start, added to any block. It costs more because somebody else's scheduled work moves to make room.
We do not publish a single hourly figure, because one number cannot be honest across a junior theme tweak and a senior Functions problem. You get a rate and an estimate in the same reply, before any money moves. For market context, senior Shopify work sits in the low hundreds per hour at US and UK boutique agencies in 2026, and meaningfully less offshore.
Some of these cost us work. All five exist because breaking them turns a cheap engagement into an expensive one, usually for you and usually a fortnight later.
Not even for a one line change, not even when you ask nicely. Duplicate, change, preview, publish. The five minutes it costs has saved more trading days than any other habit we have.
Availability is a retainer product and it is priced as one. A block of hours you are holding "just in case" is money doing nothing, and we will tell you to spend it or skip it.
If you return eight months later with a different engineer available, re-reading your store is billable. Hiding that in an estimate would be quieter and less honest.
The cross-device pass is not padding. It is the reason a fix stays fixed, and it is where most of the value of buying a senior hour rather than a cheap one actually lives.
If your ticket is really a project, or really a retainer, or really something Shopify already does natively and nobody told you, we say that in the reply. Turning down two hours to keep a relationship honest is a good trade, and it is the only reason this page has a section listing what hourly is bad at.
Seven direct answers on minimums, estimates, overruns, start times, expiry, rates, and the one question people are too polite to ask, which is whether hourly ever works out cheaper.
Yes. The smallest block is five senior hours, bought once, with no contract and no monthly minimum. You send the ticket, we reply with an hour estimate and a range, and work is scheduled once you approve. When the hours are used the engagement simply ends. There is nothing to cancel and no notice period to serve.
The developer stops at the top of the estimate and messages you with what is done and what remains. Nothing above the estimate is billed without your written approval first. If the overrun came from us misreading a ticket we could have understood, the first hour of it is not billed. If it came from the store being materially different from the brief, we stop and requote rather than absorb it silently.
A standard block gets a first reply within two business hours and a scheduled start within three business days. A rush block starts the same or next business day and is priced above standard, because it moves work somebody else has already booked. Hourly buys a position in a queue rather than an on-call rota, and the queue is honest about that.
Unused hours stay valid for twelve months from purchase. There is no monthly use-it-or-lose-it rule, because a block is a one-time purchase rather than a subscription. One honest caveat: if you return many months later, the engineer who knows your store may be booked, and bringing a new one up to speed draws on the block like any other work.
A staff account with the permissions the ticket needs, an unpublished copy of your theme, a ticket someone else could reproduce, your app list, an honest description of how the theme code has been maintained, one named approver, and a development store if checkout is involved. Create a staff account rather than sharing your own login. If something is missing we tell you before billing anything.
Usually only for small, well-defined work. Hourly has the lowest entry cost and the highest per-hour rate, and you carry the risk of the job running long. A fixed-price project moves that risk to us, which is worth paying for on anything with dependencies. A retainer buys continuity, so nobody re-learns your store every time. Past roughly twenty hours a month, a retainer is normally the cheaper answer.
Not guaranteed, and that is the real trade you are making. We try to keep the same person on a store while a block is running, and the written change notes exist so a second engineer can pick up without charging you to rediscover everything. If a named engineer who stays with you matters more than avoiding commitment, a retainer is the correct purchase rather than this one.
Three things moved the economics of buying Shopify help by the hour. Theme code got easier to work with and harder to guess about, the storefront performance bar became a published number rather than an opinion, and assistant-written code raised the floor on speed while raising the value of the review step.
Online Store 2.0 sections and app blocks mean a competent hour now changes settings and schema rather than hardcoded markup, which is why a rebuilt section often pays for itself: your team edits it afterwards without buying another hour. The Shopify theme sections documentation is the reference an hourly developer should be working from, and asking which sections a change touches is a fair question to put to anyone quoting you.
The performance side stopped being arguable. Core Web Vitals publishes field thresholds at the 75th percentile, so a speed hour has a pass mark instead of a vibe. Google's page experience guidance is explicit that these are field measurements, which matters when somebody sells you an hour against a lab score alone.
Assistant-written Liquid made the first draft of a change faster almost everywhere. What it did not make faster is knowing which of your four apps is injecting the script that breaks the change on iOS. That judgement is most of what a senior hour is actually for in 2026, and it is the part worth paying a higher rate to get right the first time.
What this means for your purchase: ask for an estimate with a range, ask which files and sections the change touches, and ask what the QA step covers. A supplier who cannot answer those three is selling you typing rather than engineering, and typing is cheap everywhere.
Related work: for continuity see hire Shopify experts, for a defined build see Shopify development, for speed work see Shopify speed optimization, and for cover on a trading store see Shopify maintenance.
Four free browser tools we reach for during a triage hour. Running them first sometimes turns a five hour block into a two hour one, which is the point.
Describe the job in a paragraph. A senior Shopify engineer reads it, sends back an hour range and a start date, and tells you plainly if hourly is the wrong way to buy it.
115 people across five studios in New York, Delhi, London, Sydney and Lucknow, shipping ecommerce, web, software and mobile work for founder-led brands. Senior engineers only, no account-manager relay, and the same team from kickoff to launch.
Published .
Pinch, scroll or double-tap to zoom · drag to pan
Where should we send the proposal?
Please enter your name and a valid email.
Any faster way to reach you? Optional.
Please fill in the one you picked.