CodeSync
Clinics lose money when the visit, the coverage check, and the claim live in different tools. I built that loop as one CodeSync product, with each clinic’s rows isolated, on Next.js, Supabase, and tenant-safe Postgres.
- Next.js
- TypeScript
- Supabase
- PostgreSQL
- RLS
- Healthcare operations
The product tension
Clinics do not lose money because a screen is ugly. They lose it when the visit, the coverage check, and the claim live in different tools.
Front desk puts a patient on the calendar and captures coding without dropping charity or telehealth flags. Billing has to prove eligibility, assemble a claim, then work whatever the payer does not pay. If those jobs do not share clinic, visit, and coverage context, people re-type facts and cannot answer why a balance is stuck.
The constraint was not “build a healthcare website.” It was: keep the operator in one product family, keep each clinic’s rows isolated, and never let the browser speak directly to a payer.
What I built
I did not inherit a finished platform. I built the front of the loop, then carried the same operator into production RCM.
Visit capture. Patient and visit records, scheduling, and coding live in one face sheet so a later claim does not start from broken demographics.
One data plane. I moved that product onto a unified Supabase project—tenant-scoped schemas and one identity—before RCM could grow a second Auth.
Production RCM. On the live operator app I work eligibility, claim lifecycle, insurance A/R, and queues that must show the right clinic after a workspace switch. When money or coverage moves, the write is guarded and leaves a receipt.
How the system fits together
CodeSync is one operator loop on shared identity. Visit capture and RCM are Next.js apps. Postgres via Supabase holds tenant-scoped workflow state. Eligibility, ERA ingest, and notifications stay on the server. Queue lists are contracts: filters and counts belong in the database so a fast page cannot show another clinic’s work.
The calls that shaped the build
- 01
I would not grow a second user table
I put visit capture on a unified Supabase project and kept RCM on workforce membership and entitlements. Isolation belongs in schema and policy. A second Auth per app would have been faster in week one and expensive forever.
- 02
I refused silent writes for money movement
Intake, backfills, and ERA posting go through guarded SQL and receipts. If someone has to replay why a balance moved, the click in the UI is not allowed to be the only record.
- 03
I treated queue correctness as the feature
Speed that shows the wrong tenant is a defect. I push filters into Postgres and keep caches bounded so switching clinic changes rows and counts together.
Trust boundaries
Every operational row is clinic-scoped. The anonymous key does not read another tenant’s worklists, visits, or A/R. Payer calls, files, and privileged jobs stay on the server. Account recovery and route protection are product work: no user enumeration, server-checked recovery links, no authenticated page leaking from browser cache. This study has no PHI and no clinic names.
What I chose—and accepted
Visit capture and production RCM both exist in the history of the product, so I spend time on migrations and review instead of a greenfield CRUD app. Row-level security and receipts cost keystrokes. Shipping a second ownership model would have felt like progress and created two sources of truth.
Why the work matters
Visit capture and CodeSync RCM are one operator loop: calendar to claim, with clinic data isolated. The public brand is codesync.ai. Clinic applications stay on authenticated hosts.
What I would improve next
I would instrument one queue I still own—time-to-eligibility or list freshness after a clinic switch—so the next revision of this study can show a measured curve.