Modern healthcare benefits on Postgres — and what HIPAA on Vercel + Supabase looks like in practice.
Vitable Health is a Philadelphia-based health benefits platform serving 50,000+ members across 400+ small and mid-sized employers, expanded to all 50 states for Direct Primary Care as of May 2026. Founded in 2019 by Joseph Kitonga (Thiel Fellow, Y Combinator S20), it closed a $16M Series A led by Cherryrock Capital in July 2024, bringing total funding to $25M+ across SoftBank, First Round, and Cherryrock.
This map is intentionally split into two source categories. Documented sections describe what is publicly verifiable about Vitable: products, customer flows, named integration partners, scale, funding. Reference pattern sections describe how Vercel + Supabase HIPAA architecture canonically works — sourced from Supabase's and Vercel's own published documentation — not claims about Vitable specifically.
The Supabase customer case study at supabase.com/customers/vitable returns HTTP 404 as of May 2026, and Vitable does not appear in Supabase's public customer list. Vercel is not named in any Vitable public material found during research. Where the prose uses the reference pattern, it says "Supabase's HIPAA architecture works like this" — not "Vitable's architecture works like this." Treat that distinction as load-bearing throughout.
Vitable's customer is the small employer of hourly and variable-hour workers — restaurants, retail, home-care agencies, cleaning services — the "working poor" gap segment that earns too much for Medicaid but too little for marketplace coverage. The product wraps Direct Primary Care (DPC), ICHRA/QSEHRA reimbursement administration, MEC/MVP ACA-compliant plans, and a GLP-1 program into a single platform employers pay roughly $30 per employee per month for. Public-facing surfaces include the member iOS/Android app, employer dashboard, provider dashboard, and the developer portal at developer.vitablehealth.com.
For the technical reader: what's confirmed by sources is the company shape, the named integration partners (Finch, Stripe, Labcorp, Quest, Mishe, Liferaft), the mobile stack (Flutter), and several AWS infrastructure tokens (CloudFront, S3, Route53, PostgreSQL) visible in third-party tech-stack profiles. What's not publicly confirmed is the host of the web tier (Vercel) or the database vendor (Supabase). That makes Vitable interesting as a teaching case: it's a real, modern PHI-handling SaaS company whose actual stack we can describe partially, paired with the canonical "what HIPAA on Vercel + Supabase looks like" pattern that the rest of the industry would have to follow if they wanted to build like this.
Vitable's product line evolved from a 2018 telemedicine/home-visit MVP into a full health benefits stack. The 2025 acquisition of Liferaft added an ICHRA administration platform and a "claims engine" with proprietary carrier integrations, and Vitable subsequently rebuilt the ICHRA Quoting Tool from scratch as an "AI-native" broker product. All product names below appear on Vitable's site, in press releases, or on the developer portal.
graph TD
VIT["Vitable Health Platform"]
subgraph Care["Care Products"]
VPC["Vitable Primary Care
(DPC membership)"]
GLP["GLP-1 Weight Loss
Program"]
MH["Mental Health
(coaching + therapy)"]
LAB["Premium Lab Panels
(100+ diagnostics)"]
OCC["Occupational Health
(CVS / Walgreens)"]
end
subgraph Bene["Benefits Products"]
ICHRA["ICHRA / QSEHRA
Reimbursement Admin"]
MEC["MEC / MVP
ACA Compliance"]
AUTO["ACA Autopilot
(variable-hour)"]
QUOTE["ICHRA Quoting Tool
(2025, AI-native)"]
end
subgraph Dev["Developer Platform"]
CONNECT["Vitable Connect API
(REST + webhooks)"]
WIDGET["Embeddable
Enrollment Widget"]
end
VIT --> Care
VIT --> Bene
VIT --> Dev
style VIT fill:#0A84FF,stroke:#64D2FF,color:#ffffff
style VPC fill:#1c1c1e,stroke:#30D158,color:#f5f5f7
style GLP fill:#1c1c1e,stroke:#30D158,color:#f5f5f7
style MH fill:#1c1c1e,stroke:#30D158,color:#f5f5f7
style LAB fill:#1c1c1e,stroke:#30D158,color:#f5f5f7
style OCC fill:#1c1c1e,stroke:#30D158,color:#f5f5f7
style ICHRA fill:#1c1c1e,stroke:#FF9F0A,color:#f5f5f7
style MEC fill:#1c1c1e,stroke:#FF9F0A,color:#f5f5f7
style AUTO fill:#1c1c1e,stroke:#FF9F0A,color:#f5f5f7
style QUOTE fill:#1c1c1e,stroke:#FF9F0A,color:#f5f5f7
style CONNECT fill:#1c1c1e,stroke:#BF5AF2,color:#f5f5f7
style WIDGET fill:#1c1c1e,stroke:#BF5AF2,color:#f5f5f7
Core DPC membership: unlimited virtual visits, 1,000+ $0 prescriptions, $0 labs, mental-health coaching, dependent coverage included.
Employer-funded, tax-free reimbursement accounts; employees pick marketplace plans. Liferaft platform powers carrier integrations.
Minimum Essential Coverage and Minimum Value Plan tiers satisfying the ACA employer mandate, with automation for variable-hour workforces.
Bundled GLP-1 medication access, clinical oversight, and patient education delivered through the member app.
100+ comprehensive diagnostic panels at member-friendly pricing, fulfilled via Labcorp and Quest Diagnostics retail locations.
REST endpoints for employer/employee onboarding, eligibility, payroll sync, plus webhooks for downstream event delivery.
Pre-built UI component for plan selection, compliance checks, e-signatures, and carrier integrations — embeds in partner apps.
Post-Liferaft rebuild: instant census-to-quote generation, ACA affordability modeling, one-click PDF proposals or shareable scenario links.
The infrastructure picture below is built from three primary sources: Vitable's own GitHub organization (mobile language confirmed via forked Dart/Flutter repos), the Google Play / App Store listings, and third-party technology profiling on RocketReach. Several signals are HIGH confidence (Flutter mobile, Stripe Connect, Labcorp + Quest partnership, Finch HRIS integration). Several are MEDIUM confidence (PostgreSQL database, CloudFront, S3, Route53, ButterCMS) — visible in tech-stack fingerprinting but not officially named by Vitable. Vercel and Supabase are not in this section because no public Vitable material confirms them.
graph TD
subgraph Client["Member & Partner Surfaces"]
IOS["iOS app
(Flutter)"]
AND["Android app
com.vitablehealth.vitable_health"]
WEB["app.vitablehealth.com
(web)"]
EMP["employers.vitablehealth.com"]
PROV["providers.vitablehealth.com"]
DEVP["developer.vitablehealth.com"]
end
subgraph Edge["Edge / CDN"]
CF["CloudFront CDN"]
R53["Route 53 DNS"]
STOR["S3 Object Storage
(lab PDFs, docs)"]
end
subgraph Apps["Application Tier (host unconfirmed)"]
APIS["REST Connect API
+ web app servers"]
CMS["ButterCMS
(headless content)"]
end
subgraph Data["Data Tier"]
PG["PostgreSQL
(vendor not publicly named)"]
end
subgraph Pay["Payments"]
STRIPE["Stripe + Stripe Connect"]
end
subgraph Partners["Named Clinical / HRIS Partners"]
FINCH["Finch
(HRIS, 220+ providers)"]
LCQ["Labcorp + Quest"]
MISHE["Mishe Health
(specialists)"]
end
IOS --> CF
AND --> CF
WEB --> CF
EMP --> CF
PROV --> CF
DEVP --> CF
CF --> APIS
APIS --> PG
APIS --> CMS
APIS --> STOR
APIS --> STRIPE
APIS --> FINCH
APIS --> LCQ
APIS --> MISHE
R53 -.-> CF
style IOS fill:#1c1c1e,stroke:#64D2FF,color:#f5f5f7
style AND fill:#1c1c1e,stroke:#64D2FF,color:#f5f5f7
style WEB fill:#1c1c1e,stroke:#64D2FF,color:#f5f5f7
style EMP fill:#1c1c1e,stroke:#64D2FF,color:#f5f5f7
style PROV fill:#1c1c1e,stroke:#64D2FF,color:#f5f5f7
style DEVP fill:#1c1c1e,stroke:#64D2FF,color:#f5f5f7
style CF fill:#1c1c1e,stroke:#FF9F0A,color:#f5f5f7
style R53 fill:#1c1c1e,stroke:#FF9F0A,color:#f5f5f7
style STOR fill:#1c1c1e,stroke:#FF9F0A,color:#f5f5f7
style APIS fill:#0A84FF,stroke:#64D2FF,color:#ffffff
style CMS fill:#1c1c1e,stroke:#BF5AF2,color:#f5f5f7
style PG fill:#1c1c1e,stroke:#30D158,color:#f5f5f7
style STRIPE fill:#1c1c1e,stroke:#5E5CE6,color:#f5f5f7
style FINCH fill:#1c1c1e,stroke:#FF375F,color:#f5f5f7
style LCQ fill:#1c1c1e,stroke:#FF375F,color:#f5f5f7
style MISHE fill:#1c1c1e,stroke:#FF375F,color:#f5f5f7
| Layer | Technology | Source | Confidence |
|---|---|---|---|
| Mobile app | Flutter (Dart) | Vitable GitHub org forks Dash-Chat-2 (Flutter); Google Play package com.vitablehealth.vitable_health |
HIGH |
| Mobile chat UI | Dash-Chat-2 (Flutter) | Forked repo on Vitable's GitHub org — messaging surface for member ↔ care team | HIGH |
| Document pipeline | PyPDF2 fork (Python) | Vitable GitHub org — implies a Python service for PDF generation (proposals, lab reports) | HIGH |
| Database | PostgreSQL (vendor unnamed) | RocketReach tech-stack profile | MEDIUM |
| CDN | Amazon CloudFront (also CloudFlare visible) | RocketReach | MEDIUM |
| Object storage | Amazon S3 | RocketReach | MEDIUM |
| DNS | AWS Route 53 | RocketReach | MEDIUM |
| Headless CMS | ButterCMS | RocketReach; ButterCMS is commonly paired with Next.js on Vercel | MEDIUM |
| Marketing site | Webflow (vitable-db.webflow.io) |
Visible subdomain | HIGH |
| Payments | Stripe + Stripe Connect | RocketReach; consistent with marketplace routing model | MEDIUM |
| Analytics / CRM | Segment, Google Analytics, HubSpot | RocketReach; Vitable privacy policy confirms GA, FB Pixel, HubSpot, Google Ads on marketing surfaces | MEDIUM |
| Web framework | Unconfirmed (Next.js plausible given ButterCMS pairing) | No public source names a framework | NONE |
| Web host | Unconfirmed (Vercel claimed in research brief but not publicly verified) | No Vitable material names Vercel; not in Vercel's customer pages | NONE |
| Database vendor | Unconfirmed (Supabase claimed in research brief but not publicly verified) | supabase.com/customers/vitable returns 404; not in Supabase public customer list |
NONE |
Everything in the table above with HIGH or MEDIUM confidence has a citable source. The three rows marked NONE represent the gap that motivates the rest of this map: rather than asserting Vercel and Supabase as Vitable's stack, we describe how Vercel+Supabase HIPAA architecture canonically works (sections 05 and 06) so that the pattern can be evaluated on its own terms.
This sequence is reconstructed from Vitable's developer portal, the HRIS support article (which names Finch by name), the privacy policy, and clinical-partner press releases. Every named system below appears in public Vitable material or partner material. The diagram traces an employer signing up through the moment a member completes a primary-care visit and is billed.
sequenceDiagram
autonumber
participant Emp as Employer (HR admin)
participant Portal as employers.vitablehealth.com
participant Finch as Finch (HRIS aggregator)
participant Payroll as Employer's payroll
(ADP / Gusto / Paychex / etc.)
participant Member as Employee (Flutter app)
participant Vit as Vitable backend
participant Prov as Care provider
(providers.vitablehealth.com)
participant Lab as Labcorp / Quest
participant Stripe as Stripe + Connect
Emp->>Portal: Sign up, configure plan
Portal->>Finch: OAuth connect employer payroll
Finch->>Payroll: Pull eligibility roster
Payroll-->>Finch: Roster + payroll data
Finch-->>Vit: Sync employees (webhook)
Vit->>Member: Send invite (email / portal)
Member->>Vit: Create account, add dependents
Vit-->>Member: Digital pharmacy card in app
Member->>Vit: Book primary care visit
Vit->>Prov: Schedule appointment
Prov->>Member: Telehealth or in-home visit
Prov->>Vit: Document encounter, order labs / Rx
Vit->>Lab: Order routing
Lab-->>Vit: Results to care team
Vit->>Stripe: Charge employer subscription
Vit-->>Finch: Payroll deduction (if applicable)
Finch-->>Payroll: Write deduction back
1–5 · Employer onboarding. Finch is explicitly named in Vitable's HRIS support documentation. Finch maintains its own BAAs and integrates with 220+ payroll systems via OAuth; webhook events notify Vitable when rosters change.
6–8 · Member onboarding. The Flutter member app and the embeddable enrollment widget (described on developer.vitablehealth.com) are the two onboarding surfaces. Dependents link to the primary member account. A digital pharmacy card is generated and surfaced inside the app immediately upon enrollment.
9–14 · Care delivery. The telehealth video provider, the EHR backing the provider dashboard, and the PBM behind the formulary card are not publicly named — common DPC choices like Elation Health are plausible but unconfirmed. Labcorp and Quest are explicitly named on Vitable's occupational health page.
15–17 · Billing. Stripe + Stripe Connect appear in the tech-stack profile. Connect's marketplace topology is consistent with routing employer subscription dollars to clinical partners, but the exact Stripe configuration (direct charges vs. transfers) is not publicly disclosed.
This section describes how Supabase's HIPAA-capable Postgres tier works for a multi-tenant healthcare SaaS. It is the canonical pattern an architect would implement on Supabase — sourced from Supabase's own HIPAA and RLS documentation — not a claim about how Vitable specifically operates. The pattern matches what a company with Vitable's shape (multiple employers, members, clinicians, all sharing one database) would have to do on this substrate.
graph TD
subgraph Client["Client (mobile or web)"]
APP["App with Supabase client
(JWT in Authorization header)"]
end
subgraph SBEdge["Supabase Project Edge"]
AUTH["Supabase Auth
(JWT issuer)"]
REST["PostgREST
(auto-generated REST API)"]
end
subgraph PG["Postgres (HIPAA project)"]
ROLE["Role: authenticated
(JWT claims attached)"]
TBL["Tables with RLS enabled
(members, visits, claims)"]
POL["Policies use
auth.uid() + auth.jwt()"]
end
subgraph Server["Server-side worker"]
SVC["service_role key
(bypasses RLS — never sent to client)"]
end
APP -->|sign in| AUTH
AUTH -->|JWT with tenant_id
in app_metadata| APP
APP -->|request + JWT| REST
REST --> ROLE
ROLE --> TBL
TBL --> POL
POL -->|filter rows| TBL
SVC -.->|admin / migrations| TBL
style APP fill:#1c1c1e,stroke:#64D2FF,color:#f5f5f7
style AUTH fill:#1c1c1e,stroke:#a3a3a8,color:#f5f5f7
style REST fill:#1c1c1e,stroke:#a3a3a8,color:#f5f5f7
style ROLE fill:#1c1c1e,stroke:#a3a3a8,color:#f5f5f7
style TBL fill:#0A84FF,stroke:#64D2FF,color:#ffffff
style POL fill:#1c1c1e,stroke:#BF5AF2,color:#f5f5f7
style SVC fill:#1c1c1e,stroke:#FF9F0A,color:#f5f5f7
Supabase's published guidance for multi-tenant SaaS recommends storing the tenant identifier (e.g. employer_id) inside the JWT's app_metadata — the immutable claim namespace — rather than user_metadata, which the user can modify. Row Level Security policies then read that claim via auth.jwt() and use it as an implicit WHERE clause. Every query to a member, visit, or claim row is filtered to the caller's tenant inside Postgres, regardless of what the application layer sends.
A typical policy for a healthcare SaaS in this pattern looks like:
-- Employer tenant isolation CREATE POLICY employer_isolation ON members FOR ALL TO authenticated USING (employer_id = (auth.jwt() -> 'app_metadata' ->> 'employer_id')::uuid); -- Member self-access to their own PHI CREATE POLICY member_self ON health_records FOR SELECT TO authenticated USING (member_id = auth.uid()); -- Provider access scoped by care_team relation CREATE POLICY provider_roster ON visits FOR SELECT TO authenticated USING (EXISTS ( SELECT 1 FROM care_team ct WHERE ct.provider_id = auth.uid() AND ct.member_id = visits.member_id ));
Source: supabase.com/docs/guides/database/postgres/row-level-security — pattern, not Vitable code.Critically, the service_role key bypasses all RLS. It is intended for server-side admin work (migrations, bulk imports, support tooling) and must never reach a client. In a HIPAA workload, leaking it would be considered a breach because the policy enforcement that compartmentalises PHI lives only in the policies; bypass = full read of all tenants.
Per Supabase's HIPAA projects documentation, a project that handles PHI must:
Underneath, Supabase runs on AWS. The BAA chain in this pattern is: customer → Supabase → AWS. Supabase maintains its own BAA with AWS as the downstream subprocessor, and undergoes combined HIPAA + SOC 2 Type II audits. PHI at rest is encrypted with AES-256 (AWS-managed keys); in transit it travels over TLS. Database audit logs — every access, modification, login — are part of High Compliance Mode.
In application-side authorization, a single missed WHERE employer_id = $1 in any handler — including handlers a junior engineer writes years from now — leaks PHI across tenants. RLS moves the check into the database, where it cannot be skipped without explicitly using the service_role key. For multi-tenant healthcare SaaS this is a meaningfully smaller blast radius than the "every endpoint must remember to filter" model.
This section describes how Vercel positions itself as a HIPAA business associate, what its BAA covers, and the resulting architectural constraints any HIPAA Next.js app must respect when hosted on Vercel. As with the Supabase section, the content here is sourced from Vercel's own published documentation — not a claim that Vitable specifically uses Vercel.
flowchart TD
USER["Authenticated user
(web / Flutter web)"]
EDGE["Vercel Edge Network
(Anycast, TLS 1.3)"]
SEC["Vercel Secure Compute
(private VPC, fixed egress IPs)
Enterprise only"]
NEXT["Next.js app
(App Router / Pages)"]
HAND["Route handlers / Server Actions
(node runtime, NOT edge)"]
SUPA["Supabase HIPAA project
(scoped JWT, RLS enforces)"]
LOG["Vercel logs
(must NOT receive PHI)"]
ANA["3P analytics tags
(must be gated off auth pages)"]
USER -->|HTTPS| EDGE
EDGE -->|BAA in effect
Enterprise plan only| SEC
SEC --> NEXT
NEXT --> HAND
HAND -->|server-side fetch with
scoped JWT or service_role| SUPA
HAND -.->|scrubbed metadata only| LOG
NEXT -.->|gated to public pages| ANA
style USER fill:#1c1c1e,stroke:#64D2FF,color:#f5f5f7
style EDGE fill:#1c1c1e,stroke:#FF9F0A,color:#f5f5f7
style SEC fill:#0A84FF,stroke:#64D2FF,color:#ffffff
style NEXT fill:#1c1c1e,stroke:#BF5AF2,color:#f5f5f7
style HAND fill:#1c1c1e,stroke:#BF5AF2,color:#f5f5f7
style SUPA fill:#1c1c1e,stroke:#30D158,color:#f5f5f7
style LOG fill:#1c1c1e,stroke:#FF375F,color:#f5f5f7
style ANA fill:#1c1c1e,stroke:#FF375F,color:#f5f5f7
Per Vercel's Security & Compliance documentation, Vercel will sign a BAA only with enterprise customers and positions itself as a HIPAA business associate. The compliance page lists three commitments: technical/organizational safeguards for PHI, breach notification, and BAAs with enterprise customers. The recommended additional layer for PHI workloads is Vercel Secure Compute, an Enterprise-tier feature that provides a private, isolated cloud environment with dedicated outgoing IP addresses and supports VPC peering and VPN tunnels into the customer's AWS infrastructure. AES-256 at rest and TLS 1.3 in transit are platform defaults.
This produces a small set of hard constraints any HIPAA workload on Vercel must respect:
BAAs are not available on Hobby or Pro plans. Without an Enterprise plan, PHI cannot legally traverse Vercel infrastructure.
Vercel platform logs are operational telemetry, not a covered PHI store. Applications must scrub PHI out of request paths, response bodies, and error messages before anything reaches the log pipeline.
The edge runtime has fewer Node APIs and runs in many global regions. For PHI handling, route handlers and Server Actions should be pinned to the Node.js runtime in a region the BAA contemplates.
Incremental Static Regeneration and Static Site Generation cache rendered HTML at the edge. Any page that contains PHI must be opted out of caching or rendered server-side per-request.
Secure Compute (Enterprise) provides a private VPC, dedicated egress IPs, and the ability to peer with the customer's AWS account — closer to the "BAA-friendly path" for PHI than the shared multi-tenant edge.
Google Analytics, Facebook Pixel, HubSpot tags — the same vendors that appear on most marketing sites — must not fire on authenticated pages where PHI is rendered, or they become a PHI-leak vector to non-BA vendors.
The hardest part of this pattern, in practice, is not the BAA itself — it is keeping PHI out of the long, accidental ways it ends up in logs and analytics. URL parameters carrying member IDs, error stack traces with patient names, third-party tag managers fired before auth gating, ISR pages cached at the edge: any of these can void a Vercel BAA's protection without the team noticing. A properly engineered HIPAA Next.js app treats the Vercel BAA as the floor of the security model, not the ceiling.
Source: Vercel Security & Compliance docs (HIPAA section) + general HIPAA tracking-technology guidance.Vitable is the hub of a multi-sided network: payroll and HRIS on one side, clinical fulfillment on another, payments on a third, and a public Connect API plus an embeddable widget letting partners drive enrollment from inside their own products. Every integration named below appears in a Vitable press release, support article, partner press release, or the developer portal. Acquisitions (Liferaft) are also captured here because they brought entire integration surfaces with them.
graph TD
VIT["Vitable Health
(platform hub)"]
subgraph HRIS["HRIS / Payroll"]
FINCH["Finch
(220+ payroll providers)"]
end
subgraph Clinical["Clinical Fulfillment"]
LABCORP["Labcorp"]
QUEST["Quest Diagnostics"]
MISHE["Mishe Health
(specialists, Jan 2024)"]
end
subgraph PayBill["Payments & Billing"]
STRIPE["Stripe + Stripe Connect"]
end
subgraph Devs["Developer Surface"]
CONNECT["Vitable Connect REST API"]
WIDGET["Embeddable Enrollment
Widget"]
WEBH["Webhooks
(eligibility, enrollment,
deduction events)"]
end
subgraph Partners["Inbound Partners"]
HHAE["HHAeXchange
(homecare agencies)"]
APALY["Apaly marketplace
(enterprise APC)"]
DIRECT["DirectShifts
(100k+ clinicians)"]
HIT["Health In Tech +
MARPAI (eDIYBS)"]
end
subgraph Acq["Acquired / Embedded"]
LIFE["Liferaft
(ICHRA claims engine
+ carrier integrations)"]
end
FINCH -->|OAuth, webhooks| VIT
VIT -->|orders / referrals| LABCORP
VIT -->|orders / referrals| QUEST
VIT -->|referrals| MISHE
VIT -->|charges, marketplace
transfers| STRIPE
VIT --> CONNECT
VIT --> WIDGET
CONNECT --> WEBH
HHAE -.->|enrollment via API| CONNECT
APALY -.->|enrollment via API| CONNECT
DIRECT -.->|enrollment via API| CONNECT
HIT -.->|quoting integration| CONNECT
LIFE -->|merged in| VIT
style VIT fill:#0A84FF,stroke:#64D2FF,color:#ffffff
style FINCH fill:#1c1c1e,stroke:#FF375F,color:#f5f5f7
style LABCORP fill:#1c1c1e,stroke:#30D158,color:#f5f5f7
style QUEST fill:#1c1c1e,stroke:#30D158,color:#f5f5f7
style MISHE fill:#1c1c1e,stroke:#30D158,color:#f5f5f7
style STRIPE fill:#1c1c1e,stroke:#5E5CE6,color:#f5f5f7
style CONNECT fill:#1c1c1e,stroke:#BF5AF2,color:#f5f5f7
style WIDGET fill:#1c1c1e,stroke:#BF5AF2,color:#f5f5f7
style WEBH fill:#1c1c1e,stroke:#BF5AF2,color:#f5f5f7
style HHAE fill:#1c1c1e,stroke:#FF9F0A,color:#f5f5f7
style APALY fill:#1c1c1e,stroke:#FF9F0A,color:#f5f5f7
style DIRECT fill:#1c1c1e,stroke:#FF9F0A,color:#f5f5f7
style HIT fill:#1c1c1e,stroke:#FF9F0A,color:#f5f5f7
style LIFE fill:#1c1c1e,stroke:#FFD60A,color:#f5f5f7
| Partner | Function | Direction | Source |
|---|---|---|---|
| Finch | HRIS / payroll aggregator across 220+ providers (ADP, Gusto, Paychex, Rippling, UKG, iSolved, QuickBooks Payroll, Workday, etc.) | Inbound (rosters, payroll) + outbound (deduction writeback) | Vitable HRIS support docs |
| Labcorp | Lab testing at retail locations; covered occupational and clinical labs | Outbound orders, inbound results | Vitable occupational-health page |
| Quest Diagnostics | Lab testing at retail locations; alternative to Labcorp for member convenience | Outbound orders, inbound results | Vitable occupational-health page |
| Mishe Health | Specialist care navigation, all-inclusive procedure bundles, case management | Outbound referrals | PR Newswire, Jan 2024 partnership |
| Stripe + Stripe Connect | Employer subscription billing; Connect topology consistent with marketplace routing to clinical partners | Outbound charges, transfers | RocketReach tech stack |
| Liferaft (acquired) | Modular ICHRA platform with "claims engine" and proprietary carrier integrations for ACA marketplace plan verification | Merged into Vitable as ICHRA core | PR Newswire, May 2025 |
| HHAeXchange | Homecare agency workforce activates Vitable benefits via HHAeXchange Partner Connect marketplace | Inbound enrollment via Connect API | HHAeXchange Partner Connect page |
| Apaly | Advanced Primary Care marketplace for enterprise employers; Vitable listed as a provider | Inbound enrollment | Business Wire, May 2025 |
| DirectShifts | Clinician staffing platform; Vitable provides DPC memberships to DirectShifts' 100k+ clinicians | Inbound enrollment | Business Wire, Dec 2025 |
| Health In Tech + MARPAI | Self-funded plan quoting through eDIYBS platform, bundling Vitable DPC as a benefit option | Inbound quoting integration | PR Newswire, Jan 2025 |
| Vitable Connect API | Public REST API: employer/employee onboarding, eligibility, payroll sync, plus webhook events | Outbound surface for partners | developer.vitablehealth.com |
| Embeddable Enrollment Widget | Pre-built UI for plan selection, compliance checks, e-signatures, carrier integrations — hosts inside partner apps | Outbound surface | Developer portal overview |
Notice the pattern: Vitable owns the platform, sells DPC + benefits, and lets other systems drive enrollment into it. Finch on the HRIS side means Vitable doesn't have to build 220+ payroll integrations. HHAeXchange, Apaly, DirectShifts, and Health In Tech on the partner side mean Vitable doesn't have to acquire each enterprise or staffing-platform customer one-by-one — the partner brings the roster. The Connect API + widget is the surface that makes that scalable. This is the API/marketplace shape of the company, independent of which database or web host sits underneath.
This diagram is the union of everything in sections 02–07. Solid borders mark Documented components (publicly verifiable Vitable details). Dashed borders mark Reference pattern components (canonical Vercel + Supabase HIPAA architecture from those vendors' own docs — not a claim that Vitable specifically uses them). Treat the dashed nodes as "what an architect would add if they were building Vitable's shape on this substrate."
graph TD
VIT["Vitable Health
(platform hub)"]:::documented
%% Documented client surfaces
FL["Flutter app
iOS + Android"]:::documented
WEBAPP["Web frontends
app / employers / providers"]:::documented
DEV["developer.vitablehealth.com"]:::documented
%% Documented edge / storage
CF["CloudFront CDN"]:::documented
S3["S3 object storage"]:::documented
BUTTER["ButterCMS"]:::documented
%% Documented data + payments
PG["PostgreSQL DB
(vendor unnamed)"]:::documented
STR["Stripe + Stripe Connect"]:::documented
%% Documented partners
FINCH["Finch HRIS
(220+ providers)"]:::documented
LCQ["Labcorp + Quest"]:::documented
MISHE["Mishe Health"]:::documented
LIFE["Liferaft claims engine
(acquired May 2025)"]:::documented
CONNECT["Vitable Connect API"]:::documented
%% Reference-pattern nodes (Vercel + Supabase canonical)
VERCEL["Vercel Edge
(BAA on Enterprise)"]:::reference
SECCOMP["Vercel Secure Compute
(private VPC)"]:::reference
SUPAUTH["Supabase Auth
(JWT issuer)"]:::reference
PGREST["PostgREST
(auto REST API)"]:::reference
RLS["Postgres RLS policies
(tenant + role isolation)"]:::reference
VAULT["Supabase Vault
(secrets)"]:::reference
REALTIME["Supabase Realtime
(Postgres CDC)"]:::reference
EDGEFN["Supabase Edge Functions
(Deno workers)"]:::reference
FL --> CF
WEBAPP --> CF
DEV --> CF
CF --> VERCEL
VERCEL --> SECCOMP
SECCOMP --> VIT
VIT --> BUTTER
VIT --> S3
VIT --> STR
VIT --> FINCH
VIT --> LCQ
VIT --> MISHE
VIT --> LIFE
VIT --> CONNECT
VIT --> SUPAUTH
SUPAUTH --> PGREST
PGREST --> RLS
RLS --> PG
VIT -.-> VAULT
VIT -.-> REALTIME
VIT -.-> EDGEFN
EDGEFN --> PG
classDef documented fill:#0A84FF,stroke:#64D2FF,color:#ffffff,stroke-width:2px
classDef reference fill:#1c1c1e,stroke:#a3a3a8,color:#f5f5f7,stroke-dasharray:5 5,stroke-width:2px
Eight nodes on this map are dashed: Vercel Edge, Vercel Secure Compute, Supabase Auth, PostgREST, Postgres RLS, Supabase Vault, Supabase Realtime, and Supabase Edge Functions. These describe how Vercel + Supabase canonically slot together for a HIPAA SaaS at Vitable's shape — not what Vitable has publicly disclosed. The solid blue Vitable hub, the AWS edge surfaces (CloudFront, S3), ButterCMS, Postgres, Stripe, Finch, Labcorp, Quest, Mishe, Liferaft, and Connect API are all sourced from Vitable's own material or partner press releases.
See sections 03, 05, 06, and 07 for per-node citations.Vitable's privacy policy explicitly designates the company as a HIPAA business associate when members receive services through employer group health plans. The employer's health plan is the covered entity; the medical group delivering clinical care operates under its own Notice of Privacy Practices. Everything in the "Documented Vitable posture" table below is sourced from Vitable's own materials or named partners' security pages. The "Reference pattern" subsection describes what HIPAA on Vercel + Supabase canonically requires — sourced from Supabase's and Vercel's published HIPAA documentation.
| Claim | Detail | Source |
|---|---|---|
| HIPAA role | Vitable acts as a Business Associate to employer-sponsored covered entities; medical group operates under its own NPP. | vitablehealth.com/privacy |
| Encryption posture | Privacy policy references "administrative, technical, and physical safeguards" for PHI without specifying algorithms. | vitablehealth.com/privacy |
| HRIS BAA | Finch (named HRIS integration) maintains its own BAAs and is SOC 2 Type II with AES-256 at rest, TLS 1.2+ in transit. | tryfinch.com security page |
| Lab partners under HIPAA | Labcorp and Quest Diagnostics are covered entities in their own right; routine BA relationships apply. | vitablehealth.com/occupational-health |
| HHAeXchange marketplace | Vitable enrollment available through HHAeXchange Partner Connect for homecare agency workforces. | hhaexchange.com/partner-connect/vitable |
| Apaly APC marketplace | Vitable listed as a virtual primary care partner inside Apaly's Advanced Primary Care marketplace. | Business Wire, May 2025 |
| Breach record | No public Vitable breach reports found in OCR/HHS portal or news coverage as of May 2026. | HHS OCR breach portal search |
| Status page | 5 tracked components on status.vitablehealth.com (Infrastructure, Member App, Employer Dashboard, EMR, Member Dashboard) reporting 100% uptime over trailing 90 days. | status.vitablehealth.com |
Supabase's HIPAA pattern requires four things in lockstep: HIPAA add-on at the organization level (Team or Enterprise tier — purchased separately from the base plan), a signed BAA with Supabase, High Compliance Mode enabled per project, and the operational triad of Point in Time Recovery, SSL Enforcement, and Network Restrictions. Supabase runs on AWS as a downstream subprocessor — the BAA chain is documented as customer → Supabase → AWS.
Vercel's HIPAA pattern requires an Enterprise plan; BAAs are not available on Hobby or Pro. The canonical PHI-safe configuration adds Vercel Secure Compute (Enterprise-tier) for a private VPC with fixed egress IPs, peering directly into the customer's AWS account or the Supabase project's allowlist. Encryption defaults are AES-256 at rest and TLS 1.3 in transit on both platforms.
flowchart LR
EMP["Employer
(covered entity)"]
CUST["Vitable
(business associate)"]
VER["Vercel
(BAA, Enterprise only)"]
SUP["Supabase
(BAA, HIPAA add-on)"]
AWS["AWS
(downstream BAA)"]
EMP -->|BAA| CUST
CUST -->|BAA| VER
CUST -->|BAA| SUP
SUP -->|BAA| AWS
VER -.->|infra| AWS
style EMP fill:#0A84FF,stroke:#64D2FF,color:#ffffff
style CUST fill:#0A84FF,stroke:#64D2FF,color:#ffffff
style VER fill:#1c1c1e,stroke:#a3a3a8,color:#f5f5f7,stroke-dasharray:5 5
style SUP fill:#1c1c1e,stroke:#a3a3a8,color:#f5f5f7,stroke-dasharray:5 5
style AWS fill:#1c1c1e,stroke:#a3a3a8,color:#f5f5f7,stroke-dasharray:5 5
Vercel platform logs are operational telemetry, not BAA-covered PHI stores. Applications must scrub member IDs, lab results, and patient names from request paths, error stacks, and response logging before anything reaches the log pipeline.
Next.js Incremental Static Regeneration caches rendered HTML at the edge. Any page that contains PHI must opt out of ISR/SSG and render server-side per request, or PHI becomes cacheable across the global edge network.
The Vercel edge runtime has reduced Node APIs and runs in many global regions, making region-pinning and audit logging harder. Route handlers and Server Actions that touch PHI should be pinned to the Node.js runtime, ideally inside Secure Compute.
Vercel Analytics, Speed Insights, and any third-party tag (Google Analytics, Facebook Pixel, HubSpot) must be gated to unauthenticated marketing surfaces. Firing them on an authenticated PHI page is a known HIPAA tracking-technology violation pattern.
The Supabase service_role key bypasses Row Level Security entirely. In a HIPAA workload, this key must live only on server-side workers behind Secure Compute and never reach a client bundle, Vercel client component, or browser JavaScript.
Supabase's High Compliance Mode includes continuous monitoring of project settings (PITR, SSL enforcement, IP allowlist) with the Security Advisor flagging drift. Combined with database audit logs of every access, modification, and login.
The dominant HIPAA failure mode on this substrate is not a missing BAA — it is PHI leaking through accidental paths: query parameters carrying member IDs ending up in Vercel access logs; stack traces with patient names landing in Sentry without scrubbing; ISR caches retaining personalized HTML at edge POPs; Google Analytics tags firing on authenticated pages because someone reused a marketing layout. A correctly engineered HIPAA Next.js + Supabase app treats the BAA as the floor of the security model and adds explicit PHI-scrubbing middleware, route-level cache opt-outs, and analytics gating on top.
Sources: vercel.com/docs/security/compliance + supabase.com/docs/guides/platform/hipaa-projects + HHS OCR tracking-technology bulletin.This section compares three common substrates an engineering team can build a HIPAA + multi-tenant + AI-adjacent healthcare SaaS on. It does not claim that Vitable uses any specific subset. The Vercel + Supabase column reflects what Supabase and Vercel publish about their own platforms; the AWS and GCP columns reflect those vendors' published healthcare and HIPAA documentation. Treat this as the architect's decision matrix, not a description of Vitable's actual production stack.
For a company shaped like Vitable — PHI-handling, multi-tenant by employer, growing partner API surface, AI-curious but not AI-clinical — the substrate decision usually comes down to three families: a Vercel + Supabase managed pair, an AWS-native build (Amplify or App Runner + RDS + Cognito + Bedrock), or a GCP-native build (Cloud Run + Cloud SQL + Identity Platform + Vertex AI). Each has predictable shapes of tradeoff.
| Dimension | Vercel + Supabase | AWS native | GCP native |
|---|---|---|---|
| Time to first PHI prod | Days to weeks (managed Postgres + auth + RLS out of the box) | Weeks to months (IAM, VPC, RDS hardening, Cognito setup, Lambda runtime, KMS, CloudTrail) | Weeks (similar to AWS but smaller component count via Cloud Run) |
| Multi-tenancy primitives | Postgres RLS + JWT claims is first-class — documented pattern, copy-paste policies | RLS available on RDS Postgres; tenant isolation typically per-schema or per-row, no built-in JWT bridge | Same as AWS — Cloud SQL Postgres has RLS but you wire identity yourself |
| BAA scope clarity | Two BAAs (Vercel + Supabase) plus downstream AWS; clear chain, but PHI-out-of-logs onus is high | One BAA covers the universe (AWS BAA enumerates ~140 HIPAA-eligible services); clearest scope | One BAA covers all GCP HIPAA-included services; clear and broad |
| Vendor lock-in | Supabase is Postgres-portable; Vercel's edge primitives + ISR are sticky | High — IAM, KMS, Lambda runtime, Step Functions are AWS-specific | Similar lock-in to AWS, slightly less in compute (Cloud Run is OCI-portable) |
| AI service maturity (HIPAA-eligible) | No first-party LLM — bring Bedrock / Vertex / OpenAI / Anthropic; each needs its own BAA | Bedrock (Anthropic, Meta, Mistral, Amazon) is HIPAA-eligible under the AWS BAA | Vertex AI (Gemini, third-party models) HIPAA-eligible under GCP BAA |
| Cost shape | Per-MAU (Supabase) + per-edge-request (Vercel) — predictable at small scale, can spike on viral surfaces | Reserved Instances + Savings Plans give cost predictability at scale, painful at small scale | Sustained-use discounts automatic; small-team friendly |
| Compliance breadth | HIPAA, SOC 2 Type II (both); HITRUST gap on Supabase as of May 2026 | HIPAA, SOC 2, HITRUST CSF, FedRAMP High, ISO 27001 — the broadest cert surface | HIPAA, SOC 2, HITRUST, ISO 27001 — nearly parity with AWS |
| Talent pool | Next.js + Postgres developers are abundant; "Supabase + RLS" expertise is concentrated | Largest engineer pool; AWS skills are baseline at most healthcare orgs | Solid GCP talent pool, smaller than AWS in healthcare |
| Eject-hatch difficulty | Postgres dump out of Supabase is portable; Vercel-side rebuild on AWS App Runner is multi-week | Moving off AWS is a years-long project at any scale | Cloud Run + Cloud SQL is more portable than AWS-native, but identity + IAM is sticky |
| Eng-team break-even | Sub-15 engineer teams come out ahead on velocity-per-headcount | Pays off at ~25+ engineers when platform team can amortize | Pays off at ~20+ engineers; smaller platform team needed than AWS |
Vercel + Supabase wins for small-to-mid teams (under ~20 engineers) building Postgres-shaped multi-tenant SaaS that want RLS + JWT tenant isolation as a first-class primitive. Pays the cost in tag-management discipline and a more bespoke AI-service BAA story.
AWS native wins for orgs where regulatory breadth (FedRAMP, HITRUST) or in-platform AI (Bedrock) outweighs the slower time-to-prod, and where the platform-engineering team can be invested in.
GCP native is a middle ground: less broad than AWS on regulatory coverage but with Vertex AI as a HIPAA-eligible AI primitive and lower platform overhead. Often the right call when AI-on-PHI is core to the product.
Sources: supabase.com/docs/guides/platform/hipaa-projects; vercel.com/docs/security/compliance; aws.amazon.com/compliance/hipaa-eligible-services-reference; cloud.google.com/security/compliance/hipaa.Vitable's evolution is well-documented in press releases, founder interviews, and the company news page. The funding ladder, acquisition, geographic expansion, and the "AI-native" rebuild of the ICHRA stack are all on the public record. Note that "AI-native" is the company's own press-release framing — no technical disclosure exists about which models or infrastructure power it, and the label appears in founder-facing materials rather than engineering posts.
| Phase | Date | Event | Source |
|---|---|---|---|
| Origin | 2018–2019 | Joseph Kitonga starts Vitable as a side project at Penn State, then drops out. Initial product: home-visit + telemedicine MVP. | Penn State Invent; Philadelphia Inquirer |
| YC + first capital | Summer 2020 | Y Combinator S20 batch. Kitonga becomes a Thiel Fellow. | Y Combinator company profile |
| SoftBank pre-seed | Oct 2020 | $1.6M from SoftBank Opportunity Fund — first health investment from that fund. | TechCrunch, Oct 2020 |
| First Round seed | Oct 2021 | $7.2M seed led by First Round Capital. | Vitable blog; Crunchbase |
| Forbes 30U30 | 2022 | Kitonga on Forbes 30 Under 30 (Healthcare). | Forbes |
| Mishe partnership | Jan 2024 | Specialist care navigation via Mishe Health launched. | PR Newswire, Jan 2024 |
| Series A | Jul 2024 | $16M Series A led by Cherryrock Capital (Newark Venture Partners, Citi Impact Fund, First Round, Commerce Ventures, YC participating). Total raised crosses $25M. | MedCity News, Finsmes, Citi interview |
| HIT + MARPAI | Jan 2025 | Health In Tech + MARPAI tripartite deal: Vitable DPC as a bundled benefit in self-funded eDIYBS plans. | PR Newswire, Jan 2025 |
| Liferaft acquisition | May 2025 | Acquires Liferaft's ICHRA platform with proprietary carrier integrations and a "claims engine." Press materials describe a subsequent "AI-native" rebuild in roughly three months, with claims of eliminating ~25% of administrative cost. | PR Newswire, May 2025; HIT Consultant |
| 50-state DPC | May 2025 | Direct Primary Care plan expands to all 50 states. | Business Wire, May 2025 |
| Apaly partnership | May 2025 | Listed as a virtual primary care partner in Apaly's enterprise APC marketplace. | Business Wire, May 2025 |
| ICHRA Quoting Tool | Oct 2025 | Launches the "AI-native" instant ICHRA quoting tool for brokers: census upload → quote in seconds, one-click PDF or shareable scenario link. | AIJourn; streetinsider.com |
| DirectShifts partnership | Dec 2025 | Partnership extends DPC access to DirectShifts' 100,000+ clinicians. | Business Wire, Dec 2025 |
| Nationwide reaffirmation | May 2026 | 50-state DPC availability reaffirmed; status page reports 100% uptime over trailing 90 days. | Business Wire, May 2026; status.vitablehealth.com |
The phrase "AI-native" appears in three places in public Vitable material: the Liferaft acquisition press release, the ICHRA Quoting Tool launch coverage, and the HHAeXchange partner page (which mentions "AI assistants"). These are press-release wording, not engineering disclosure. No public source names a model provider, an LLM vendor BAA, an inference platform, or any infrastructure detail. The 25% administrative-cost-elimination claim is the company's own marketing figure. Treat "AI-native" as a strategic positioning signal — not a technical claim.
Administrative automation (eligibility processing, ICHRA quoting, compliance checks), member-facing care-navigation lookups, and the Liferaft "claims engine" for plan-design automation. All three are administrative, not clinical.
The model provider, the inference platform, whether PHI transits any AI endpoint, what BAA covers the AI subprocessor, the choice of RAG store, the use of fine-tuning, and any clinical-AI feature. The "AI-native" label sits alongside zero engineering detail.
A Series B in 2026–2027 is the most likely next funding step given the Series A timing. AI-on-PHI features (with the BAA work that entails) are the obvious next product direction given the "AI-native" positioning — but nothing public confirms a timeline.
Every acronym used in this map, in alphabetical order. The healthcare-benefits acronyms cluster (DPC, ICHRA, QSEHRA, HRA, MEC, MVP, ACA, GLP-1) describes Vitable's product space. The compliance cluster (HIPAA, BAA, PHI, PII, OCR, NPP) describes the regulatory frame. The infrastructure cluster (RLS, JWT, OAuth, SAML, PostgREST, CDN, ISR, VPC, IAM, KMS) describes the substrate.
Documented sections cite Vitable's own materials and named partners' press releases. Reference-pattern sections cite Supabase's and Vercel's published documentation. The Supabase customer case study at supabase.com/customers/vitable returned HTTP 404 as of May 2026 and is included only to document the gap that motivates the dual-badge framing.