Integrations
Systems that already talk to each other
Most of the software we build has to sit inside a stack that already exists: a marketplace, an ERP, an accounting system, a CRM that the business genuinely runs on. Every platform below is one we've integrated in shipped client work, not a logo wall.
Start a ProjectIntegration is where business systems actually break
An integration is rarely hard because the API is complicated. It's hard because two systems disagree about what a customer is, because the documented behaviour and the real behaviour differ, because a sync that works at a hundred records a day quietly falls apart at ten thousand, or because nobody notices it stopped running until the month-end numbers don't reconcile.
That's the work: making two systems agree, keeping them in agreement under load, and knowing immediately when they stop.
Platforms we’ve integrated
Marketplaces
Multi-channel selling where the same physical unit is listed in more than one place and can only be sold once.
Amazon
TrueCellListing and inventory sync across a high-volume resale catalog, with serial-level reconciliation so a unit sold on one channel is pulled from the others before it can be oversold.
eBay
TrueCellTwo-way listing and order sync, driven by a rules engine that decides which units are routed to eBay and which are held back for other channels.
Back Market
TrueCellCondition-graded listings kept in step with the diagnostics and grading pipeline, so what's advertised matches the grade of what's actually in stock.
Inventory & ERP
The system of record for stock and pricing, connected to the commerce layer instead of parallel to it.
Fishbowl
KineinBidirectional sync between a B2B storefront and Fishbowl: multi-warehouse inventory levels, customer-specific pricing and orders moving both ways, with no middleware layer and no re-keying.
Acumatica
KineinStorefront orders, pricing and stock kept in step with Acumatica as the system of record, so the commerce side runs on the ERP rather than maintaining a second version of the truth.
Accounting
Order and invoice data landing in the books as it happens, rather than in a monthly re-entry exercise.
QuickBooks
KineinOrders, invoices and customer records flowing between the storefront and QuickBooks in both directions, removing the manual re-entry step between commerce and the books.
Xero
KineinThe same bidirectional sync against Xero, so a distributor already running their accounts there doesn't have to change systems to get a B2B storefront.
E-commerce
Wholesale order flow connected to the storefronts brands already run.
Shopify
B2B AccessCatalog and order sync between a wholesale marketplace and the Shopify stores its brands already operate, so orders placed by retailers don't have to be re-entered on the brand side.
CRM
Account and order history kept where the sales side already works.
Zoho CRM
B2B AccessRetailer and order records synced into Zoho CRM, keeping verification status, account activity and buyer history in one place instead of split between the marketplace and the sales team's tooling.
This is what we've shipped, not the limit of what we integrate. If a system exposes a documented API — or a database, a file drop, or a webhook we can work against — it's in scope. We'd rather show you the ones we can point at real work for.
How we approach integration work
The same rigor we apply to AI work applies here, and for the same reason: a system that's right most of the time is a system nobody can trust with money.
Map the real data model first
Before any code, we work out where the two systems genuinely disagree: what one calls a customer and the other calls an account, which fields are optional in the docs but mandatory in practice, what the exception cases look like. Almost every integration that fails late fails because this step was skipped.
Assume the other system will fail
Third-party APIs go down, rate-limit without warning, and occasionally return success for something they didn't do. We build for that: retries with backoff, idempotent writes so a replay can't double-charge or double-ship, and queues that hold work rather than dropping it.
Test against the real thing
Mocks confirm our own assumptions back to us. We test against sandbox and real accounts, including the ugly cases — partial data, duplicates, records edited on both sides between syncs — because those are what actually arrive in production.
Reconcile and alert continuously
A sync that silently stops is worse than one that never ran, because by the time it surfaces the data has drifted for weeks. We build reconciliation that compares both sides on a schedule and alerts on divergence, so the failure mode is a notification rather than a discovery at month end.