Skip to content
How much to read
Adwitiya Rahman
EmailResume

Knowledge base

projects / clarity

Clarity, a financial ledger for one dentist that answers what Excel cannot

A web ledger built for a single practising dentist that speeds up his existing habit and answers who still owes him money, a question his spreadsheet cannot.

overview · current · updated 2026-09-22 · Clarity case study

Clarity replaces a practising dentist's manual Excel workbook with a fast web ledger. The user is "a dentist I know", the owner of a real single clinic practice, not a persona. He entered every transaction by hand for roughly 16.5 months. Clarity is built to accelerate that habit, not replace it: voice capture is out of scope, and entry stays a deliberate desk action after a procedure.

The wedge

The workbook is a cash receipt log, not a treatment ledger. Every row is a payment tagged with a treatment type, with no patient entity, so multi visit and instalment treatments cannot be linked. He tracked who still owed him money by hand, in margin cells, invisible to any formula. That gap is the product's reason to exist. See the open case accelerator.

How it is built

Twelve findings, derived by unzipping the workbook and recomputing aggregates from raw cell values rather than trusting cached formulas, drove every entry screen decision: no prefilled amount, lab and consultant charges off the default path, five recency ranked amount shortcuts. See numbers for the underlying figures.

Insights, the headline AI feature, keeps the model away from arithmetic entirely: a typed, unit tested engine computes every figure, and the model only narrates it, checked by a deterministic faithfulness gate before anything reaches the screen. See deterministic narration and the eval suite.

Status

The dentist is still using it and reports his pain points closed as of the last check in. Login is invite-only by decision, and the ledger now exports as a real four-sheet Excel workbook. See XLSX export, known gaps, and open questions.

A rebuild, Clarity 2, adds a second user (an attendant who books the phone schedule) and a new stack, and is being built now, beginning with a design review with both users at the clinic's own address. See v2. That review's second work order, a role-chosen desk and phone shell over one made-up clinic, is built and verified at the live address (details). Its third, the desk's Today entry path, is built and verified too (details).

A four-page replacement for the clinic's own website is built and verified at a preview address, marked noindex, while its launch waits until after cutover (the review build, the decision).

Pages

This page was written by a model from my own repositories and checked by a second one against the same sources. I did not write it, and no version of it was approved by me before it went up. How that works, and where it can still be wrong.