The parts of a store that need real code.
A theme covers most of a shop. The rest — a configurator, a variant rule the picker was never designed for, an order that has to reach a warehouse and come back — is where the work is. You buy your own Shopify plan and your own apps, direct. We are in none of Shopify’s partner or expert programmes, we take nothing from what you pay them, and we are paid by you.
This is also the one platform where we ship a product rather than only projects: our order-support app is listed on the Shopify App Store and you can read it before you speak to us. Every price we charge sits on one page.
Three places the work lands.
-
In the theme
Liquid work for product configurators, variant pickers and upsell modules, and custom blocks or sections in an Online Store 2.0 theme so the merchandising team can move them without calling anybody. Where the storefront needs data the theme cannot reach, the Storefront API does the reaching.
-
Between the store and everything after it
Orders routed onward to Klaviyo for abandoned-cart, post-purchase and win-back flows, to Printful with the variant mapping done properly, or to a 3PL — ShipBob, ShipHero, or a warehouse with an API of its own. The interesting part is never the happy path; it is what happens on the retry.
-
As an app, when the job outlives the project
Some work stops being a build and becomes a product. Ours is listed on the App Store: it answers order tracking, returns and refunds around the clock, and the merchant approves before anything is actioned. It is open to read before you speak to us, which is the standard we hold the rest of this site to.
The failure worth designing against.
A webhook is retried after a timeout, and the order ships twice. Shopify sends the order, your endpoint takes too long or answers badly, Shopify sends it again because that is exactly what a careful platform should do, and the second copy goes down the same pipe to the warehouse. Two parcels, one payment, and a customer who now knows more about your systems than you would like.
The fix is not a faster endpoint. It is a record of what has already been accepted, so the second delivery of the same order is recognised and dropped rather than processed. We build that in from the first order rather than after the first duplicate, and it is the first thing we ask about when someone else built the integration.
Three published limits that decide the build.
Each of these is in Shopify’s own documentation and each one changes what gets built rather than how long it takes.
-
The plan decides how fast anything can talk to the store
The GraphQL Admin API is metered in points a second: 100 on a standard plan, 200 on Advanced and 1,000 on Plus, and no single query may cost more than 1,000 points whatever the plan. A tenfold gap between standard and Plus is not a detail to discover during a catalogue sync — it decides whether a job is batched overnight or runs while somebody watches.
-
A retired API version keeps answering, which is the awkward part
Shopify ships a new version every three months and supports each stable one for at least twelve, with nine months of overlap. When a version does retire, calls are forwarded to the oldest supported version rather than refused — so an integration nobody has touched does not break loudly. It quietly starts running against different behaviour.
-
Functions reach every plan through a public app
Only a store on Plus may use a custom app containing Function APIs. Any plan may use a public app from the App Store that contains them. So the plan does not decide what is possible — it decides how it has to be built and packaged, which is a design decision taken at the start rather than a wall found at the end.
What the work costs.
The platform changes how a job is built, not what it is worth, so these are the same figures as everywhere else on this site.
-
The store joined to one other system
One connection in one direction at $3,250 — a 3PL, a print partner, an email platform. Two systems kept in step both ways at $11,500. The integration work.
-
A job that starts itself
One job at $2,550, or the whole run around it at $3,950 — the nightly reconcile, the stock sync, the report nobody should be building by hand. Work that runs on its own.
-
Customer and order records that stopped agreeing
A read-only report on what is in there at $390, the cleanup at $2,950, and a move with the count proved on both sides at $4,900. The data work.
When it is running, somebody has to be watching it.
A build is finished the day it goes live. Keeping it alive is a different job, and on a platform that ships a new API version every quarter and forwards the retired ones rather than failing them, it is not an optional one.
Watch
$549 per month
“It runs. I do not want to be the one who notices when it stops.”
- We are told the moment a run fails, and we tell you
- A written note every month of what ran, what failed and what we did
- Broken things fixed by the next working day
- Your accounts stay yours — we hold access, not ownership
Guard
$849 per month
“I need to know about the runs that finish and quietly do nothing.”
- Everything in Watch, plus:
- We check the runs that finish but do nothing, where there is something to count
- Broken things fixed the same working day
- Changes are unlimited — they join a queue and we work through it in order
Managed
$1,200 per month
“I do not want to run it at all. I want somebody whose job it is.”
- Everything in Guard, plus:
- We operate it, not you
- A named person, and the name of their backup
- Reachable outside business hours when something is genuinely down
- Your changes are worked ahead of everyone else’s
Monthly, in advance. Thirty days’ notice either way, from either side. Offered after a build, never before — we will not sell you a plan to watch something we have not seen.
Tell us what you want the store to do.
Your plan, the apps already installed, and the thing the theme will not stretch to. We will tell you whether it is a theme change, an integration, or an app already on the store that does it. We reply within one business day.