Integration in gated steps.
Every step has a concrete output and a decision of yours at the end. Fail a gate and we stop; you keep what was built.
- 01Integration discovery
- 02POC on real data
- 03Production build
- 04Managed operations
What comes with every integration
Sent twice, still one record. When the target is down, events wait and then go through.

Integration discovery
Integration discovery is the step where we read the APIs and real data of both systems before anyone quotes. You grant read-only accounts or sandbox API keys, give us 60 to 90 minutes with someone who knows the business flow, and send a data sample with sensitive fields masked. We return data-flow maps, a draft field mapping, an assessment of webhooks and rate limits on both ends, a proposed deduplication key, a risk list and a POC outline. Discovery is paid, because a proposal written without real data has to guess. The assessment is yours; take it to another vendor if you want.
POC on real data
The POC is the step that proves the approach on real data: one business flow, 20 to 50 transactions, on staging or a test account of the target system. Both sides agree the acceptance criteria before the first line of code. We reconcile every transaction by hand, replay 5 events and count target records, measure P50 and P95 from the logs, block 2 webhooks to see reconciliation detect and backfill them, and deliberately cut the target off to check the backlog drains once it is back. Fail and we stop; you keep the assessment and the POC source code.
Production build
The production build is the step where we build every flow agreed after the POC, with full edge cases: edits, voids, partial returns, merges, splits. Each event carries a deduplication key of the shape source:type:id:version, and the database enforces it with a unique constraint, so a replay of any count still yields one record. Failed writes retry with backoff plus jitter, and when attempts run out they land in a replayable dead-letter queue. Reconciliation compares counts every hour and checks record by record every night. The new flow runs in parallel with the old process before cutover, and the build ends with a runbook and a handover session.
Managed operations
Managed operations is where we take monthly responsibility for the middleware once it is in production, on hecigo's infrastructure or yours. We monitor, take the alerts and handle incidents within committed hours, run reconciliation and send the discrepancy report, and apply security updates and version patches. Each month includes an allowance for small changes such as adding a mapped field. The monthly report lists volume, success rate, P95 measured from the logs, and every incident with how it was handled. New business flows, a third system, or rewrites after a third party ships a breaking API change are scoped separately.
Handover
Handover is the exit, and it is written into the contract from the day you sign, not a verbal promise. You get the custom source code with ownership stated in the contract, the database schema and all mapping data, the deployment config (compose files, environment templates with secret values redacted, build process), and a runbook covering how to run it, how to monitor it and how to fix the common failures. It ends with a handover session for the incoming team. You can trigger handover at any step, or buy it on its own if you want to run the middleware yourself from day one.