This was my first hackathon. Four days later, our TeamViewer team won gold at the Microsoft EMEA Builders Hackathon in Copenhagen. The prototype mattered, but the process around it made the result possible.
Understand the rules you are being scored against. Then optimize for them.
Start with the rules
Before we decided what to build, we asked how the event worked. We wanted to know what the judges would score, what evidence they expected, who would be in the audience, and how much time we had.
The criteria covered innovation, technical ambition, customer and business impact, scalability, and feasibility. Teamwork, creativity, and storytelling could also add value. This gave us a filter for every decision. If something did not help the prototype, the business case, or the pitch, it was less important.
Build the right team
We had different strengths. I focused on the Azure integrations. Clemens and Jakob brought AI experience. Marcel knew the TeamViewer client and its security model in detail. This mix let us build the Microsoft integration, connect it to a small version of TIA, and check whether the idea was technically realistic.
Good teamwork also kept us moving when the days became long. Everyone shared responsibility for the prototype and the pitch.
Use the help around you
Microsoft product specialists and partner coaches were available throughout the event. We asked them specific questions, tested our assumptions, and used their feedback. They either helped us directly or connected us with the right specialist.
Very few teams seemed to use this support. For us, it made the prototype easier to build and the story easier to explain. Ask for help early, while there is still time to use the answer.
Make the value clear
Our idea was TeamViewer QuickFix. A user could ask Microsoft 365 Copilot for help with a device problem. TeamViewer and TIA would identify the device, propose a fix, ask for approval, and report the result.
The key was TeamViewer’s distribution. TeamViewer is already present on many types of devices. When we combined that reach with remote access and AI troubleshooting, people understood why TeamViewer was in a strong position to build this.
Turn 30 minutes into three
Our first explanations took about 30 minutes. The final pitch gave us three. We had to make the problem and the result clear before we explained the technology.
We used a familiar story:
- PowerPoint would not open just before my presentation.
- I asked Copilot for help by voice.
- The demo fixed the problem, and I could start the presentation.
Only after the audience saw the result did we explain what happened. This made it easier to talk about the wider value: faster help for employees, less routine work for IT support, and less downtime for companies.
Test the full situation
We did not only test the software. We tested the full pitch on the real stage. We checked the slides, the voice input, the audio, the timing, the handover, and every transition. We also simulated the things that could fail.
We ran the pitch about 30 times. On the day before the presentation, we spent more than 16 hours on the final version. Each run removed one unclear sentence, one risky step, or one small delay.
The last runs felt repetitive. That was the point. By the time we went on stage, the pitch was simple, familiar, and reliable.
What I would do again
Know the requirements first. Build for the real scoring criteria. Ask experts for help. Show a problem people understand. Test the full pitch where it will happen. Then repeat it until the team can handle mistakes without losing the story.
That process helped us turn a first hackathon into a gold award. Videos from the rehearsals are available on request.