Dentacares

A dental clinic SaaS I built solo. The hard parts were multi-session billing that reconciles to the cent, structured insurance claims, and an Electron tray app that files X-rays to the right patient without anyone touching them.

Visit site

Overview

Built and shipped Dentacares end-to-end — a multi-tenant dental clinic SaaS with 56 backend modules, a React 19 web app, a mobile app, and a desktop companion. The kind of project where the hard part isn't any single feature, it's keeping them all coherent.
Designed the multi-session treatment billing engine — splitting a treatment plan's cost across sessions, locking session costs at plan creation, and reserving them against appointments so money couldn't drift between what was quoted and what was charged. Rounding edge cases ate more time than the happy path.
Wrote the insurance layer from scratch: companies, plans, per-procedure pricing, patient coverage, and claim lifecycle. Pricing had to fall back cleanly across plan → company → list price without surprising anyone at the front desk.
Built an Electron Windows tray app that watches the X-ray sensor's output folder with chokidar and auto-uploads new scans to the right patient and reservation — no manual import step, which is exactly the friction clinics hate.
Stood up the infra side too: Redis-backed Bull queues for CSV imports (patients, invoices, expenses), Socket.IO gateways for live chat and notifications, and Sentry + Prometheus so I could actually see what production was doing instead of guessing.

The problem

Clinics were running on a patchwork of spreadsheets, paper, and separate tools that didn't talk to each other — billing in one place, the patient chart in another, X-rays on a sensor's local disk.
Multi-session treatments had no honest way to split cost across visits, so what a patient was quoted and what they were eventually charged would quietly diverge.
Insurance was manual and error-prone: no structured plans, no per-procedure pricing, no claim tracking.
Importing X-rays meant a staff member manually finding the file and attaching it to the right patient — slow, and easy to attach to the wrong one.
Bulk data (patients, invoices, expenses) had to be entered by hand because there was no import path.

The solution

Built a multi-tenant NestJS backend (56 modules) with branch/organization scoping threaded through everything, serving a React 19 web app, a mobile app, and an Electron desktop tool from one API.
Designed the billing engine to lock per-session cost at plan creation and reserve it against reservations, with splitEqually() handling the rounding so totals always reconcile to the cent.
Modeled insurance as companies → plans → per-procedure prices → patient coverage → claims, with pricing that falls back across layers predictably.
Wrote an Electron tray app that watches the sensor folder with chokidar and posts new scans straight to the matching patient and reservation — the import step just disappears.
Added Redis-backed Bull queues for CSV imports with background processing, Socket.IO gateways for live chat and notifications, and wired Sentry + Prometheus so failures and latency are visible instead of inferred.

Outcomes

56-module NestJS backend powering web, mobile, and a desktop importer from one API||Multi-session billing engine with session-cost locking and reservation reservations — quoted cost and charged cost stay in sync||Full insurance stack: companies, plans, per-procedure pricing, coverage, and claims with clean price fallback||Electron tray app auto-imports X-rays to the correct patient + reservation with zero manual steps||Redis/Bull import queues, Socket.IO real-time chat & notifications, Sentry + Prometheus observability in production.

My role

Full-Stack Developer

NestJS, TypeScript, React, PostgreSQL, Redis, Electron