From board-meeting deadline to live sync in three weeks.

The situation

The client is a mid-market distribution business operating across the US and Canada. They had two systems that mattered for the operations question their board was asking: an ERP — the system of record for orders, invoices, and vendor relationships, ten years old and customized — and a warehouse management system running the physical operations side.

The ERP and the WMS had never talked to each other. Every day, someone on the operations team was exporting a CSV from the ERP, opening it in Excel, running a set of lookups against the WMS's daily export, and hand-reconciling the differences. When the numbers disagreed — which they did most days — the same person walked the floor to figure out which system was right.

The board was about to ask a question the current setup could not answer in real time: what is our unshipped-order backlog as a fraction of the WIP inventory, right now, across all warehouses? The client had three weeks before the board meeting. Two other vendors had already proposed six-month timelines and rip-and-replace projects. Neither answered the board question in three weeks. That is when they called GRTC.

What Discovery found

Discovery ran the standard two weeks. Four findings mattered:

1. The ERP already had an integration surface — the operations team did not know about it. A REST-adjacent API endpoint shipped in a vendor patch release the previous year, documented as "for partner integrations" — which the operations team read as "not for us." It was exactly the surface we needed.
2. The WMS had a webhook feature the client was already licensed for. A configuration setting was toggled off. Turning it on required a support ticket and a business day, not a rebuild.
3. The daily hand-reconciliation had a hidden mapping table. Over three years, the operations person had built a mental map of which SKU codes in the ERP corresponded to which pick-locations in the WMS. This map lived in her head and, in fragmented form, in a personal Excel workbook. Any integration that skipped this mapping table would ship correct data that answered the wrong question.
4. The board question was not the real question. The board asked about backlog-to-WIP as a proxy for cash conversion. The real business question was how much working capital is currently trapped as unshipped goods. The integration had to be structured around answering that.

Discovery output: a fixed-fee Growth Build proposal for six weeks of delivery, staged as three two-week sprints. The client signed on day 12.

What we built

Sprint 1 — Read path (weeks 1–2)

We turned on the WMS webhook and wrote a thin ingestion service in Node.js that received the webhook events and normalized them. We wrote a poller against the ERP REST endpoint on a ten-minute cadence — not real-time, because the ERP's rate limits would not have supported it, but frequent enough for a board-meeting-relevant answer. Both feeds landed in the same PostgreSQL database as append-only event tables.

Sprint 2 — Mapping and reconciliation (weeks 3–4)

We sat with the operations person for three afternoons and extracted her mental map into a proper mapping table — 4,200 rows, one per canonical SKU, with the ERP code, the WMS pick-location code, unit-of-measure conversions, and a known-exception flag. She reviewed and signed off on all 4,200 rows over five business days. We built a small internal admin UI so she can update the table herself when a new SKU comes in — because the alternative was hard-coding the mapping and creating a dependency on us.

Sprint 3 — Reporting layer and board deliverable (weeks 5–6)

We built the specific reporting surface the board question needed: working capital trapped as unshipped goods, broken down by warehouse, product category, and age of the unshipped order. The reporting surface lives inside the client's existing BI tool. We wrote three canonical queries; the client's finance team wrote the other twelve, using ours as templates. Every service has a runbook. Every runbook has a recorded walkthrough.

What happened at the board meeting

The board meeting was in week six of the engagement — three weeks ahead of the client's original deadline. The CFO opened with the working-capital-trapped number, current to within ten minutes. The board asked two follow-up questions the CFO answered from the reporting surface, live. No slides.

The engagement handed back on day 31 with runbooks, recorded walkthroughs, and an on-call rotation the client's IT team owns.

What we did not do

• We did not replace the ERP. The other vendor's twelve-month rip-and-replace was the wrong project for the actual question.
• We did not build a new dashboard product. Metabase was already in the client's stack — a bespoke dashboard would have created a second product to maintain.
• We did not automate the mapping table entirely. The operations person's SKU-exception judgment is not something a script would get right.
• We did not push for real-time sync. Ten-minute polling was enough for the business question.

Numbers we can share

Numbers we cannot share: contract value, specific ERP and WMS vendor names, and the client's identity — all per client NDA. Reference calls with Jordan can be arranged on request after Discovery.

The pattern this case study represents

Most systems-integration engagements that fail do so for the same three reasons: the integration is scoped to the systems rather than the question; the hidden mapping table gets missed; or the vendor treats the integration as its own product — rip-and-replace, bespoke dashboard, middleware platform — anything that adds a third product the client has to maintain. The right shape is usually the smallest pipeline that answers the question, on primitives the client's team already knows how to operate. We pick the boring, recoverable primitive — then we automate it.