ESN Event Hub: six tools, one event and why we built it boring
For the Erasmus Student Network in Potsdam we mapped the event process, modelled it and shipped a small web app as a team. Understand first, then build.
Trello, WhatsApp, Pretix, Instagram, Drive and email. The Erasmus Student Network in Potsdam runs about 80 events per semester across those six tools. All volunteers, no budget, and the team keeps changing.
That was our partner in the course Foundations of Enterprise Applications. There were five of us. The task: understand the process, find the weak spots, come up with a concept and build a prototype that a volunteer organisation without money can actually run.
We didn’t start with code. We started with conversations. Five interviews with people in very different roles, from the board to someone who only comes to the events as an Erasmus student, plus watching how things work day to day. I ran one of the interviews myself, in English. From that came a BPMN model of the current process with its own lane for each role, 27 tasks and 12 decision points. Then a list of 15 pain points and 10 strengths.
The most important pain point wasn’t technical. Every role only sees its own slice of the process, spread across the six tools. Nobody sees an event as a whole. And when someone leaves, their knowledge leaves with them.
So our concept was: one event, one shared view of the process. The event is the single source of truth, and every role gets its own view of it. Trello goes, WhatsApp, Pretix and Instagram stay because they work. Before that we ran a market analysis of what could be bought off the shelf.
The team shipped the prototype, and the demo on this page replays it with sample data. A board where an event moves from idea to planning, published, live and done. A public sign-up page without login: once capacity is full, you land on the waitlist. And an event log with the “Process Pulse”. It shows lead times and bottlenecks and checks whether a real event ran the way the target process says it should. Process mining, small size.
Process Pulse BPM · Monitoring
Every metric is computed live from the Activity event log, the trace data the app records itself.
Mined from the event log: the path events actually took, against the TO-BE happy path. Dashed arcs are deviations.
Process Pulse computes from the event log how events really run and checks them against the designed to-be process (BPMN).
Everything is stored in a Google Sheet. Sounds like a stopgap. It’s on purpose. ESN owns the sheet, running it costs zero euros, and hosting is on Vercel. AI agents, automated emails, gamification: we left all of that out on purpose because the client can’t carry running costs. “We chose boring on purpose” was on one of the final slides.
About the code: the commits in the repo are all Robert’s. I contributed the groundwork of the app, and we designed the system together. My most visible part was the presentations. In the interim presentation I did the closing part: what works well, the core pain point, the direction of the solution and what we had learned, including that BPMN was not decoration for us. In the final presentation I did the first six slides, from six systems to one event record.
What I’m taking away: understand first, then build. The core pain point came from the interviews, not from a feature list. Process and data belong together. And sometimes the right architecture is a spreadsheet.
Tools and skills: stakeholder interviews, BPMN with bpmn.io, prioritising pain points, build-vs-buy analysis, Next.js, the Google Sheets API, Vercel, and presenting to a real partner.
Note added later: the module grade is a 1.3.