Comparison
Make or buy: building Connect detection on webhooks yourself
Receiver exists, signature verified, handlers deployed — the tempting half is done. The ledger below completes the picture: twelve remaining components between current state and trustworthy detection, each owned forever once built. Some teams should build; all teams should see the whole list first.
The component ledger
✓ Receiver/signature · ✗ Claim/dedupe store · ✗ Durable queue+retries · ✗ Race delay+locks · ✗ Detectors · ✗ False-positive corpus · ✗ Backfill pagination · ✗ Risk scoring · ✗ Alerting · ✗ Recovery actions+idempotency · ✗ Audit trail · ✗ Multi-tenant isolation · ∞ schema-drift maintenance.
Run-cost honesty
Serverless economics at volume, on-call rotation, key-custody liability under envelope encryption — recurring costs invisible in build estimates but unavoidable in operations.
When building wins, and the middle path
Regulatory data-residency or bespoke ledger integration justify building. Otherwise adopt detection read-only while keeping ledgers sovereign via exports — control where it matters, delegation where it does not.
Common questions
Start with the scanner while deciding?
That is precisely its job — independent verification costs nothing while options stay open.
Migration effort to adopt?
One read-only key plus webhook endpoint registration; minutes, not projects.