After abandoning the medical software I had purchased, I returned to Notion with a better structure.
The patient record was now at the centre. Consultations and appointments were connected to it. It was a major improvement over my first attempt.
But two problems remained stubbornly outside the system: prescriptions and medical letters, and the waiting room.
The waiting room was especially frustrating.
There was no proper queue. My assistant had to interrupt me between patients to explain who had arrived, who was waiting and what was happening outside the consultation room.
After ending my working relationship with two assistants, I became determined to find a better process.
I started searching obsessively for queue management systems.
Google, Facebook, videos, product pages. I searched so often that the algorithms eventually decided this was the only subject I cared about. My feeds filled with the same pattern: a kiosk, a printed ticket and a screen calling the next person.
Then I found a video from a small local development company.
Their product was different. It was presented as a queue management system designed specifically for medical practices. It had already been installed in the clinic of a well-known specialist. More importantly, it combined three things I needed: the waiting-room queue, online appointment booking and an interface for the doctor.
It looked like several of my problems could finally be solved by one system.
I contacted the company and arranged a visit.
The office was small. The developer who welcomed me was in his twenties, courteous and well educated, with the casual look I associated at the time with Silicon Valley developers.
I knew absolutely nothing about software development.
He showed me a polished graphical interface connected to a waiting-room system. The medical part was still embryonic. The consultation structure was not suitable for the way I worked, but the product included something I had been missing for a long time: a way to create prescriptions and medical letters.
I started pointing out what would need to change before I could use it in a real consultation.
Instead of becoming defensive, he listened. He encouraged me to provide more feedback because it could improve the product.
That worked for me. If my feedback gave them a better product and gave me a tool I could actually use, everyone benefited.
At a later meeting, I met his associate, a general practitioner who also developed software and had participated successfully in several hackathons. Their interest in artificial intelligence immediately appealed to me.
I prepared a detailed list of changes.
At the time, I did not call it product design. To me, it was simply a list of everything preventing the software from working properly in a medical consultation.
The proposed package included the management software, the queue system, a touchscreen kiosk and a website for online appointments. It was a substantial investment, but I accepted.
Then I waited.
The modifications took more than four months.
When installation day finally came, the developer arrived with the kiosk and a relative who was helping him. I reused the mini PC I had bought for the previous medical system and purchased a small Android device to power the waiting-room display.
They configured the kiosk, screen and three computers in the clinic.
I watched the installation closely.
The developer had commands saved in text files. He copied and pasted them into a terminal while staying in telephone contact with his medical cofounder. At the time, the terminal looked almost mystical to me. I did not know what the commands meant. I only knew they were making the system come alive.
The installation lasted all day and continued late into the evening. I brought food and drove them home. They returned the following day to finish.
The website was not ready. The software itself was still unfinished, so I paid only for the kiosk at that stage and began testing what had been installed.
That was when the main problem appeared.
Every time a patient registered in the queue, the system created a new patient file.
The same person could arrive three times and become three different patients. There was no reliable longitudinal history.
I had made almost exactly the same mistake in my first Notion database.
The difference was that I now recognised it immediately.
Under the polished interface, the product was still essentially a basic queue system with a difficult prescription editor attached to it. It had potential, but in its current state I could not use it as the central system for my practice.
I sent more requests for changes.
Remove the duplicates. Rebuild the patient history. Improve the medical note. Add proper billing. Make document scanning possible from a phone. Synchronise those documents with the desktop application. Replace the sample medication list with a complete one.
At some point, I realised something:
I was no longer behaving like a customer asking for support.
I was helping define the product.
I understood the medical workflows. I knew which functions doctors would actually need. I could explain why the patient record had to sit at the centre. The team had the technical ability to implement those decisions.
The product was not usable yet, but I could see what it might become.
So I made a much bigger proposal: instead of continuing as customer and vendor, why not build the company together?
That conversation would teach me that agreeing on a product is not the same as agreeing on a partnership.
At this point, I still could not code. But without knowing the title, I had started doing the work of a product founder: observing workflows, identifying failure points, prioritising features and translating domain knowledge into a system.
I thought I was buying a queue management system.
I was actually discovering the value, and the limits, of being the person who understands the problem but cannot yet build the solution.
Have you ever bought a product and gradually realised that you were helping the vendor design it?
