Your entire platform sits on Vercel, Supabase and Clerk — three venture-backed vendors. What is your concentration risk and what is my exit if one of them dies?

The full executive answer

It is a real concentration, so let me walk the portability of each layer, because the honest answer is that the risk is much smaller than the logo list suggests. The database is the crown jewel and the most portable: Supabase is standard, unmodified Postgres — the most widely supported database in the world. Our 192 migrations are plain SQL, our row-level security policies are Postgres-native features, and pgvector is open source. A dump-and-restore lands us on RDS, Cloud SQL, or self-hosted Postgres — Supabase itself is open source and self-hostable. No proprietary database features, no proprietary query language.

The application is standard Next.js — open source, and deployable on AWS, Azure, Google Cloud, or containers; Vercel is the best host for it, not the only one. The genuinely stickiest layer is Clerk, and we chose our integration pattern for that reason: because we adopted SAML/SCIM standards rather than Clerk-proprietary auth, migrating to another identity platform (WorkOS, Auth0, or self-hosted) is a re-integration project, not a data-model rewrite — user identity ultimately lives in your IdP, not in Clerk. The AI layer is dual-vendor by construction: Anthropic primary, OpenAI fallback, behind one gateway abstraction, so no single model vendor is load-bearing.

This maps to the exit-strategy expectations regulators now apply to material outsourcing — the EBA/DORA operational-resilience regimes ask exactly your question — and our answer is: documented exit paths per layer, standard-technology choices at every tier, and your data continuously exportable via API and file export, so your exit never depends on our cooperation on the day.