Service
Integrations that hold when the other side misbehaves.
The seams between systems are where most projects quietly fail. Not because the protocol is hard, but because the other end goes down, answers twice, changes a field without telling anyone, or returns success for something it did not do.
What this involves
-
Payments, from card rails to Bitcoin
Stripe for cards and subscriptions, BTCPay Server for Bitcoin and Lightning. Both demand the same discipline: webhooks that are processed exactly once, a local record that still matches the provider six months later, and a refund path that was configured per spec rather than improvised.
-
Third-party APIs and undocumented endpoints
Pool APIs, partner platforms, endpoints with a specification that no longer matches the responses. Where documentation is missing, the observed behaviour becomes the specification — written down, so the next person is not starting over.
-
Webhooks in both directions
Receiving events without losing them when your application is restarting, and emitting events without hammering a consumer that has gone away. Signed, queued, replayable.
-
Retry semantics and idempotency
A retry is only safe if the operation can happen twice without doing damage. That property has to be configured into the boundary — it cannot be added afterwards by wrapping a call in a loop.
-
Reconciliation against external ledgers
The remote system is the authority on some numbers, yours on others. Regular comparison, explicit handling of the differences, and an alert when the two stop agreeing — instead of noticing at the end of the quarter.
-
Moving data between systems that were never meant to talk
Field mapping, unit and timezone mismatches, records that exist on one side and not the other. Migration and ongoing synchronisation are different problems, and we treat them as such.
When this is more than you need
If two well-behaved SaaS products need to exchange a handful of records, an off-the-shelf automation tool will do it cheaper than we can. This work pays off where the data matters, the volume is real, or the other side is unreliable.
Is this the problem you have?
If it is adjacent rather than exact, say so anyway — the useful conversations usually start that way.