Demo · Selected work · 05

This is what it looks like to model a real operation from scratch — no SaaS, just the tables that actually matter.

A vertical mini-ERP for an ambulatory surgery center. Five linked tables, a drawer that resolves foreign keys live, operator KPIs that recompute on filter — and an insert form per tab so a new row propagates through the whole model.

Healthtech · ASC operations5 tables · 90+ linked rowsSupabase-flavored schemaClient-only · no APIAll values in USD

Bayshore Ambulatory Surgical Center · Ortho · General · ENT · Pain

Miami, FL · Same clinic as the Surgery Board · Same staff, different view

4 surgeons3 anesthesiologists4 rooms

filter · surgeonKPIs computed live from 20 surgeries · 35 consults · 20 patients

OR utilization · wk

17%

4 rooms · 3 days · 11h

Consult → surgery conv.

100%

20 of 20 cleared

Billed

$132k

$131,950

Collected

$66k

50% of billed

AR outstanding

$66k

to chase

Cancellation rate

5%

1 of 20 surgeries

Payer mix · revenue

BCBS$46k · 34%

Aetna$31k · 24%

Medicare$28k · 21%

Self-pay$14k · 11%

Cigna$14k · 10%

Surgeon load · cases + revenue

Dr. Marcus Chen

Orthopedic surgery

7 cases

$62k

Dr. Priya Patel

General surgery

4 cases

$31k

Dr. James Kowalski

Otolaryngology (ENT)

4 cases

$29k

Dr. Sofia Ruiz

Pain management

5 cases

$11k

AR risk · top surgeries with outstanding balance

click to inspect

Operator note

Why this dashboard and no other

Five operational KPIs, not twenty. The people who run this clinic every day measure what was collected, what's still outstanding, how full the rooms are, how often the day falls apart, and how well the valuation funnel converts. Everything else is pretty noise.

Consult → surgery conversion is the most undervalued metric in an ASC. It's where the surgeon wins or loses the day — and where you find out whether pre-auth is a real bottleneck.

The surgeon filter sits at the top on purpose: the owner wants to look at the staff, the surgeon wants to look at themselves. Same dashboard, two readings.

Insert · supabase.surgeries

Writes to local state. KPIs recompute, the new row appears in its table, and the drawer opens on the new record so you can see the FKs resolve.

patient_id*· fk → patients

surgeon_id*· fk

anesth_id*· fk

room_id*· fk

procedure*· text

date*· date

start_time*· HH:MM

duration_min*· int

payer*· enum

amount_usd*· int · USD

consult_id· fk · optional · null = outside the funnel

5 typed tables · pure functions over linked records · fully client-side20 patients · 35 consults · 20 surgeries · 15 payments

How it works

What this demo does, how, and what's missing

What it does

→Models an ambulatory surgery clinic as a mini-ERP of 5 linked tables: patients, valuation consults, surgeries, operating rooms and payments.
→Each table is an Airtable-style view with a Supabase-flavored "schema strip", field-type badges and an RLS hint — selling the data model, not just the UI.
→Click any row to open a drawer that resolves FKs live: see the patient with their consults, surgeries and payments — or the surgery with its origin consult and associated payments.
→Dashboard with operator KPIs (OR utilization, consult → surgery conversion, AR outstanding, payer mix, cancellation rate) that recompute when you filter by surgeon.
→Insert form per tab: add a patient, consult, surgery or payment and watch the KPIs, related rows and drawer reflect it instantly.

How it does it

→Five typed TypeScript arrays in useState are the entire database. FKs are string IDs (pat-001, con-019) — exactly what a Supabase seed would look like.
→The "schema strip" reads from a SCHEMA object describing table, PK, field types and relations. Same source of truth a real migration would generate.
→KPIs are pure functions over the filtered arrays — they group, aggregate and derive ratios on the fly. No table library, no global state.
→Inserts append to the array and auto-open the drawer on the new record so you see the FKs resolve. A reset button rolls everything back to the seed.
→No backend, no real Supabase, no Airtable, no API. Fully client-side and deterministic.

What a real impl would need

→Real Supabase with versioned migrations, RLS by clinic_id, and triggers to keep consistency (completed surgery → expected charge).
→Full CRUD with validation, undo, audit log and a permissions model (front desk, biller, admin, surgeon) — different verbs per role.
→Integrations where it hurts: 837/835 clearinghouse to reconcile payments, Stripe Terminal for POS, and a bridge with the scheduling system to avoid a double source of truth.
→HIPAA: BAAs with every vendor, column-level encryption for PII, retention policy, breach-notification and access logs surfaced in the dashboard.
→Assisted onboarding: import patients from CSV/EHR, map referring MDs to a canonical table, and a "demo mode" so the operator can play with the tool before committing.

The same skeleton works for dental clinics, imaging centers, infusion suites, fertility, or any service business where the asset is equipment-time and billing flows through insurance + patient. The work is modelling the right 4-5 tables, not building the 100th CRUD in the industry.

Back to selected workv1.0 · 2026