01 / the front door
Shopify holds the order
Shopify Plus is the system of record for the order: customer, line items, payment, address. It is where the sale happens.
The real problem
The storefront takes the order. The shipping platform ships it. The work is the space between.
Orders that never imported. Tracking that never wrote back. Duplicate fulfillments. Oversells from one-way, ten-minute stock. The gap between the storefront and the shipping platform is where fulfillment breaks.
02 / the back room
ShipStation owns shipping
Once an order lands in ShipStation it owns rating, labels, carrier and tracking. It becomes the shipping system of record.
03 / the gap
The middle is where it breaks
Orders that never imported. Tracking that never wrote back. Duplicate fulfillments. Oversells from one-way, ten-minute stock.
Our position
We built a product around that exact gap. ShipStation plugs into it as a first-class, path-mapped adapter.
Architecture
Orders flow one way out. Fulfillment and tracking flow back.
Orders are pushed from Shopify into ShipStation, where labels print and shipments are created. Fulfillment status and tracking are written back into Shopify. The middleware sits in the middle, makes both writes idempotent, and reconciles what neither side guarantees to deliver.
Order system of record
Shopify Plus
where the sale is placed
The platform
Makro Middleware.
map · reconcile · audit
Shipping system of record
ShipStation
rate · label · track
Orders: Shopify → ShipStation, pushed and upserted on orderKey
Fulfillment + tracking: ShipStation → Shopify, written once
POST /orders/createorderAn upsert keyed on
orderKey, full-resource only. We set orderKey to the Shopify id for idempotent retries, always set advancedOptions.storeId, and read-merge-write so we never clobber a field. Open-status only.Shopify → SSGET /orders · delta pollThere is no order-update webhook, so mutations are caught by a timed poll. A
modifyDateStart / modifyDateEnd window with a page loop is the canonical delta sync. Datetimes are PST/PDT, not UTC.SS → MKSHIP_NOTIFY webhookThe shipment event is a thin pointer, not the data. We make an authenticated GET to its
resource_url for the batch, then write back into Shopify with fulfillmentCreate + fulfillmentTrackingInfoUpdate at FulfillmentOrder granularity.SS → ShopifyAPI key · vault-storedV1 HTTP Basic, V2
API-Key header, both static and full-access. The credential lives server-side in a vault, never in client code, behind the least-privilege boundary the middleware owns. TLS 1.1+ throughout.handshakeGET /fulfillments · reconcileA daily sweep confirms or repairs every writeback. We watch
marketplaceNotified and notifyErrorMessage to prove the tracking reached Shopify, and replay any miss against the idempotent targets.SS ↔ ShopifyThe console
This is not a connector. It is something you operate.
Every order import, every writeback, every failed sync is visible. This is the same Makro Middleware console your fulfillment team would watch in production. Move through the views.
console.makro.agency / northfield-outfitters / sync
live
Sync Monitor
Sync Monitor
Dead Letter Queue
Observability
Entity Key Map
Schedules
Order Relations
Records / 24h ▲
48,210
across 9 entities
Queue depth
3 pending
2 retrying · 1 review
Avg latency
1.2s
event → Shopify
Last reconcile
04:00
0 drift detected
Activitylive · last 60s
Throughputrecords / hr
In queue
3
of 48,210 processed
Auto-retrying
2
transient · rate-limit
Needs review
1
permanent
Resolved / 24h
41
38 auto · 3 manual
Dead Letter Queuenothing is dropped in silence
| Time | Entity | Error class | Attempts | Next | Action |
|---|---|---|---|---|---|
| 08:13:04 | writeback · order #1042 | PERMANENT · validation | 3 / 3 | held | Inspect |
| 07:55:22 | createorder · #1038 | TRANSIENT · timeout | 2 / 5 | 09:50 | Retry now |
| 06:40:11 | delta poll · GET /orders | RATE_LIMIT · 429 | 1 / 5 | paced | Inspect |
Sync volume7-day · records
Circuit breakersper endpoint
ShipStation · V1 orderslast trip · never
closedShopify · Admin APIlast trip · 3d ago
closedShipStation · V2 rateslast trip · never
closedUptime · 90 dayserror rate 0.03%
order · #1042entity_key_map
shopify gidgid://shopify/Order/57…
orderKey57-1042-a91f
ss orderId418820037
storeId228390 · Northfield
webhook idX-Shopify · de-duped
→ decision: UPDATE · open status, read-merge-write
Every order carries three identities at once: the Shopify gid, the ShipStation orderKey we stamp for idempotent upserts, and the ShipStation orderId that results.
Set orderKey to the Shopify id and a replayed webhook writes the order once, never twice. The map also pins advancedOptions.storeId so an order can never land in the default manual store.
This is what stops duplicate fulfillments and double-imported orders before they reach your shipping queue.
Active schedules
7
all workflows enabled
Runs today
96
0 failures
Next run
09:46
order delta poll
Rate budget
40/min
V1 token bucket
Workflowstenant · northfield
Order delta pollGET /orders · modifyDateevery 5 min✓ 09:41 · 14 ordersnext 09:46Run now
Order pushcreateorder · upserton Shopify event✓ 09:42 · 6 ordersevent-drivenRun now
Tracking writebackSHIP_NOTIFY → Shopifyon shipment✓ 09:40 · 9 fulfillmentsevent-drivenRun now
Inventory pullGET /v2/inventoryevery 10 min✓ 09:38 · 3 SKUsnext 09:48Run now
Carrier & service cachelistservices · listpackageshourly✓ 09:00 · 4 carriersnext 10:00Run now
Fulfillment sweepGET /fulfillmentsevery 15 min✓ 09:35 · marketplaceNotified ✓next 09:50Run now
Daily reconciliationboth systems vs key mapdaily · 04:00✓ 04:00 · 0 driftnext 04:00Run now
Shopify order#1042
gidgid://shopify/Order/57…
customerDana Reyes
line 1SKU-TRAIL-22 × 2
line 2SKU-PACK-09 × 1
fulfillmentshipped · tracking ✓
#1042↔orderKey 57-1042✓
orderKey 57-1042↔orderId 418820037✓
SKU-TRAIL-22 × 2↔TRAIL-22 · qty 2✓
SHIP_NOTIFY↔fulfillmentCreate✓
1Z…48A9↔tracking → Shopify✓
entity key map · order stitched Shopify → ShipStation → fulfillment
ShipStation shipmentorderId 418820037
orderKey57-1042-a91f
storeId228390
carrierups · ground
tracking1Z…48A9
marketplaceNotifiedtrue
Order journey#1042 → fulfillment · 5s end to end
09:42:04order webhook→
09:42:04HMAC ✓ · dedup ✓→
09:42:05createorder upsert→
09:42:06label · SHIP_NOTIFY→
09:42:08fulfillmentCreate→
09:42:09tracking → Shopify
drag, scroll, or use the tabs
Inside the platform
The reliability layer ShipStation's connector does not have.
The native path is a black box: no surface to observe, no alert, no replay, on an at-least-once substrate. These are the ten subsystems the middleware brings to ShipStation's exact, documented gaps.
01 / 10
When a write fails
Integrations are judged by how they fail. Follow one failed writeback.
It is classified before it is retried, and nothing disappears into a log file. Colour carries the verdict: amber arrives and is sorted, teal retries, red is held, green replays.
01
It arrives
A notifyErrorMessage comes back on a tracking writeback, or a 429 hits on the 40/min V1 ceiling. Instead of disappearing into a log, it enters the pipeline.
→ 02
It gets classified
Every failure is sorted before anything is retried, so a bad record never loops forever and a real outage never gets buried.
classified→ 03
Transient retries
A 429 enters the RATE_LIMIT lane and paces against X-Rate-Limit-Reset. Timeouts retry with backoff, automatically, until they clear.
→ 04
Permanent is held
A validation failure routes straight to the dead-letter queue for review. It is never retried blindly or lost.
held for review→ 05
You replay it
Fix the cause, replay from the queue against the idempotent targets. A daily reconciliation pass catches anything the live path missed.
replayed · reconciledWhen the native ShipStation connector stops being enough
Where off-the-shelf connectors break, and what the docs actually say.
The native connector is fast, free, and genuinely the right answer for a single store with vanilla order-in, label-out, tracking-back. These are the failure modes no vendor page admits, every reality traced to a primary ShipStation, ShipEngine or shopify.dev source. A custom middleware layer is built to handle all of them, explicitly.
Orders not syncing, missing orders, dropped custom fields
01
The claim"The native ShipStation Shopify connector does it all. Install it and you're integrated."
The realityThe native connector does the basics, then stops. It cannot customize data mapping, build multi-step fulfillment workflows, or sync objects beyond orders and basic customer info. Custom Shopify fields only reach ShipStation if mapped into bounded ShipStation custom fields. It is genuinely fine for a single simple store, and a black box with no surface to observe, alert on, or replay a failed sync.
02
The claim"Orders sync from Shopify to ShipStation in real time."
The realityThe native store connection is poll-based, not push. Import runs on an algorithm-driven refresh with an effective ~2-hour auto-refresh floor, and a configurable minimum-order-age delay up to 2 hours can hold imports. For deterministic real-time, middleware pushes via
POST /orders/createorder or drives POST /stores/refreshstore on its own cadence.03
The claim"Tracking writes back to Shopify automatically once you ship."
The realityThe writeback switch is
notifySalesChannel, and it defaults to false. Mark an order shipped via API without explicitly setting it true and Shopify never learns the order shipped, the classic "tracking not appearing in Shopify." ShipStation also does not ingest Shopify-side fulfillment changes after import, so fulfilling the same order in Shopify creates drift it will not auto-correct.04
The claim"The API gives you a single tracking webhook with the order data in it."
The realityShipStation webhooks are thin pointers, not data. The body is just
resource_url (200-char) plus resource_type; you make an authenticated GET to fetch the records, and that callback is batch-scoped, so one notify fans out to N orders. Every callback costs against the 40/min budget.05
The claim"There is an order-updated event you can subscribe to."
The realityThere is no order-update webhook. Events fire on creation and shipment only. Any change to an existing order, an address fix, an item edit, a hold, is invisible to an event-only design. You must poll
GET /orders?modifyDateStart=… on a timer, and ShipStation datetimes are PST/PDT, not UTC, a classic delta-window off-by-timezone bug.06
The claim"You can patch a field on a ShipStation order through the API."
The realityShipStation order writes are full-resource upserts, not patches.
POST /orders/createorder requires the entire resource in the body and is keyed on orderKey. Only open-status orders (awaiting_payment, awaiting_shipment, on_hold) can be updated; shipped and cancelled are terminal. Middleware must read-merge-write to avoid clobbering fields.07
The claim"ShipStation tracks your stock. Just read inventory from the API."
The realityThe V1 product object has no quantity-on-hand field of any kind. V1 "warehouses" are ship-from addresses, not stock. Real numbers exist only in V2 (
on_hand / allocated / available), and only with the separate Inventory API add-on enabled. Building inventory middleware against V1 is a dead end.08
The claim"Turn on ShipStation and your Shopify stock stays in sync."
The realityShipStation's internal inventory does not sync to Shopify on its own. The bridge is the separate Inventory Sync: one-directional (Sources → Targets), pushing
On Hand − Committed every ~10 minutes, exact-SKU match only (non-matches silently skipped). And there is no inventory webhook in either generation, you poll or infer.09
The claim"Multi-warehouse order routing is built in."
The realityNative multi-warehouse "routing" is a blunt "Do Not Import" automation rule that filters orders by location, a workaround, not routing logic. Real B2B and warehouse routing needs a custom integration. Map Shopify Locations to V2 inventory warehouses, never to a V1
warehouseId, which is an unrelated id namespace.10
The claim"One Shopify order equals one ShipStation order, so reconciliation is simple."
The realityFor multi-location Plus, ShipStation mirrors Shopify's Fulfillment Orders API: one Shopify order with two fulfillments imports as two ShipStation shipments. The unit of work is the fulfillment order, not the Shopify order, so reconciliation must join on fulfillment.
11
The claim"Multi-store is easy. Just connect each store."
The realityConnecting multiple Shopify stores is a known failure point: connections can appear to process yet never show as connected, and the documented fix is logging out of all active Shopify sessions before reconnecting. Import failures surface as 400 or 500 errors. For multi-store and expansion-store brands, a consolidated custom-mapped integration is more reliable than stacking native connectors.
12
The claim"The webhook is signed, so you can trust whatever ShipStation sends."
The realityLegacy V1 subscribe docs describe no built-in signature. ShipStation has since added RSA-SHA256 signatures via ShipEngine, verified with three
x-shipengine-* headers, a JWKS endpoint, and a 5-minute replay window, but you must confirm which path the account is on and verify every inbound webhook. There is no documented at-least-once or retry guarantee for V1 webhooks; treat them as best-effort and back with a reconciliation sweep.13
The claim"ShipStation rate limits are generous."
The realityV1 is 40 requests per minute per key-and-secret pair, low, and shared across webhook callbacks, reconciliation reads, and writes. A breach returns HTTP 429; you stop and wait
X-Rate-Limit-Reset seconds. V2 is 200/min and steers bulk work to batch endpoints. High volume plus batch-webhook fan-out plus a 40/min ceiling is a throttling problem you engineer around with a rate-aware token bucket.14
The claim"One API key is fine, and it's scoped."
The realityA ShipStation API key is static, long-lived, and grants full account access, no token expiry, no refresh, and no documented scoped or read-only keys. Compromise equals full account takeover until manually revoked. The credential must live in a vault, never in client code or version control, with rotation and immediate revocation built in from day one, exactly the server-side boundary ShipStation's own docs prescribe.
15
The claim"Webhooks are enough. If it fired, it arrived."
The realityBoth ends are at-least-once and best-effort. ShipStation gives no V1 retry guarantee; Shopify does not guarantee webhook ordering or delivery, retries up to eight times in a four-hour period, and silently removes a subscription after repeated failures. The documented-correct architecture on both sides is a reconciliation job plus idempotency keys (
orderKey, X-Shopify-Webhook-Id), which is exactly where the middleware lives.What we build
Custom ShipStation middleware, scoped to your fulfillment.
One platform, your exact order flow. The four build modules below cover the Shopify and ShipStation API surface, the routing, and the volume the native connector cannot model.
Module 01
Shopify + ShipStation API integration
Custom-field and metafield mapping across the order, fulfillment and webhook surface, both API generations.
- orderscreateorder upsert on orderKey
- writebackfulfillmentCreate + tracking
- fieldsyour custom data, mapped not lost
Right for brands that need custom fields and labels to carry the data the native mapping drops.
Module 02
ERP / WMS / 3PL order routing
ShipStation routes to and from your ERP and WMS. We own the routing logic the native "Do Not Import" rule cannot express.
- routingreal rules, not import filters
- erp/wmsorder and status sync both ways
- edgeOMS-edge handoffs, idempotent
Right for routed fulfillment that has to reconcile with an ERP or WMS, not just print a label.
Module 03
Multi-store & multi-warehouse
A consolidated, custom-mapped integration across stores and expansion stores, with Shopify Locations mapped to V2 inventory warehouses.
- storesone integration, not stacked connectors
- warehousesLocation → V2 inventory warehouse
- fulfillmentreconciled on fulfillment order
Right for multi-store and expansion-store brands tired of stacking native connectors.
Module 04 at volume
High-volume batching, multi-box, split
A rate-aware token bucket against the 40/min ceiling, V2 batch and multi-package rates, and split or partial shipments handled cleanly.
- throttletoken bucket · 429 backoff lane
- ratesV2 cross-carrier + batch labels
- shipmentsmulti-box, return, partial splits
Right for Plus brands whose fulfillment has outgrown the native connector: high volume, multiple stores, multi-warehouse, B2B and wholesale routing, custom field or label data, or ERP and WMS-adjacent flows.
The decision guide
The three ways to connect ShipStation and Shopify, and when each is right.
There are three ways to connect ShipStation to Shopify: the native connector built into ShipStation, a third-party iPaaS layer for advanced data mapping, and a custom integration on the Shopify and ShipStation APIs for fully tailored workflows. The right choice depends on store count, routing complexity, and order volume.
Option 01
Native ShipStation connector
The connector built into ShipStation. The fastest path, sets up in minutes, limited to orders and basic customer data.
- scopeorders, customer, address, lines
- syncpoll-based, ~2h refresh floor
- mappingno custom data, no workflows
- recoverynone, a black box on failure
Right for a single store with vanilla order-in, label-out, tracking-back and no B2B or routing needs. If that is you, this is the right answer.
Option 02
Third-party iPaaS (e.g. Skyvia)
A subscription middleware layer on a shared platform for advanced data mapping across templated connectors.
- mappingconfigurable, template-bound
- tenancyshared platform, row filtering
- pricingannual fee, grows with volume
- routingERP/WMS often an afterthought
Right for standard multi-system data mapping where the routing logic fits a template and rented infrastructure is acceptable.
Option 03 our build
Custom middleware
Built on the Shopify and ShipStation APIs around your exact workflows, owned by you, operated with a support agreement. Where Plus and B2B brands end up.
- mappingyour fields, your routing rules
- tenancysingle-tenant, isolated per client
- recovery7 failure classes, DLQ, replay
- scopemulti-store, multi-warehouse native
Right for multiple stores, B2B and wholesale routing, multi-warehouse fulfillment, custom data mapping, ERP and WMS sync, or a Plus environment where tracking writeback and automation must be reliable at volume.
How we deliver
Timeline by scope, not a contact-us wall.
A ShipStation × Shopify Plus build lands in one of three bands depending on store count, routing complexity, and how many of the break points above are in play. Discovery first, then build, then a parallel-run to go-live.
Band 01 · foundation
4–6
weeks · single store · standard fulfillment
- Order push via createorder, idempotent on orderKey
- Tracking writeback with notifySalesChannel handled explicitly
- Delta poll for order updates, PST/PDT-correct windows
- Dead-letter queue, daily reconciliation, the console
Band 02 · multi-store / B2B
8–10
weeks · multiple stores · custom fields
- Everything in foundation, across consolidated stores
- Custom-field and metafield mapping, mapped not dropped
- B2B and wholesale order routing rules
- Shopify Locations mapped to V2 inventory warehouses
Band 03 · ERP / WMS / 3PL
12–16
weeks · routed fulfillment · high volume
- Everything in multi-store, plus ERP and WMS order routing
- Rate-aware token bucket against the 40/min ceiling
- V2 batch, multi-package and return-label flows
- Inventory bridge with one declared authoritative side
Cost · scoped per build
We price a ShipStation integration as an engineering engagement: a build with a support agreement, not a per-record meter or a platform seat that renews forever. For market context, enterprise iPaaS commonly runs $30,000 to $100,000+ a year before the work begins. Your exact figure is scoped to the band and the break points in play, and we put it in writing before anything starts.
Security posture
Built to pass your review, and your fulfillment team's questions.
Credentials never in plain config
The ShipStation key is static, long-lived and full-access, so it is held as an encrypted field, isolated per tenant, rotatable without downtime, and never in client code or version control.
Inbound traffic is verified
Shopify webhooks are HMAC-verified and ShipStation webhooks RSA-SHA256-verified via ShipEngine, three x-shipengine headers, a JWKS endpoint and a 5-minute replay window, then deduplicated so a replay cannot create a second order.
The middleware owns least-privilege
ShipStation has no scoped or read-only keys, so the boundary is ours. V1 Basic and V2 API-Key are vault-stored, and the middleware exposes only the operations the integration needs, never the raw full-access key.
Everything is on the record
An append-only audit trail logs every operation, source-tagged, so you can prove what happened to any order, label or tracking writeback.
Frequently asked questions
Where ShipStation integrations get hard, and where we land.
The details that separate a team that read the docs from a team that shipped against them. Open any one.
01How do I integrate ShipStation with Shopify?+
There are three methods: the native ShipStation connector (built into ShipStation, set up in minutes), a third-party iPaaS tool like Skyvia for advanced data mapping, or a custom integration on the Shopify and ShipStation APIs. The native connector syncs orders, customer details, shipping addresses, and line items automatically every few minutes. For multi-store, B2B, or ERP-connected operations, a custom integration is usually required.
02What does the native ShipStation Shopify connector sync, and what doesn't it?+
It syncs orders, customer details, shipping addresses, line items, and basic order metadata, with new orders importing automatically every few minutes. It does not support custom field mapping, multi-step fulfillment workflows, multi-store consolidation, or ERP/WMS sync. Merchants typically outgrow the native connector as order complexity and channel count grow.
03Can I connect ShipStation to multiple Shopify stores?+
Yes, but multi-store connections are a known pain point. Connections can appear to process yet never show as connected, and the documented fix is logging out of all active Shopify sessions before reconnecting. For brands running multiple Shopify stores or Shopify Plus expansion stores, a consolidated, custom-mapped integration is more reliable than stacking native connectors.
04How do I set up ShipStation for Shopify Plus, multi-warehouse, or B2B fulfillment?+
ShipStation supports multi-location and multi-warehouse fulfillment, but native routing relies on blunt "Do Not Import" rules rather than true order-routing logic. Real B2B/wholesale routing, warehouse assignment, and ERP/WMS sync require a custom integration on ShipStation's order, shipping, and webhook APIs, with Shopify Locations mapped to ShipStation's V2 inventory warehouses.
05Why won't my Shopify store connect to ShipStation, or why aren't orders importing?+
The most common causes are insufficient ShipStation permissions, a store in test/maintenance mode blocking third-party connections, or stale Shopify sessions. Import failures often surface as 400 or 500 errors. A clean reconnect, correct permissions, live store mode, logged-out sessions, resolves most cases; persistent failures usually indicate a deeper config or API issue worth an expert review.
06Do I need an agency to integrate ShipStation with Shopify?+
For a single store with simple needs, the native connector is enough and self-serve. You need an integration partner when you have multiple stores, B2B/wholesale routing, multi-warehouse fulfillment, custom data mapping, ERP/WMS sync, or a Shopify Plus environment where tracking writeback and automation must be reliable at volume.
07Why does tracking not appear in Shopify after I ship?+
The writeback switch is
notifySalesChannel, and it defaults to false. Mark an order shipped via the API without explicitly setting it true and Shopify never learns the order shipped. We own the write instead: consume SHIP_NOTIFY and write into Shopify with fulfillmentCreate and fulfillmentTrackingInfoUpdate at FulfillmentOrder granularity, then watch marketplaceNotified and notifyErrorMessage to confirm or repair the writeback.08There are two ShipStation APIs. Which one does a Shopify integration use?+
Two APIs, not interchangeable. V1 (
ssapi.shipstation.com, HTTP Basic) carries the order, store, fulfillment and webhook model. V2 (api.shipstation.com/v2, API-Key header) is shipping-first: rates, labels, tracking, batch, plus the inventory add-on. A Shopify Plus fulfillment integration is mostly a V1 job, with V2 brought in for cross-carrier rates, batch labels and real stock.09Are we locked into a black box?+
No. On the ShipStation side we use the documented public APIs only: V1 orders and webhooks, V2 rates, labels and inventory. The middleware is our platform, but your data, your field mappings, your routing rules and the full append-only audit trail are yours, documented and exportable. Your team can inspect how every order, label and tracking writeback moved. The thing we sell is the opposite of lock-in.
10Will rollout touch our production store?+
Not until you decide it does. We build and prove the flow in a controlled environment, parallel-run against real orders with daily reconciliation, and only flip the live writeback when the reconciliation report says zero drift and you sign off. Idempotency on both writes, the
orderKey upsert and Shopify webhook-id dedup, means a replay during cutover writes once, never twice. The audit trail covers every record from day one.The framework underneath
A platform in production. ShipStation is a path-mapped adapter.
Every system sits behind the same contract: authenticate, fetch master data, push orders, validate, report. The platform runs in production today against a live enterprise ERP. ShipStation is a registered target on that same framework, its path fully mapped: a V1-first order, store and fulfillment surface with V2 for rating, labels and inventory.
We say this plainly: the credibility is a proven platform and a precisely understood ShipStation path, not years of ShipStation traffic. That distinction is exactly what your fulfillment lead can verify, which is why we lead with it.
adapter contractbase.ts
01authenticate()V1 Basic / V2 API-Key
02fetchMasterData()orders · carriers
03pushOrder()createorder upsert
04validate()schema check
05report()audit + status
NS
NetSuite
ERP adapter
SS
ShipStation
fulfillment adapter
The engineering standard
Claims you can check.
There is no ShipStation case study to borrow, and we will not invent one. What we lead with is the platform's checkable standard, the same platform that runs NetSuite in production, that the ShipStation adapter is built to.
1,756
Automated tests across 139 suites, run on every change. Counted in the repository, not rounded for the slide. No code reaches your production data without passing them.
85%
Coverage gate enforced before any deploy.
39
End-to-end browser tests, Chromium, Firefox, WebKit.
7
Failure classes, each with its own pre-decided policy.
0
Credentials stored in plaintext, anywhere, ever.
Bring your fulfillment lead and your connector's failure list. We will walk the platform, not a deck.
A real conversation about your stores, your routing, your order volume, and the failure modes you have already hit.