Vendor & Dependency Risk
Engineering Practice & Continuity answers "what if the founder is unavailable." This page answers the infrastructure equivalent: "what if a critical vendor is unavailable, changes terms, or shuts down."
Critical dependencies and their blast radius
| Vendor | Role | If it fails |
|---|---|---|
| Supabase | Postgres, Auth, Row-Level Security | Highest-impact single dependency. Standard Postgres underneath -- data is exportable, not locked into a proprietary format. Migration would require standing up new Auth infrastructure, which is real work but not a rebuild-from-scratch. |
| Cloudflare | DNS, Pages (web + docs hosting), edge proxy, Turnstile | DNS and edge routing are portable (any registrar/CDN). Pages deployments are static builds -- redeployable to any static host within hours, not weeks. |
| Whop | Checkout/billing | Payments-provider risk is the most replaceable category structurally (Stripe and others are drop-in alternatives for subscription billing); the switching cost is integration time, not data lock-in. |
| Exchange APIs (Binance, OKX, Bybit, Bitget, Coinbase, Kraken) | Trade execution | Each is an independently swappable gateway (see Exchange Gateways) -- one exchange changing its API or restricting access degrades that one gateway, not the platform. This is the direct payoff of the non-custodial, per-provider gateway architecture. |
| Sentry | Error tracking | Observability-only; loss would reduce visibility, not availability. |
Why this table matters to a diligence review
The common failure mode for infrastructure-dependent startups is a single vendor whose failure is also the company's failure (e.g., built entirely on a single exchange's proprietary API with no abstraction layer). ChimeraMiND's exchange-gateway pattern was specifically built to avoid that failure mode for the highest-risk dependency category (execution venues) -- see Architecture Overview for the gateway factory pattern. The remaining dependencies (Supabase, Cloudflare, Whop) are all standard, portable infrastructure choices, not custom/proprietary lock-in.
What is not yet formalized
There is no written disaster-recovery runbook per vendor (e.g., a documented step-by-step Supabase-to-alternative migration playbook) -- the above is an architectural risk assessment, not an executed migration drill. Formalizing per-vendor runbooks is reasonable follow-up work, tracked the same way other operational maturity gaps on this page are tracked.