Which system holds the truth, what crosses the boundary, what happens when a call fails, and who is responsible for it a year later.
Nearly every integration failure traces back to an unanswered version of this.
Two systems holding a stock number is not an integration problem until they disagree. Then it is the only problem, and it usually surfaces as an oversell on the busiest trading day of the year.
So the first thing a scope names is ownership. For each entity that crosses a boundary, one system holds the truth and the others hold a copy. Stock might be owned by the warehouse system, prices by the ERP, customer records by Shopify, and product content by whichever system the team actually edits. Those are business decisions, not technical ones, and they are made before any code exists.
The second thing it names is direction and timing. One way or two, on a schedule or on an event, and how much delay is tolerable before somebody notices. A ten-minute stock delay is fine for most catalogues and unacceptable for a single-unit resale business.
Each with a different failure mode and a different urgency.
Swipe the systems
Stock
Stock levels, product data, purchase orders and multi-location availability. The most visible integration, because its failures are visible to customers.
Money
Orders, refunds, payouts and fees reaching the finance system in a form that reconciles without manual repair.
Despatch
Orders out, tracking back, and the exceptions that make up most of the real work: splits, holds, cancellations and partial shipments.
Marketing
Customer and order data reaching marketing systems with consent intact and identities that actually match.
A scope that cannot answer these is not a scope.
| Question | What has to be decided | Cost of skipping it |
|---|---|---|
| Ownership | Which system holds the truth for each entity | Two systems disagree and neither is wrong by its own rules |
| Identity | How records are matched across systems, and what happens to duplicates | Silent duplicate customers and orphaned orders |
| Volume | Expected records per day and per peak hour, against published rate limits | The integration works in testing and stalls in November |
| Failure | Retries, backoff, replay and what is safe to run twice | Duplicate orders, or a queue that quietly stops |
| Visibility | Who is alerted, where the log lives and how a failure is noticed | A broken sync found by a customer, days late |
| Ownership after launch | Who maintains it when an API version is deprecated | An unmaintained integration that fails on someone else’s schedule |
Where a middleware platform already covers a flow reliably, using it is usually the better answer. Bespoke code is worth writing when the flow is genuinely specific to the business.
The interesting cases are all failure cases.
An integration that only works when both systems are healthy is a demonstration. These are the conditions it has to hold up under.
Reconciliation is the one most often left out and the one that catches the rest. If nothing compares the two systems periodically, a slow divergence is invisible until it is expensive.
Three stages, and the direction each record actually travels.
Shopify
ShopifyStorefront, orders and customer recordsShopify to Integration service
Orders, customers and product data leave Shopify.
Integration service back to Shopify
Values owned elsewhere — typically stock and price — are written back to Shopify.
Integration service
Integration service to Connected systems
Each boundary is scoped separately, because each one fails differently and at a different urgency.
Connected systems
These are system categories, not named products. Which system owns each entity is a business decision, made before any code exists, and the specific systems are named per project rather than published here.
Published starting figures in GBP and USD, excluding VAT.
Scoped after a technical review
One bounded piece
£1,500$2,000
One bounded improvement: landing pages, a template rebuild, an analytics implementation, or a build-readiness review credited against a larger project.
Fixed price
Plus, B2B, multi-market
From £8,000From $10,500
Shopify Plus, B2B, multi-market, multi-language, custom integrations or headless work. These configurations are sized after discovery, not instant-priced.
Starting price · scoped after discovery
Monitoring and maintenance after launch
Per month
From £1,250From $1,650
A live improvement programme on one site. You set the priorities each month, we work the queue in order, and the month closes with what changed and what it did.
Starting price
Per month
From £3,000From $4,000
Continuous delivery across an agreed portfolio, with planning ahead of the work rather than a queue you have to keep feeding.
Starting price
Integration work is scoped after reviewing the other system’s API, its rate limits and the volumes involved. A published figure before that would be a guess, and integration guesses are expensive in one direction only.
An app or a middleware platform is usually the better first answer, because someone else maintains it against platform changes. Bespoke work earns its place where the flow is specific to how your business operates and no off-the-shelf mapping fits.
Whoever is named in the scope. APIs are versioned and deprecated on the vendor’s schedule, not yours, so an integration without a maintenance owner is a fault waiting for a quiet week. That is agreed before it is built.
Sometimes, through scheduled exports, a database connection or a file drop. It is slower and more fragile than an API, so it is scoped with those limits stated rather than presented as equivalent.
Monitoring and a scheduled reconciliation report. Alerting on failure is not enough on its own, because the most expensive integration faults are the ones that succeed with the wrong data.
That single answer, plus rough daily volumes, is usually enough to say whether this is an app, a middleware flow or a build.
