The kiosks were already there. Nobody was using them.

The situation

The kiosks were already in the building. Patients walked past them to queue at the desk instead.

A private hospital group in Portugal had bought self-service check-in some time earlier, and adoption had never arrived. The hardware was fine. The software came from a supplier who was slow to change anything, so the system stayed as it was first delivered while the hospital’s actual processes moved on around it. Every gap between the two sent another patient back to the counter.

We came in as the replacement software supplier. The brief was not “build kiosks” — the kiosks existed. It was: make them worth using.

What made it hard

The handover was not a handover. The outgoing supplier was being replaced and had no reason to make that easy. There was no cooperative transfer of knowledge — we picked up a system we had not written, serving a hospital that could not pause while we learned it.

The requirements changed daily. Not weekly, and not through a change process. The client’s needs genuinely moved that fast, and a large share of what we built in any given week was obsolete by the end of it. That is a demoralising way to work if you treat each change as a failure of planning.

A patient was standing there. Check-in touches identity, appointments and payment, and all three answers live in hospital record systems built long before self-service was a consideration. Nothing could be rebuilt or paused. The kiosk had to ask those systems the right questions, fast, with someone waiting in front of the screen.

What I did

I was hands-on technical lead for a team of two junior developers, and worked directly with the hospital’s people rather than through a written brief — gathering requirements, turning them into the design, reviewing the code and coordinating releases.

Given how fast requirements moved, we ran close to extreme programming: short cycles, constant contact with the client, and no long-range detailed plan to be invalidated. The design followed from the same fact. We optimised the code for change rather than for the current specification — anticipating where variation would land, and keeping it readable enough that any of the three of us could pick up anyone else’s work.

Underneath, it was microservices in C# and .NET Core with a React front end, MySQL and Docker. REST APIs handled patient verification, appointment lookup and payment processing, integrating with the hospital’s existing databases and with the in-house ticket panel so the kiosks and the desk stayed in step.

The lesson I took, and would give any engineer walking into something similar: treat change as the normal condition, not the exception. The requirements are not going to settle. Build for that and a moving client is survivable; build for the spec you were handed and you will rewrite it anyway, in a worse mood.

What changed

Self-service check-in success rose by 50%, and the queue at the front office shortened with it.

The kiosks went live in 2018 and were still running when I last checked — around eight years of production service, on software written for requirements that were changing under us the whole time. That is the part I am most pleased with, because it is the part that was hardest to design for.

It also changed what the team was trusted with. Delivering this earned enough credibility that the hospital gave us the ticket-panel system next — the displays that call patients through from the tickets the kiosks issue. We built those too.

Why this still matters

Most of what I now do for clients has the same shape as this project, and almost none of it has the shape of a greenfield build.

You inherit something. The people who built it are gone, or unwilling. It has to keep running while you change it. And what the business needs from it will not hold still long enough for a specification to survive contact.

That is also, precisely, the position every European healthcare organisation is now in: by March 2029 the European Health Data Space requires patient records to move between providers and across borders — from systems built in a different decade, without breaking what already depends on them. It is the same job.