LabFlow

A tube arrives at the front desk with a name written on it.

From that moment every step is a chance for the name and the tube to come apart. Accessioning. The run. The read. The signature. The release to whoever ordered it.

A laboratory is a chain of custody before it is anything else.

Software that treats a result as a row in a table has already dropped the part that matters, which is not the value in the field but the question of who is allowed to say that value is final.

LabFlow runs on the Firebase free tier wherever Firestore security rules can enforce the policy, and reaches for Cloud Functions only where a rule genuinely cannot.

That line is drawn on purpose. A rule runs on every read and costs nothing; a function is a bill and a cold start.

Multi-tenancy makes the question sharper still. A list query has to prove its own tenant from its own filters, because a rule inspecting a document cannot rescue a query that asked for everything, and the difference between those two is invisible to a green build.

Patient and order management, sample accessioning and tracking, results entry and validation, billing, inventory, quality control and equipment integration.

Results move Draft, then Reviewed, then Approved, then Released. A role gates every transition.

Every patient record, order and result is tenant-scoped and audit-logged, so the question of who changed what has an answer that does not rely on anybody remembering.

Three production surfaces share one tenant model: a React web application, a Capacitor mobile build and Firebase Functions.

Underneath them sits one domain-service layer of 151 services, 28 Zustand stores and 60+ page modules.

It exists so that three surfaces cannot drift into three different definitions of what approved means.

The mobile build keeps core workflows usable offline through Dexie and IndexedDB, because a collection round does not stop where the signal does.

Then the costs, which in this domain are mostly about restraint.

A status machine that refuses is a status machine people will try to route around. So it has to be strict enough to be worth having and loose enough that the laboratory does not quietly start keeping a parallel spreadsheet, and that balance is a product judgement rather than a technical one.

Tenant isolation fails silently.

A correct rule and an over-broad query look identical from the outside, and the only defence is that every list read carries its own tenant filter and an explicit limit. That is checked by reading the queries, not by watching the build go green.

No patient identifier reaches a log or an error report. That is right, and it means a production incident tells me less than it otherwise would, so reproducing one takes longer.

Offline work means conflicts, and conflicts mean somebody has to decide which version of a result is the real one.

No iOS. There is no Apple Developer account behind this work, so the web and Android are the two surfaces it actually reaches.

The workflow is the product. Everything else listed above is scaffolding around one rule: a result does not leave the laboratory until a person with the authority to release it has said that it can.