ROAM Adventure Co.
A wholesale portal running alongside direct-to-consumer operations, plus a platform migration — work where the storefront is only one participant in the system.
- Wholesale portal
- Migration
- Development
Solution — ERP
The storefront and ERP need more than a connection.
Almost every ERP integration is sold as plumbing: pick a connector, map some fields, schedule a sync. The projects that go badly are rarely defeated by the API. They're defeated by an unresolved disagreement about which system is allowed to be right.
Products, inventory, orders, fulfillment, customers, refunds and finance each need an owner. Once those decisions exist in writing, the technical work becomes ordinary.
Symptoms
Two systems, two versions of the truth
The tell is usually human: somebody in operations or finance has quietly become the integration, correcting the same handful of records every morning.
Signals
- Inventory counts that disagree by location
- Orders that fail to post and get keyed manually
- Duplicate customers and duplicate sales orders
- Refunds reconciled by spreadsheet
- Product data edited in two places
- Fulfillment status the customer can't rely on
- Month-end close waiting on eCommerce
- Nobody certain who owns the connector
An integration should reflect the operating model — not define it.
Likely causes
Where ERP integrations actually fail
- 01
Ownership was never decided
Both systems can edit the same object. Whichever wrote last wins, which is not a governance model.
- 02
The operating model wasn't mapped
The integration encoded how someone assumed the business works, rather than how it actually fulfills, invoices and returns.
- 03
Timing treated as one setting
Inventory may need near real-time. Item data rarely does. Orders should be event-driven with a retry queue.
- 04
No failure design
Retries, idempotency, partial failures and alerting are deferred, and then discovered in production.
- 05
Edge cases postponed
Bundles, pre-orders, exchanges, gift cards, multi-entity and tax — the flows that generate the disputes.
- 06
Nobody operates it
Integrations degrade from neglect more often than from design. Someone has to own the alerts and the runbook.
What we'd examine
One page per data domain
Before scoping a build we write the ownership map: for every object, which system is the source of truth, which direction data moves, how often, and what happens when the transfer fails.
This page is deliberately broader than any single ERP. Where NetSuite is the system in question, we have a dedicated page for it.
Shopify and NetSuite- ShopifyownsStorefront, orders, customers
- ERPownsCosts, purchasing, financial truth
- Inventory / 3PLownsStock position and fulfillment status
- CRM / emailownsContact record and lifecycle state
- ReportingownsNothing — it reads from everything
When does it move?
What happens on failure?
Who needs to know?
Decisions we work through
- Item and variant master data
- Pricing and price basis
- Inventory and available-to-sell
- Order creation and financial record
- Customer identity and account matching
- Wholesale and B2B entities
- Fulfillment and tracking
- Returns, refunds and credits
- Tax and multi-currency handling
- Sync timing per flow
- Failure, retry and reconciliation
- Monitoring, alerting and ownership
Proof
Systems that had to agree
ConnectFit
A Shopify store built to integrate with a HubSpot marketing site so customers move between the two without the transition feeling obvious — an ownership question before an implementation one.
- Platform architecture
- Advisory
Which system is right?
If the answer takes more than a sentence, that's the project — and it's worth doing before anyone writes code.