Skip to main content

Boardroom Answers · People & Operations · Operational Excellence

Your product is a wrapper on other people's infrastructure — Vercel, Supabase, Anthropic, OpenAI, Clerk. How do you manage YOUR vendors, and what happens to me when one of them fails or changes terms?

The question a Chief Procurement Officer (CPO-P) asks.

The short answer

Public subprocessor list, SOC 2-grade managed platforms underneath, and dual AI providers — Anthropic and OpenAI — already wired in with per-artefact provenance, so no single model vendor owns our fate or yours.

The full executive answer

I would push back on "wrapper" but embrace the question, because fourth-party risk is real and we manage it visibly. Start with transparency: the full subprocessor list is public on our legal pages, so you know exactly whose infrastructure sits under yours — no discovery surprises. Each dependency is a managed, SOC 2-attested platform in its own right, which is precisely why an early-stage vendor builds on them rather than on hand-rolled servers: you inherit the operational maturity of Vercel, Supabase and Clerk instead of inheriting my ability to patch Linux at 3am.

On concentration risk where it matters most — the AI models — we are deliberately dual-provider: the platform runs both Anthropic and OpenAI behind our own gateway, with the provider recorded on every generated artefact for provenance. If one provider has an outage, degrades a model, or changes terms, the other is not a migration project; it is already wired in. That is a stronger position than most AI products, which are silently single-model.

What happens to you when something fails: the status page decomposes our service into subsystems, so an upstream failure shows up scoped — AI generation degraded, say, while your data, reports and dashboards stay untouched — rather than as an unexplained blackout. And the data-layer answer from earlier applies: your data is in standard Postgres and exportable, so even the extreme scenario of a forced infrastructure migration is a vendor problem, not a data-loss event for you.

Grounded in: Third/fourth-party risk management per ITIL 4 supplier management — published subprocessor register, inherited attestations, and dual-sourcing of the single most critical dependency.

Want this answered live, on your data?