When we started the AI Strategy Lab, I already told my group member that I would be comfortable with building the prototype. With a bachelors degree in Information Science and a IT job in healthcare I already have some experience with software design, AI tools and vibe coding. What interested me most was connecting that experience and knowledge to the business side I wanted to develop through this masters programme. Developing an AI business case alongside teammates with business backgrounds helped me better understand how technology and business strategy connect.
My main responsibilities were developing the prototype, designing the experiment, and analysing failures and governance. We divided tasks based on our backgrounds, which worked well. My teammates brought business knowledge and ways of thinking that complemented my technical experience. I could translate our proposal into something tangible, while their contributions helped place it within a business model and competitive context. While this division felt natural, it also meant I had fewer opportunities to apply the business knowledge I was gaining during the course. I mostly contributed in an area I already felt comfortable with, even though developing a broader business perspective was one of my reasons for choosing this masters. In a future project, I would still use my technical experience, but also take more responsibility for the strategic or commercial analysis.
Choosing the idea was harder than I expected. Only later I realized that some ideas from my work could also have been interesting for this assignment. By then we already had chosen our topic, and some of those other ideas would have been difficult to develop within available time. During other groups’ presentation, I sometimes thought their business opportunities and ideas were very clever. Looking back, I might have spent more time brainstorming and drawing ideas from my work experience before committing. Despite that I still believe our idea was practical and addressed a recognizable problem.
Our proposal focused on the effort required to assemble a customised football trip, visiting multiple matches. Customers have to coordinate fixtures, travel, accommodation, and preferences before they know which combinations are feasible. Building the prototype made these dependencies concrete. I used vibe coding, and my previous experience helped me direct the development process and assess the output. Still, resource constraints were noticeable. Compared with the AI access available at job, my personal cheaper subscription offered less flexibility, and required more manual finetuning. This reminded me of the AI-dependency I already have unfortunately.
Using a local model for the prototype avoided paid API usage, but introduced limitations. One of the guest lecturers had encouraged us to try running local models and explore becoming less depended on AI providers. I was sure a commercial model would be able to handle conversations better, but I wanted to discover how far we could get with a local alternative. Since this was a proof of concept, it did not require production-level performance to demonstrate the workflow. Despite its limitations, the prototype showed the concept sufficiently to support initial testing.
Those limitations become apparent when the system misunderstood corrections, misinterpreted preferences, missed flexible dates or unnecessary repeated questions. One example of misinterpretation was that after telling the AI travel agent I wanted to go to Rome, it did not understand and made the connection to Italy. Eventually the choice was made to introduce structured preference updated and validation rules, separating natural language interpretation from logical feasibility checks. AI interpreted wishes, while application logic handled calculations and constraints. A stronger model would likely improve conversational reliability, but these safeguards would remain relevant. Task-technology fit therefore directly became a applied course concept in the design of this prototype.
Designing the experiment required me to think beyond whether the application worked. We compared manual and AI-assisted planning using the same task and information, measuring completion time alongside itinerary validity and perceived effort. Faster planning did not directly mean higher paid conversion or commercial profitability. The pilot suggested reduced planning friction, but its small sample and fictional supplier data restricted our conclusions.
Our collaboration generally ran smoothly. Clear, direct and fast communication meant that we sometimes skipped meeting when there was little need to discuss, while sill meeting at important moments. I really appreciate that flexibility in a collaboration. Unfortunately, we had received not received interim project feedback, and we would have appreciated it. Without it we had to judge whether we were moving in the right direction, which was difficult to gauge sometimes. Next time, I would seek more feedback along the way when it is possible.
The biggest lesson I will carry forward is to establish business value first and choose a solution and technology afterwards. My background makes building something an attractive starting point, particularly when AI tools make development and experimentation easy. The project made me pay more attention to whether a solution actually improves the process and how we could test that. Especially given the current AI hype, it is a good takeaway to be clear about a problem before building, and to avoid making a solution more complicated than it needs to be.
