{"id":7681,"date":"2025-11-24T09:54:16","date_gmt":"2025-11-24T08:54:16","guid":{"rendered":"https:\/\/blog.bart.sk\/en\/?p=7681"},"modified":"2026-01-08T12:40:21","modified_gmt":"2026-01-08T11:40:21","slug":"from-prototype-to-product-testing-ai-in-clinic-kiosk-development","status":"publish","type":"post","link":"https:\/\/blog.bart.sk\/en\/from-prototype-to-product-testing-ai-in-clinic-kiosk-development\/","title":{"rendered":"From Prototype to Product: Testing AI in Clinic Kiosk Development"},"content":{"rendered":"\n

When building a new digital product, the most important goal is usually the same \u2014 get to a functional prototype as quickly as possible. That\u2019s the moment when we learn whether an idea works outside of documentation and whether it\u2019s worth investing in further development. It\u2019s not just about speed, but about reducing the risk of heading in the wrong direction early on.<\/strong><\/p>\n\n\n\n

For our clinic kiosk application, we decided to internally compare three different ways of building a prototype. We wanted to see how speed and quality would differ when using AI-only, a traditional workflow with no AI, and a hybrid approach where a developer works hand-in-hand with AI.<\/p>\n\n\n\n

This experiment allowed us to look at the same task from three perspectives and evaluate which method makes the most sense for similar projects. Since the client only pays for the solution that goes to production, we were free to explore all approaches without increasing their budget.<\/p>\n\n\n\n

I was part of the team testing the developer + AI workflow. And while I had certain expectations, some results were far more surprising than I anticipated.<\/p>\n\n\n\n

The brief: a self-check-in kiosk for clinics<\/strong><\/h2>\n\n\n\n

The project had a clear goal: build a touch-friendly kiosk application for clinics that allows patients to quickly and intuitively confirm their arrival \u2014 without waiting at the reception desk. Key requirements included:<\/p>\n\n\n\n