Two perspectives on our internal hackathon at the Schaltzeit team.
That's a question we kept asking ourselves at Schaltzeit, so we put it to the test: an internal hackathon where every team member builds something, regardless of their technical background or area of work. What surprised us: the differing levels of IT knowledge weren't the obstacle – they were the engine for new solution ideas. In this post, two voices from our team, Lucas (concept, facilitation, and vibecoding expert) and Fenja (no IT background), share how that turned into real prototypes, and what we took away from it for designing hackathons more broadly.
Why a hackathon and why this way?
Lucas – Concept, facilitation & participant
The idea: we take a full day as a team, form pairs, and solve real, internal problems – using digital tools. No theoretical exercise, no external use case. Just the kind of challenges we all know: the file management that nobody really understands. The content planning that lives across three different tools. The task tracking that creates more work than it saves.
We're a team that's half software and web development – and half futures research, design, and business administration. We work together every day, but often in parallel worlds. One group builds tools, the other uses them. Or doesn't. In between, there's sometimes a translation gap that's bigger than you'd think. The hackathon was meant to open up exactly that space in between – not as a team-building event with sticky notes and pizza, but as collaborative work on concrete solutions.
The focus was on vibecoding: the ability to build digital prototypes with the help of AI-powered tools, even without deep programming knowledge. We wanted to understand what that actually changes in practice. We wanted to bring together the different ways of working with AI that already exist within the team. And we wanted to develop prototype solutions that we could genuinely pursue further internally.
The format: two stages instead of one sprint
Even before the hackathon itself, we'd gathered internal problems and challenges in a team meeting – a shared problem pool that the teams could later draw from. We then split the hackathon itself into two half-days, several weeks apart.
The first half-day was about forming teams, picking a problem from the pool, and really getting to the bottom of it. Each team documented its path to a solution sketch in writing – from the current state and the requirements through to the proposed approach. The day ended with a short presentation of all the solution sketches to the team, and a first phase in which the teams could make an initial start on their ideas.
In the weeks between the two stages, the teams had the chance to keep building on their prototypes. The second half-day was deliberately designed as the closing stage: finishing the prototypes, presenting and testing them within the team. And above all: having the conversation about the tools used and the path to the prototype – so we could learn together from our experiences with AI and with the process itself.
In the thick of it, not just along for the ride
I'd designed the hackathon, put the teams together, and facilitated the day –but I also deliberately took part in a group myself. A balancing act: as a facilitator, you watch the clock and the energy in the room. As a participant, you want to dive into your own problem.
What surprised me most from that dual role: before a single line of code was written, every team first wrestled with understanding the problem. What exactly is the problem? What would a good state look like? What assumptions are baked into the current solution? Making that implicit knowledge visible was, in hindsight, the most productive moment of the first day and the precondition for AI being able to help in any meaningful way at all.
Will every prototype be carried forward in the end? That will become clear after the second hackathon day. But the space for thinking that opened up — around the question of how we, as a diverse team, develop digital solutions together — that's here to stay.
I'm not a developer. And I still built something.
Fenja – The non-IT perspective
I'm not a developer. And I never would have imagined that by the end of the first hackathon day I'd have helped build a prototype — one that's actually already running.
My colleague Tim and I took on a problem many people will recognise: recurring tasks for which a new timeline gets built from scratch every single time – even though the pattern is always the same. Before we'd even started building, we tried to describe the problem as precisely as we could: current state, target state, trigger, frequency, constraints.
That was the first challenge in itself. We both know the problem and the room to optimise it – but it's surprisingly hard to describe the whole thing concretely and without a lot of waffle. In hindsight, that very understanding of the problem was the foundation for the application we're still tinkering with now.
Because that's exactly what the AI needed in order to take us somewhere useful. It suggested approaches I wouldn't even have known existed. Programming languages I don't speak. Decisions that Tim could weigh up and make – and then explained to me. Together, we kept developing the application: more user-friendly, with more logic, with editable settings. And the longer we work on it, the more little things crop up that we want to improve. We'll make the UI pretty right at the very end.
What surprised me: by the end of the first day, a first prototype was running. Plenty of bugs and things to adjust, sure – but it ran. Without my having written a single line of code. That changes something about how I think about technical feasibility — and about what cross-functional collaboration really means.
What makes a good hackathon
What this day showed us: a hackathon doesn't just live off its format, but off the preparation behind it. The right teams, a well-researched collection of problems, the right setting for AI-supported work – that's what determines whether you end up with real prototypes or just a post-it graveyard.
Just as crucial is the setting during the hackathon itself: not only whether the technology is accessible to technical and non-technical team members alike, but also whether there's enough room for thoughtful discussion in small groups. Because some of the most productive moments for us weren't technical ones. They were the moments when teams stopped building – and started clarifying.
This is exactly the kind of thing we love designing for other teams, too. We take a close look with you beforehand at which problems are well suited to a hackathon. We design your format, one that brings technical and non-technical perspectives together to work out solution ideas. And we evaluate the results together. In short: we design, facilitate, and accompany hackathons that fit you.
Get in touch!
