TL;DR

Ich baute CalendarGenie für Konzertplakate. Meine ersten Beta-Tester hatten andere Pläne: Konferenzprogramme, Stundenpläne, Arztbriefe, Reisepläne. Eine Maklerin nutzte es für Team-Besichtigungspläne. Wichtigstes Produktprinzip: Nicht du definierst den Use Case – deine Nutzer tun es.

Der Plan – und die Realität

Ich baute CalendarGenie für einen einzigen Use Case: Konzertplakate. Klar, fokussiert, einfach. Meine ersten Beta-Tester hatten andere Pläne.

Was die Beta-Tester wirklich hochluden

Innerhalb weniger Wochen luden meine bevorzugten Beta-Kunden Dinge hoch, die ich mir nie vorgestellt hatte:

  • 📋 Konferenzprogramme mit 40+ Sessions
  • 🏫 Schulstundenpläne für das ganze Semester
  • 🏥 Arztbriefe mit Terminen
  • ✈️ Reiserouten aus Buchungsbestätigungen
  • 🎭 Saisonprogramme von Theatern
  • 📅 Gym-Kursübersichten

Ein Beta-Tester lud ein Foto eines handgeschriebenen Post-its hoch. Es funktionierte. Ein anderer lud einen WhatsApp-Screenshot mit Terminen hoch. Auch das funktionierte.

Die überraschendste Nutzerin

Eine Maklerin lud Besichtigungspläne für ihr gesamtes Team hoch. Sie wurde zu meiner engagiertesten Beta-Kundin. Das hatte ich nie geplant – aber aus ihrer Sicht macht es vollkommen Sinn: Ihr Job ist schnelle Terminkoordination. Und genau das macht CalendarGenie.

Was jeder Use Case lehrte

Jeder neue Use Case bedeutete neue Learnings für die Entwicklung:

  • Festival-Pläne → Mehrtägige Event-Verarbeitung
  • Arztbriefe → Wiederkehrende Termine
  • Konferenzprogramme → Zeitzonen-Bewusstsein

Professionalisieren oder Nebenprojekt?

An einem Punkt stellte sich die Frage: Weiter professionalisieren – oder als Nebenprojekt halten? Ich entschied mich für das Letztere. Diese Entscheidung hat mich befreit: Ich konnte weiter experimentieren und lernen, ohne den Druck eines Skalierungs-Ziels. Manchmal ist das die richtige Entscheidung.

Das Muster wiederholt sich

Post-er, mein Content-Tool, folgte demselben Muster. Ich baute es für LinkedIn-Posts. Beta-Tester begannen es für Instagram-Carousels, Blog-Entwürfe und E-Mail-Newsletter zu nutzen.

Das Muster ist immer dasselbe: Du baust für A, Nutzer entdecken B bis Z. Ship it. Beobachte was passiert. Iteriere basierend auf echtem Feedback – nicht auf deinen Annahmen.

Dieser Beitrag ist Teil meiner Serie über Vibe-Coding und das Bauen von Apps ohne klassische Programmierkenntnisse. Alle Artikel in der Serie →