What I Learned Shipping to Researchers
Clinical and academic users break your assumptions. Notes on the UCSF × Stanford deployment.
Academic and clinical users are the best stress-testers you'll ever have. They're meticulous, skeptical, and have exactly zero tolerance for data loss.
Assumption 1: Users Will Follow the Happy Path
They won't. Researchers explore. They'll upload files in formats you didn't test, run queries you didn't anticipate, and report bugs with enough detail to make your QA team jealous.
Assumption 2: Downtime is Annoying
In consumer software, downtime is annoying. In clinical settings, downtime can delay patient care. The difference shapes every architectural decision.
For the UCSF × Stanford pipeline, we designed for 99.9% uptime from day one, not as an aspirational goal but as a hard requirement. That means circuit breakers, graceful degradation, and explicit failure modes that surface the right information to the right people.
Assumption 3: Your Data Model is Correct
It isn't. The clinical data schema we started with had to be revised three times based on how researchers actually used the system. Build in migration paths early.
The Thing That Surprised Me Most
Researchers write the best bug reports. Detailed reproduction steps, system state, expected vs. actual behavior, exactly what you'd want from a QA engineer. Treat them as partners in the build, not just users of it.
— Amisha
Filed under: Infrastructure