A hundred free events a day, and I miss the best ones
The best things in Berlin happen 300 meters from my door, and I find out too late, or never. The choir concert in the courtyard of the library next door for Fête de la Musique, the tenants' advice session, the neighborhood cleanup day, the new street food market two streets over. Not the big festivals, everyone catches those, but the small, local things that quietly pass you by.
Not for lack of things to do. Berlin has around a hundred free events every day, the path to the information just costs too much. Anyone who wants to head out on a whim switches between event apps, Facebook groups and local blogs, compares, guesses distances, works through categories. The outcome is rarely a decision, it's decision fatigue. And that ends in "maybe later".
The starting question of the project: how do you design an app that reduces decisions, instead of just presenting them better?
Built for people in Berlin who want to head out on a whim without planning, myself included. A gap between two appointments, no lead time, no research, no signup. Three situations where it counts:
First a script for myself
I started pragmatically, because at first it was only meant for me: a Python script that scrapes the sources every day, filters by my categories, and emails me at midday. At some point I wanted it not just in my inbox but on the spot, out somewhere in Berlin, and realized it might be useful to others too.
The phone knows location and time, and the weather is one API call away. Those three are enough to assemble a sensible feed.
The feed
A vertical list of cards, sorted by walking distance. Each card shows the event name, category, walking time in minutes, and start time. Anything more than ten minutes on foot doesn't appear at all. When it rains, indoor events are prioritized automatically.
Data sources
The MVP pulls events from Berlin's cultural database (open API), berlin.de, radioeins, and gratis-in-berlin.de, and shows them based on GPS position or a predefined address. Location data stays on the device.
Tools and time
Concept and clickable prototype came together in one working day. Design in Figma, prototype in HTML/CSS.
What's still missing
The data is often messy, poorly structured, sometimes missing or wrong. A reliable aggregator would be a project of its own.
Most events have no images. That doesn't hurt here, the feed focuses on the essentials. Density matters more: there should be more events so every district shows at least one. In the inner city that works, in Zehlendorf it already gets thin.
For a small proof of concept, though, it's enough, and it works.
Frequently asked questions
Why is there no search bar?
Because search requires a decision: you have to know what you're looking for. The goal of this concept was the opposite. An app that makes relevant suggestions without the user having to search or filter actively. The context information the smartphone already has replaces the search bar.
How long did the project take?
The concept and clickable prototype were built in one working day. The Python script that served as a precursor solution had been built earlier. It was the actual starting point, even though I didn't see it that way at the time.
What tools were used?
Python for the initial scraping script and email automation, Figma for UI design and the interactive prototype, HTML and CSS for the clickable demo. The data comes from gratis-in-berlin.de and the Berlin cultural database.
Could the concept work in other cities?
In principle, yes. The concept is based on GPS, time, and weather, not on Berlin-specific data. It would need a reliable event data source for the respective city and user research into local behavior: what counts as walkable in Hamburg? How far are people in Munich willing to go spontaneously?
What would the next step towards a production-ready product be?
Three things: user tests across different Berlin neighborhoods with real spontaneous use cases, a clean data pipeline with a curated event source instead of scraping, and a decision on the business model. And probably an answer to the social question, because the actual barrier might be motivation, not information.