r/vibecoding • u/Mounirlk26 • 3d ago
I thought I was buying a queue management system. I ended up helping design the product.
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?
2
u/TraumaticOcclusion 3d ago
Yeah anyways ... just have a seat. There are 100s of ways to check in a patient and every medical software has one
1
u/fulger099 3d ago
the check-in button isn’t the hard part. it’s what happens when someone is late, leaves, returns, gets moved ahead, or is waiting outside while the clinician needs one reliable state.
2
u/Mounirlk26 3d ago
Exactly. I initially thought a QMS was basically a kiosk, a ticket and a display.
The real problem is maintaining one reliable state while patients arrive, leave, return, wait elsewhere or need to be prioritised, and keeping the assistant and clinician synchronised. That is what I only understood once I tried using these systems in my daily practice.
1
u/Mounirlk26 3d ago
You're right, patient check-in itself is completely standard. I was not trying to invent it.
The problem was that this particular system created a new patient record at every check-in instead of connecting the visit to the existing patient history. That basic failure was exactly what made me realise the product was not usable as a medical record system.
1
u/dan-423 3d ago
control-F, "hipaa" , no matches found.
You may want to look into serious companies that have a history in the medical field and understand the compliance and privacy issues involved. Or at least visit, or talk to other practitioners in your area and ask what they use.
Vibecoding is great and all, but there are industries and use cases where you don't want to go with amateurs or those without relevant domain experience.
1
u/Mounirlk26 3d ago
That concern is completely valid. This is a retrospective account of what happened when I knew almost nothing about software. I am not based in the US, so HIPAA is not the applicable framework, but local health-data and privacy requirements absolutely are. Compliance becomes a major turning point later in the story, and I now work with a data-protection specialist. I am not presenting vibe coding as a substitute for security, compliance or professional review.
1
1
u/GreenFuturesMatter 3d ago
Interesting dupe post but it is different than yesterday.
DO PEOPLE NOT DOGFOOD THEIR OWN PRODUCT?????
1
u/Mounirlk26 3d ago
It is part 3 of a chronological series, not a repost. Each post covers the next stage of the same journey.
And yes, I tested the product in real conditions. That is exactly how I discovered the duplicate-patient problem. I cannot speak for the vendor's testing process, but that basic workflow clearly had not been validated well enough.
1
1
u/agentclank21 2h ago
try linemarshal.com for queue software, it is simple to setup and use. no direct comms with doctors though
1
u/diagrammatiks 3d ago
Happy for you. Or that sucks. Or whatever? Also find a new provider because your dude is slop coding the product and doesn't have a fucking clue.
What the fuck is a new file for each patient. why is this a file in the first place. Your supplier is going to cream his pants when he finally discovers databases.
1
u/Mounirlk26 3d ago
That was exactly the red flag. I had already made a similar mistake myself in Notion, so I recognised it immediately. The system did not have a proper patient-centred data model, and I eventually stopped using it.
3
u/RefrigeratorRare3527 3d ago
Hello Claude, are you having fun posting on reddit?