I sat down next to a pharmacist and watched her work for the better part of an hour. Clinical research data, patient records, treatment schedules, follow-up dates, all of it living inside one enormous spreadsheet. She scrolled, filtered, copied, pasted, then scrolled again. Every single day. That afternoon is why I decided to build a custom CRM to replace Excel for the pharmacists on that team, and it turned into one of the most satisfying builds of my ten years in engineering.
The spreadsheet that ran a research team
Here is the thing nobody warns you about spreadsheets: they scale right up until the exact moment they don't, and then they fail quietly.
The file had hundreds of rows. Every patient, every treatment cycle, every scheduled follow-up sat in a grid that was never designed for any of it. The pharmacists had built an entire clinical research workflow on top of a tool meant for accounting.
Then one day I watched the thing that decided the whole project. She accidentally overwrote a colleague's row. Didn't notice. Nobody noticed for two days. Two days of clinical data, gone, because a cursor landed one cell too far and there was no undo, no history, no guardrail. In research, that is not an inconvenience. That is a real problem.
I looked at that spreadsheet and something in me went quiet. Not anger. Just a very clear thought: I can fix this.
I watched before I wrote a single line
Here is the mistake I almost made. I almost went home and started building what I assumed they needed.
Instead I stayed and kept watching. The workflow in my head turned out to be nothing like the workflow on their screen. Pharmacists don't think in components and API calls. They think in patients and deadlines. I had to unlearn my own vocabulary before I could build anything in theirs.
So I mapped what they actually did, not what a developer imagines a "CRM" should be:
- Patient records that never silently disappear
- Treatment tracking that updates for the whole team the instant one person changes it
- Follow-up scheduling that lives in the system, not in someone's memory
- Search and reports that answer a question in seconds instead of a scroll
Only after that did I open an editor.
The build: Vue.js and Firebase
The stack was deliberately boring, and that was the point.
- Vue.js on the frontend, for a fast, reactive interface the team could actually enjoy using.
- Firebase on the backend, with its real-time database doing the heavy lifting.
The real-time piece is what quietly killed the biggest problem. When one pharmacist updated a treatment record, everyone else saw it instantly. No more emailing the "latest version" of the file around. No more two people editing two copies and one of them winning by accident.
Underneath, it was all the unglamorous fundamentals: authentication, CRUD, search, reports. Nothing you would put on a conference slide. Everything the business actually needed.
The impact: 40% faster, zero lost records
The numbers came in fast once the spreadsheet was gone:
- Processing time dropped 40%. Not because the pharmacists suddenly got faster, but because the system stopped slowing them down.
- Around two hours a day of manual data entry disappeared.
- Zero lost records. The accidental-overwrite class of disaster simply stopped existing.
- The workflow went 100% digital. The spreadsheet didn't get improved. It disappeared.
That last line matters more than it looks. I didn't build a better spreadsheet. I replaced the process that made a spreadsheet feel necessary in the first place.
The difference between a developer and an engineer
Vue and Firebase were just tools. I could have used a dozen other stacks and landed in the same place. The actual work started when I sat down, shut up, and watched people struggle, then built something that made their day genuinely better.
If I had to compress the whole project into three rules:
- Talk to the users before you write a single line. Their real pain is never the pain you assume.
- Replace the process, not just the tool. A faster spreadsheet is still a spreadsheet.
- Measure impact in human time saved. Forty percent and two hours a day mean something to a person. Lines of code don't.
That, to me, is the line between a developer and an engineer. A developer ships the feature. An engineer changes how people work.
Somewhere right now, someone at your company is tracking something mission-critical in a spreadsheet. They're not complaining about it. They stopped complaining years ago and just accepted it. Find that person. Build that tool. You won't just be writing code. You'll be changing how they work.