Der Ausgangspunkt für die Entwicklung war die Beobachtung eines verbreiteten Orientierungsproblems: Viele Menschen können in ihrer eigenen Stadt nur grob sagen, wo sie schon waren, aber nicht systematisch, welche Viertel oder Ecken sie noch nie gesehen haben. Dieses Problem habe ich in verschiedenen Städten (Stuttgart, Köln, Hamburg) identifiziert.

A. Problemdefinition und Zielsetzung

Das Kernproblem lautet: Wie kann ich Menschen helfen, sichtbar zu machen, welche Teile einer Stadt sie schon entdeckt haben – und sie spielerisch motivieren, neue Ecken zu erkunden?

Meine Zielgruppe sind primär neugierige Menschen zwischen ca. 20 und 30 Jahren, die oft neu in einer Stadt sind, viel unterwegs und offen für Gamification.

B. Die Produktidee: Fog-of-War für reale Städte

Die Lösungsidee war eine App, die Stadtentdeckung gamifiziert – inspiriert von Videospiel-Mechaniken: Eine Karte, die anfangs von einem „Nebel“ (Fog of War) bedeckt ist und Stück für Stück dort aufgedeckt wird, wo sich der Nutzer bewegt.

Dies liefert ein sofortiges, visuelles Feedback und dient als spielerische Motivation. Langfristig soll die App als skalierbare Plattform für Stadtentdeckung dienen und monetarisiert werden können.

A. Agiles Vorgehen (Scrum-Ansatz)

Um die technische und funktionale Komplexität (Tracking, Karte, Backend, Gamification) kontrollierbar zu machen, bin ich bewusst in einem Scrum-ähnlichen Vorgehen vorgegangen:

• Einrichtung eines Backlogs in Jira und Strukturierung in Epics (z. B. Tracking & Fog-of-War, Kartenlogik, Social Layer).
• Arbeit in Sprints mit klaren Sprint-Zielen und einem lauffähigen Inkrement am Ende, das direkt getestet wurde.
• Bewusstes Einlegen von Refactoring-Sprints, um die Code-Struktur und Dokumentation zu verbessern, was die Wartbarkeit und Skalierbarkeit von Beginn an sicherte.

B. UX, Marktanalyse & Designentscheidungen

Vor dem Coding wurde die Idee durch Mockups und UX-Recherche geschärft. Der Leitgedanke war, bekannte UI-Muster (z. B. von Instagram, Google Maps) zu übernehmen, um die Einstiegshürde gering zu halten.

Die frühe Validierung im Umfeld bestätigte das Orientierungsproblem und die intuitive Motivation durch den „Fog-of-War“-Ansatz.

A. Cross-Platform & Technologie-Stack

Zur Erreichung von Android und iOS wurde Flutter gewählt, um eine einzige Code-Basis zu nutzen. Dies minimierte den Entwicklungs- und Wartungsaufwand. Das Backend basiert auf Firebase (Firestore/Authentication) wegen der nahtlosen Integration in Flutter und der Skalierbarkeit.

B. Architektur: Stadtlogik und Daten

Für die Kartenvisualisierung wurde Mapbox gewählt. Die Geodaten stammen aus OpenStreetMap. Strategisch wurde die Welt in drei hierarchische Ebenen unterteilt (Stadt → Bezirk → Viertel), um:

• Demotivierung durch zu große Gesamtziele zu vermeiden.
• Kurz- und mittelfristige, erreichbare Erfolge zu ermöglichen.

Der Code ist modular aufgebaut, sodass die gesamte Logik einmal implementiert wurde und neue Städte relativ schnell durch spezifische Datendateien hinzugefügt werden können.

C. Umgang mit technischen Hürden (Pragmatismus)

Als der Emulator aufgrund wachsender Komplexität unzuverlässig wurde, traf ich eine pragmatische Entscheidung: Statt Zeit in die Fehlersuche im Emulator-Setup zu investieren, wurde ein physisches Android-Smartphone für die direkte Entwicklung und das Testen erworben. Dies beschleunigte die Zyklen und ermöglichte realistischere Performance-Tests.

D. Zentrale App-Screens

Parallel zur Architektur habe ich die wichtigsten Screens iterativ entwickelt – vom Einstieg bis zur eigentlichen Stadtentdeckung.

A. Aktueller Stand und nächste Schritte

Die App befindet sich aktuell in einer Beta-Phase, in der eine kleine Gruppe von Nutzern die Funktionalität (Tracking, Nebel-Mechanik, POI-System) im Alltag testet. Parallel dazu wird die Code-Qualität weiter professionalisiert, u.a. durch die Hinzuziehung externer Programmierunterstützung zur Stabilisierung und Skalierung der Architektur für die nächsten Features (z. B. Social Layer).

B. Prototyp-Evolution

Die App ist über mehrere Prototypen hinweg entstanden. Die folgenden Videos zeigen die Entwicklung von einer frühen Version hin zu einem deutlich gereifteren Produkt.

C. Monetarisierungsideen

Um das Projekt wirtschaftlich zu machen, wurden frühzeitig Einnahmequellen ohne störende Werbung konzipiert: Freischaltmodelle für weitere Städte und der Verkauf kosmetischer Elemente (Skins, Themes) als In-App-Käufe.

D. Persönliche Learnings

Die Arbeit an der App hat meine analytische und strukturierte Arbeitsweise nachhaltig geschärft. Meine wichtigsten Takeaways sind:

• Ich denke Produkte konsequent vom Problem und vom Nutzer her – und nicht vom Feature.
• Ich nutze strukturierte Methoden (Scrum-Ansatz, Jira) in jedem Projekt.
• Ich treffe bewusste Tech- und Architekturentscheidungen und arbeite iterativ.
• Ich bin bereit, pragmatische Entscheidungen zu treffen, um Fortschritte zu erzielen.

Dies sind die Schlüsselprinzipien, die ich aus diesem Entwicklungsprojekt für meine zukünftigen Tech-Projekte mitnehme.