Pranav Yadav monogramCase study · Care-Provider Ops Portal
Case study · Toptal · Ops platform

Care-Provider Ops Portal

A New Jersey behavioral-health nonprofit was managing referrals, service authorizations, and contractor pay in spreadsheets. Contractor invoicing is a financial-integrity problem wearing an operations costume: units of service, authorizations, and pay periods have to reconcile exactly — and errors surface as underpaid people, not as exceptions.

Next.jsFirebaseAirtableshadcn/ui
Care-Provider Ops Portal — screenshot
01

Context

  • A contractor portal covering dashboard, service logs, authorizations, availability, invoices, and document upload, with an administrative review queue.
  • Airtable is the system of record, with Firebase authentication and session handling layered over it.
  • Invoice generation is cron-driven, restructured on client approval from service-date periods to approval cohorts — one invoice per contractor per check run.

Silently wrong is worse than missing. Here, silently wrong meant contractors being underpaid.

02

What I built

A typed schema layer over Airtable, verified against the live metadata API — introduced after hand-maintained status lists in two places drifted from the base, producing empty result sets for users and rejected requests for four valid statuses.

The invoicing engine, with unit coverage, plus Playwright end-to-end tests with screenshot regression across the portal.

A controlled data repair: the corrective backfill ran behind an opt-in flag the scheduler never sets, with before-and-after snapshots diffed field by field to prove the exact scope of what changed.

03

Key decisions

04

Outcome

  • 8 invoices repaired: 310 units and $3,881.50 of contractor pay restored; the worst case moved from 12 units to 184.
  • Test coverage rose from 21 to 32, with the gap that allowed the defect named explicitly.
  • The invoice engine landed as a written specification with dated client approval, after a multi-pass engineering and adversarial review.