Working along my studies has taken me to a wide range of business conferences, from the ones related to the tech and AI to ones related to media and marketing. Whatever the topic you could always find me at the start up peach stands. On our Demo Day, I was finally on the other side. I had to explain our idea, demonstrate the prototype I had built, and make its value clear before the next group arrived. That was a satisfying finish of a project, that taught me what it really means to build a useful AI application.
EventKlaar started with a teammate’s frustration. While organizing events, they had seen how an incomplete permit application in Rotterdam can set off a loop of repeated questions between organizers, municipal staff and advisory services, often because information was missing or contradictory. That experience gave us a concrete problem to build around. We developed an AI assistant that checks application documents and produces a gap report for municipal permit workers, who verify the findings and send organizers one consolidated list of what is still missing.
I volunteered to build the whole prototype because I had faced a similar challenge before. During my bachelor’s entrepreneurship semester, I had to implement a technology inside the workflow of a real organization, and that project gave me hands-on experience with vibe coding, connecting AI models through APIs and developing applications with Claude Code. I also took responsibility for designing and conducting the evaluation and analysing failures. As the prototype took shape, my teammates raised doubts about the economics and governance of the application, and I contributed my own input on both, alongside my work on the introduction and recommendations.
Before I could build anything, however, we needed to agree on who would actually use it. Our proposal, early drafts and Business Model Canvas pointed in different directions: an applicant pre-check, an interactive checklist, and assistance for municipal staff. These differences became difficult to ignore when I tried to translate the idea into an application.
I researched the permit process more closely and mapped where our tool could intervene. Personally, I initially preferred helping applicants correct their documents before submission. However, parts of the team’s work already focused on municipal staff. Through discussion, we settled on a staff assistant at intake. I came to see why this made sense: the municipality would pay for the tool, and its own workers would be the ones saving time with it.
That decision changed how I understood collaboration. My technical role depended on choices we needed to make together. Equally, building the prototype raised questions that affected everyone else’s work. Explaining API use, costs and data handling to teammates helped connect the application to their analysis. I learned to make assumptions explicit early, because different interpretations become much harder to resolve once they have turned into separate deliverables.
With the workflow clarified, I used Claude Code in Antigravity to build the prototype, drawing on my own coding experience. Under time pressure, I attempted a broad autonomous build instead of developing each component separately. It produced a starting point, but getting the application online and making sure its data persisted required more troubleshooting than I expected. A working local demo still needed deployment, storage and reliable connections before I could share it with my team mates, the grader and the audience during the demo day.
I also made an avoidable sequencing mistake. I began doing the evaluation with an Anthropic model before confirming that I can easily connect it to the application. When I moved to OpenAI’s API, I had to repeat the evaluation. Next time, I would validate the full connection first, then freeze the setup before conducting the tests. I would also build in smaller stages, so problems are easier to isolate.
The working prototype is the contribution I’m most proud of, because it turned our proposal into something we could actually test. It was a staff dashboard where a municipality worker opens an incoming event dossier, runs an AI check against 41 permit rules, and gets a gap report of findings to confirm or dismiss before contacting the organizer. A built-in checklist-only mode let us compare the AI against a simpler baseline on the same fictional dossiers. That let us demonstrate the core review task live without claiming an integration with Rotterdam’s systems that didn’t exist.
Evaluation was my biggest learning gap. I had few business analytics courses, but had never designed a test of an AI application. I needed to decide what success meant, which comparison was fair, and what result would make us reconsider the solution.
Testing the prototype changed how I judged my own work. The AI performed well overall, but it still missed an important issue and sometimes produced different findings when checking the same application. After putting so much effort into building it, I had to step back and assess what those weaknesses meant. Getting the application to work was satisfying; deciding whether its performance justified taking it further required a different kind of judgment.
This shaped our recommendation to improve the tool before moving to a pilot. I learned that a strong overall result can hide a weakness that matters more than the average suggests. Designing the evaluation also made me define what “good enough” meant before seeing the results, which helped me judge the prototype more critically despite being proud of what I had built.
Before this project, I associated AI business value mainly with model capability. I now pay much more attention to where a tool sits in a workflow, who benefits, and what evidence supports the claimed improvement. Our decision to deliver one report at intake, with a permit worker verifying it, showed me what the course means by combining AI with workflow redesign: the value came from changing how people work with the output, not from the model alone. That is the lesson I will carry into my future projects.
