KickerTUM

The problem

Munich has a lot of foosball tables and a lot of people who want to play on them, and no way to connect the two. Finding a free table meant walking to it, and finding an opponent of roughly your level meant already knowing them. Games got played, but nobody could say who was actually any good.

What we built

A web platform for foosball players built on the MERN stack, with three pieces that reinforce each other:

• Table Finder — where the tables are and whether they are in use.
• Matchmaking — pairing players looking for a game.
• Tournaments and ranking — a tournament system on top of an ELO-based rating, so results from casual games and organised brackets feed one ladder.

The ELO ranking is what ties it together: it gives matchmaking something to match on, and it gives casual games a reason to be recorded.

What I took from it

This was the project where the data model mattered more than the framework. Rating systems are unforgiving of loose modelling — a match has to be an immutable, ordered fact, because a rating is a fold over history rather than a column you update. Getting that wrong early would have meant a ladder nobody trusted, and trust was the entire product. Ownership here was E2E, meaning that a feature was implemented from Frontend to Backend, as well as the data model to support it. This approach led to a lot of learnings on whats important for a system to work smoothly from start to finish.