Every clinician knows the feeling: software that technically does the task, designed by someone who has clearly never done the task. Logbooks that take longer than the operation note. Portfolio systems that treat evidence collection as an end in itself. Forms that ask for the same patient details four times across three tabs.
The reflex is to blame the developers. That is the wrong target. The developers built exactly what they were told to build by people who, like them, were one step removed from the ward. The gap is not skill. It is distance — between the person who feels the friction and the person who writes the code.
I started building because I was tired of that distance. Over the last few years I have built and shipped six tools for clinical work: a portfolio tracker for the Portfolio Pathway and CESR route, a surgical logbook, a patient-reported outcomes platform, an AI dictation tool, a consultant-interview prep tool, and a research assistant that is still in development. None of them is sophisticated by the standards of a real software company. All of them exist because the friction they remove was friction I felt myself, repeatedly, and could describe precisely.
The advantage is the brief, not the code
The genuinely hard part of clinical software is almost never the engineering. It is knowing what to build. A working surgeon already holds the most valuable artefact in the whole process: an accurate mental model of the workflow, including the parts that never make it into a requirements document. The five-second hesitation. The field everyone leaves blank. The export that has to match a specific royal college template or it is useless.
A developer has to reconstruct that model through interviews and guesswork, and they lose fidelity at every step. A surgeon who can build — even badly — skips the lossy translation entirely. You are both the domain expert and the user, and you can iterate against your own irritation in real time. That is a structural advantage no amount of engineering talent compensates for.
You do not need to be good at it
This is the part people resist. You do not need a computer science degree or clean architecture. The bar is not “production-grade engineering.” The bar is “better than the spreadsheet you are using now,” and that bar is low.
Modern tools have collapsed the cost of getting from idea to working prototype. A logbook that captures cases the way you actually classify them, runs on your own machine, and exports what your college wants is a weekend of effort, not a funded project. The code can be ugly. The data model can be naive. If it removes friction from your week and nobody’s safety depends on its internals, it is doing its job.
Where the caution belongs
There is a real line, and it runs through patient data. The moment software touches identifiable information, the calculus changes completely: information governance, encryption, access control, and a clear answer to “where does this data live and who can reach it” stop being optional. My own rule is strict — anything resembling a logbook or an outcomes tool is designed to be de-identified by construction. No free-text patient fields, coded categories only, stored locally, with the identifiers kept somewhere the application never sees. Build for the version of yourself who has to explain the design to an IG officer, not the version in a hurry.
That caution is the cost of admission, not a reason to stay out. The clinicians who understand the workflow are the ones who should be shaping the tools — and increasingly, the ones who can.