ERP and inventory
Two-way sync between Shopify and the system that actually owns your stock — so the storefront stops selling things you don’t have.
When no app on the store does what you need — or the one that does costs more per month than building it once. Admin API, Storefront API, webhooks, and middleware that doesn’t fall over quietly.
Buy the app when one exists, does roughly what you need, and is actively maintained. That’s most of the time, and we’ll say so.
Build it when the app doesn’t exist, when the closest option needs so much configuration that it’s fragile, when the subscription cost over two years exceeds the build cost, or when the data flow is specific enough to your business that no generic tool models it correctly.
The case against building: custom integrations need maintenance. Shopify deprecates API versions on a schedule, and a connection nobody owns will eventually break at the worst possible moment. If you don’t have a plan for who maintains it, buy the app.
Two-way sync between Shopify and the system that actually owns your stock — so the storefront stops selling things you don’t have.
Orders out, tracking back in, fulfilment status reflected accurately in Shopify and in the customer’s account.
Customer and order data flowing into the system your marketing team works in, with the fields they actually segment on.
B2B price lists, tiered pricing, and purchase logic that Shopify’s native settings don’t cover.
Storefront API work where the front end lives outside Shopify but checkout stays inside it.
Admin API scripts and small internal apps for bulk operations your team currently does by hand.
What moves, in which direction, how often, and what happens when the two systems disagree. Most integration failures are unresolved conflict rules, not code.
Shopify’s API rate limits and the other system’s constraints, before design rather than after. This is what breaks integrations at scale.
What happens when the other system is down, returns a partial response, or sends the same webhook twice. Retries, idempotency, and alerting when something silently stops.
Against a current stable API version, with the deprecation date written into the handover.
Including the edge cases — refunds, partial fulfilments, cancelled orders, duplicate webhooks.
What it does, where it runs, what breaks it, and when the API version needs upgrading. Written for whoever inherits it, not for us.
Admin API for order, product, inventory and customer data; Storefront API for headless and custom front ends; webhooks for event-driven flows; and Functions where checkout logic needs customising on Plus.
Depends on the job. Some sit inside a private Shopify app, some as middleware on your own infrastructure. We’ll recommend based on who needs to maintain it, not on what’s fastest for us to build.
Shopify releases quarterly API versions and supports each for a defined window. We record the deprecation date at handover so it’s a planned upgrade rather than an outage. If you’d rather not track it, that’s what a maintenance arrangement covers.
Sometimes — via file exchange, database access, or a vendor-provided endpoint. Sometimes not, and we’ll tell you early rather than after you’ve paid for discovery.
A well-built integration runs server-to-server and never touches the customer’s browser. If someone proposes doing it in front-end JavaScript, that’s a red flag.
Yes, with documentation. You’re not renting the integration from us.
Tell us what the two systems are and what needs to move between them. We’ll tell you whether an app already does it — and quote the build if not.