Skip to content

Vendor Stack

Third-party dependencies at the company level. Not architecture (that's docs/engineering/) — this is the what we depend on and what breaks if it goes down view.

Source of truth: Metrognome Technology Vendors doc, owned by the CTO. Update there first; mirror here.

Criticality classification

Two tiers, sorted by what an outage prevents.

Critical — outage directly prevents members from accessing studios or paying

If any of these are down, the business is partially or fully offline.

Vendor What it powers
Stripe Payment processing, billing, subscriptions. Every monthly + hourly transaction. Invoicing, payment methods.
Supabase Database, authentication, storage. Primary data store + auth provider for .com.
Vercel Web app hosting and deployment. Hosts member-facing site + staff tools.
UniFi Access control hardware. Smart locks, key codes, camera systems across all locations.
Mighty Networks SESHN community platform. Whitelabel app for paywalled content + community.

Implication: any architecture decision that creates new critical-tier dependencies should require an explicit decision (consider an ADR).

Operational — outage disrupts specific workflows or comms

If any of these are down, specific functions degrade but core access + payment remain.

Vendor What it powers
Twilio SMS + voice. Member notifications, access codes, staff alerts.
Resend Transactional email — booking confirmations, receipts, account notifications.
Sentry Error monitoring + alerting. Real-time error tracking across web + API.
Cloudflare DNS + network security.
Metabase Business reporting + analytics. Financial + operational dashboards.
Umami Website + marketing analytics. Event tracking for marketing/conversion funnels.
OpenAI AI embeddings for staff documentation search. Powers internal docs RAG.
Google Ads + marketing. Paid search, display, Google Business Profile.
Meta Ads + marketing. Paid social campaigns across Facebook + Instagram.

Strategic notes

Critical vendors are the moat (and the liability)

The Stripe + Supabase + Vercel + UniFi + Mighty Networks stack is what makes the company operate at the current scale with five people. Replacing any of them is a months-long project. Treat the vendor list itself as a strategic asset.

Vendor concentration is the corresponding liability — five outage points span the business. Mitigations:

  • Stripe: see docs/engineering/architecture/stripe/ for webhook + sync architecture; the data sync pipeline (ADR-007) localizes Stripe state.
  • Supabase: dual-purpose (DB + auth); permission system (ADR-006) leans on Supabase Custom Access Token Hook.
  • UniFi: known issues exist (UI can't render developer-API schedules; ticket filed with vendor). Diagnostic scripts kept in tree.
  • Mighty Networks: SESHN is operationally separate from .com — outage isolated to the SESHN pillar.

Vendor decisions are CTO-owned

Per CTO JD V0.3: "Make build vs. buy decisions for technology investments" + "Integrate and manage all third-party partners, systems, and integrations." When a vendor decision is in play, Aaron decides; document the choice in docs/decisions/ if it's significant.

Marketing/ad vendors decouple from the operational stack

Google Ads and Meta Ads are essential for the acquisition function but are separable — the business operates without acquisition spend during a planned slow period (e.g., the Sept–Dec 2025 hourly launch ramp).

Vendor change log

When a vendor is added, swapped, or retired, append to log.md with rationale and link any relevant ADR.

Outstanding items

  • [ ] Quickbooks — bookkeeper integration target referenced in roadmap notes. Current status: integrated, not integrated, on roadmap?
  • [ ] Asana — used as the team's task tracker; should it be listed as Operational tier?
  • [ ] Slack — primary intra-team chat; should it be listed?
  • [ ] AI vendor stack beyond OpenAI (additional model providers for agent workflows)?
  • [ ] Acuity for tour bookings — still in use?