There is a particular kind of hospital software that costs a fortune, requires three logins and a VPN, takes nine seconds to load a list of forty patients, and is defended on the grounds that it is enterprise-grade. I spent a weekend replacing one such system — for my own use, with proper care about what data went where — with a single file. The file was a SQLite database, the application was a few hundred lines of code running on the laptop already on my desk, and the whole thing opened the same list of patients before my finger had left the trackpad. This is not a brag. It is a cautionary tale that happens to have a happy middle.
The reason it felt like sorcery is unglamorous: distance. The enterprise system kept its data in a datacentre somewhere, behind a load balancer, behind an authentication service, behind another service whose job was apparently to think about the first service. Every click was a question shouted across the country and a long wait for the answer to come back. The laptop version kept its data in a file an inch beneath the keyboard. There is no network round-trip to a desk drawer. Below is the race, and it is not close — fire a query and watch the on-device read finish while the cloud version is still clearing its throat.
I round the numbers honestly: a local SQLite read is genuinely sub-millisecond to single-digit-millisecond territory, and a chatty cloud system can absolutely spend hundreds of milliseconds per interaction once you add the network, the auth handshake and a few unnecessary services nodding at each other. The bar for the local read is stretched here only so your eye can see it finish at all. That gap is not a bug in the expensive system. It is physics, and physics does not respond to procurement.
When the weekend rebuild is wise
SQLite is the most deployed database on Earth — it is in your phone, your browser, your aeroplane — and it is wonderful precisely when the job is one person or one device reading and writing their own data fast. A logbook. A clinic’s local audit. A personal research dataset. There is no server to administer, no cloud bill, no 2 a.m. page when a managed instance falls over, and the entire system is a file you can copy onto a stick. For a great many “systems” that are really just a glorified spreadsheet with ambitions, this is not a downgrade. It is the correct amount of software.
When it is absolutely a trap
Now the cold water, because a fair essay owns its limits. The moment many people need to write to the same data at the same instant, a single file on a laptop is the wrong tool, and pretending otherwise is how you lose a Tuesday’s records to a clobbered write. The moment the data is identifiable patient information that must be governed, audited, backed up to standard and survive the laptop being left on a train, “a file on my desk” stops being charming and starts being a serious problem. Enterprise systems are slow partly because they are doing genuinely hard things — access control, audit trails, resilience, regulatory survival — that my weekend file simply does not attempt. Speed is not the only axis, and the expensive thing is sometimes expensive for honest reasons.
The skill is not picking the clever tool over the boring one. It is knowing which problem you actually have — and being honest when the boring, expensive thing is doing work your weekend file quietly refuses to.
So the rule I have settled on: build the small fast thing for the small fast problem, and resist the urge to grow it into the thing you just escaped. The weekend rebuild is a scalpel, not a hospital. Used on the right small problem it is a quiet joy and saves you nine seconds a hundred times a day; used on the wrong large one it becomes the very system someone replaces in a weekend three years from now. If you are wondering why a surgeon is writing any of this at all, that argument lives next door in why surgeons should build.