Building a real connector platform, then shipping it as a demo

Rabbid started as a high-fidelity prototype: every screen rendered from static fixtures over a frozen demo clock. It looked like a product, but it had never reconciled a single real transaction. This note is about closing that gap — building the read-only reconciliation core for real — and then serving the demo from mad.engineering/demos/rabbid with no extra infrastructure.

Two ends, no middle

The connectors authenticated and the reconciliation matcher was solid and tested. What was missing was the middle: nothing actually pulled Procore and NetSuite data, mapped it, matched it, and persisted the result. We built that as a set of small, injectable boundaries — a gateway that pulls extract lines and a store that persists them — so the orchestration is deterministic and testable without a live sandbox.

Correlate, never guess

The load-bearing decision in reconciliation is the correlation key. We pair a Procore document with a NetSuite record only when their identifiers match exactly — the Procore document number against the NetSuite externalId — and we never fuzzy-match. A record with no counterpart surfaces as an exception for a human to resolve rather than being silently paired.

Read-only first. Ingest both systems, surface the drift, prove value — and only then consider writing anything back. Restraint is the feature.

Shipping the demo without a second deploy

The demo is a self-contained static export — fixtures only, no backend, no secrets. Rather than stand up a separate deployment, we serve the bundle from this site itself, mounted under /demos/rabbid. The one subtlety worth remembering: under a standalone build, the public/directory is not reliably present in the serverless function's filesystem, so the bundle is force-included into the route's function via file tracing instead.

The result is the demo you can open right now — the same interactive product, running on simulated data.