Nexo Dental

A clinic does not operate through one generic dashboard. Reception works in minutes, keeping appointments and conversations moving. Dentists work around the clinical record at the chair. Managers need the financial and operational picture that emerges from both.

I saw a product opportunity in those handoffs: one shared system could preserve the same patient and financial context while giving each role a surface designed around its own decisions. I founded Nexo Dental to build that product from the data model outward, rather than stitching separate screens onto disconnected records.

Nexo Dental follows work from the first appointment through clinical care, payment, claims, and follow-up. The interface changes emphasis by role, while the underlying patient, treatment, and financial records remain connected. That product boundary shaped the three workspaces below.

Reception starts with time and attention. The agenda organizes appointments across professionals and statuses; the conversations workspace keeps patient communication beside the operational context; and the action queue turns open work into explicit next steps.

The goal is not another notification feed. A receptionist can move from a pending confirmation to the relevant conversation or patient balance without reconstructing why the item matters. The product keeps the queue actionable while a person remains responsible for every response and change.

The patient workspace gives dentists one clinical context rather than a trail of isolated forms. Identity, history, odontogram, encounters, files, treatment proposals, and financial context remain reachable from the same record.

The odontogram is structured clinical data, not a drawing pasted onto a profile. Tooth conditions and procedures feed the clinical timeline and treatment proposal, preserving attribution as the record moves from diagnosis to the front desk. That reduces duplicate interpretation at the handoff between care and administration.

Managers need to understand what clinical and reception work produced: treatment proposals, installments, payments, commissions, insurance claims, and reporting. Nexo Dental keeps those records connected to the patient and clinic tenant instead of treating finance as a separate back-office product.

The management surface exposes the operational trail behind a balance or claim. Reporting routes are present in the implementation, but I describe them as active development rather than presenting the product as a finished analytics program.

A React and TypeScript application talks to a FastAPI service under `/api/v1`; PostgreSQL owns application state and Alembic evolves the schema. The boundary is deliberately conventional so product complexity stays in explicit domain modules rather than leaking into the client.

Every tenant-scoped database session sets `app.tenant_id`, and row-level security is enabled and forced on tenant tables. The application still scopes requests deliberately, while PostgreSQL rejects cross-clinic access if a query path forgets. A guarded MSW mode supplies deterministic fixture data for interface development and public captures without a real clinic session.

Clinical and financial data made application-only filtering an unacceptable boundary. A missed condition on a new query should not be enough to expose another clinic's records.

I built tenant identity into the schema and session lifecycle, then enabled and forced PostgreSQL row-level security through reusable Alembic helpers. That choice adds migration discipline to every tenant-owned table, but it moves the final refusal to the layer that stores the data. Claims fields add AES-GCM protection and masked API representations for another sensitive boundary.

A visual tooth chart would have been faster to ship, but it would stop being useful as soon as encounters, treatment proposals, and finance needed the same facts. I modelled teeth, conditions, and procedures as structured clinical records instead.

The interface can still present an intuitive FDI chart, while the system retains history, attribution, and links to downstream work. The trade-off is a richer clinical model and more careful state transitions. The benefit is one source of clinical meaning across the chart, timeline, proposal, and ledger.

Nexo Dental uses AI assistance beside role-specific work rather than presenting it as an autonomous operator. The action queue ranks open items and deep-links to the next useful surface; adjacent panels can draft assistance, but a person reviews and acts.

That boundary also shapes the backend. Clinical AI inputs are checked for PII before a provider call, and operator capabilities remain role-aware. I chose a narrower, inspectable interaction because clinical, communication, and financial actions need accountable human judgment more than they need the appearance of automation.

I founded, designed, and built Nexo Dental as the sole developer: product direction, interaction system, React application, FastAPI service, PostgreSQL model, tenancy and permissions, clinical and financial domains, communications, claims, AI boundaries, automated tests, and local development tooling.

AI accelerated scaffolding, refactoring, test generation, and review. The product thesis, architecture, implementation, validation strategy, security decisions, and final trade-offs remained my responsibility.

The private repositories contain working paths for scheduling, patients, odontogram and clinical records, finance and treatment proposals, WhatsApp communication, CRM, TISS claims, reporting routes, role-aware navigation, and the action queue. At this revision, 50 backend and 134 frontend test files exercise those domains, tenancy, authentication, runtime guards, and interface behavior.

The engineering safeguards are concrete: forced row-level security, encrypted and masked claim fields, pre-provider PII validation for clinical AI, no-PII assertions on operational payloads, and a production guard against mock data. Nexo Dental remains in active development, its source is private, and there is no verified public environment or published clinic outcome today.

The repositories are private. Every interface capture on this page uses seed or MSW fixture data—never a real clinic or patient—and visible identifiers are invented showcase values. The case study describes what the implementation contains without turning synthetic data into customer, adoption, reliability, or business-impact claims.