Where the teams started
Each team began with a specific problem. Before building anything, it had to decide who cared about that problem, why existing options fell short and which assumption about the audience or business model needed testing first.
The process
- 1
Define the problem and audience
The teams described a specific situation and checked who was affected by it.
- 2
Sketch the product and business model
They reduced the value proposition, core functions, market and possible revenue to the decisions that mattered.
- 3
Build a prototype
AI-assisted tools helped each team make a clickable version. Gaps became visible before anyone invested in complete software.
- 4
Present it and choose the next test
Each team showed its product and identified the assumption that now needed testing with real people.
Five directions, five testable ideas
The prototypes explored shared memories, media literacy, keeping clothes in use for longer, meeting people offline and making medical reports easier to understand. The subjects differed, but the working rhythm stayed the same.
Three prototypes from the sprint
The LMU Munich teams began with a specific everyday problem and made their idea tangible as a clickable prototype within two days. These short presentations show where each team had got to by the end of the sprint.
Sustainability and consumption
Second Chance
The app gives rarely worn clothes another chance. Users photograph an item and the AI suggests personalised outfits for different occasions. The aim is to rediscover what is already in the wardrobe rather than buying something new too quickly.
Social connection and local business
Stammtisch
Stammtisch brings people to a shared table rather than another chat. Cafés use quiet periods to host themed gatherings. AI-generated prompts help conversations get started, while recurring events are designed to turn encounters into relationships.
Health and clear communication
klaro
klaro explains medical reports in plain language, presents key values clearly and helps people prepare for their next appointment. The prototype also highlights where professional review, privacy and firm boundaries are essential when dealing with health data.
These applications are student prototypes created in a learning format. They are not finished products and do not replace professional advice on medical or other sensitive matters.
What other teams can use
The point is not to produce a perfect app in two days. It is to make an idea tangible early enough to spot contradictions and learn from real users.
Would you like to make a product idea tangible with your team? We can help you choose the right format.