Ich habe lange geglaubt, dass gutes UI und schnelle UX fast alles sind. Wenn die App hübsch ist, wenn sie sich flott anfühlt, wenn man sie in zwei Minuten versteht, dann kommen die Nutzer schon. Das war naiv. Der Nutzen war bei mir oft nicht sofort da, weil alles erst Sinn ergab, wenn schon ein Netzwerk da war. Ich habe Features gebaut, die bei großen Apps funktionieren, und gedacht, ich könnte das kopieren, ohne die Millionen Nutzer mitzunehmen. Das war falsch. Nicht theoretisch falsch. Praktisch falsch, an drei Projekten, an denen ich hängen geblieben bin, bis ich verstanden habe, woran es wirklich scheitert.
Illustration zum Cold-Start-Problem. Erstellt mit GPT Image.
SWIQ: Warum soll jemand die App installieren?
Bei SWIQ wollte ich Menschen helfen, Entscheidungen zu treffen. Welche Frisur? Welches Outfit? Welches Logo? Du erstellst eine Frage, andere stimmen ab. Klingt simpel. Technisch war es das auch irgendwann. Am Anfang aber habe ich es wie eine richtige Social App behandelt. Registrieren, Profil, in der App bleiben, Challenges entdecken. Ich war stolz auf das UI. Es war schnell, klar, modern. Und trotzdem bin ich an einer banalen Frage hängen geblieben, die ich zu spät gestellt habe: Warum soll sich jemand registrieren und einen ganzen Prozess mitmachen, nur um bei zehn oder dreißig Challenges abzustimmen? Das macht keinen Sinn. Nicht für den Nutzer, der nur eine schnelle Meinung abgeben will.
Jemanden anzusprechen und zu sagen „Probier mal meine App aus“ war ein Prozess. Es fühlte sich nicht cool an. Es fühlte sich an wie Bitte stellen. Und jedes Mal, wenn ich das gemacht habe, habe ich gespürt, dass ich nicht das Produkt verkaufe, sondern eine Hürde. Die Lösung war nicht noch ein Feature. Die Lösung war, die Hürde wegzunehmen. Anonymes Voting. Und vor allem: Voting im Web, ohne Install. Du bekommst einen Link, klickst, stimmst ab, fertig. Das hat für mich alles verändert. Plötzlich brauchte niemand mehr meine App, um mir einen Gefallen zu tun. Die Leute nutzten es, weil es für sie in dem Moment funktioniert hat. Nicht weil schon eine Community existierte.
Ballin: Zu komplex, um den Sinn zu erklären
Ballin war das Gegenteil von minimal. Ich habe eine komplett komplexe App gebaut, die ich selbst cool fand. Viele Ideen, viele Ecken, viel „das könnte man noch machen“. Und irgendwann saß ich da und konnte mir selbst nicht mehr in einem Satz erklären, wofür die App eigentlich da ist. Nicht so, dass es mir peinlich wäre. Sondern so, dass es ein Warnsignal war. Wenn ich als Builder den Kern nicht mehr klar formulieren kann, wie soll das ein neuer Nutzer tun?
Dazu kam Monetarisierung. Was soll was kosten? Warum sollte jemand zahlen? Ich hatte Antworten im Kopf, aber keine, die sich natürlich angefühlt hätten. Ballin hatte ein Shareable Object, die Spielerkarte. Theoretisch der richtige Gedanke: Sofort Wert, sofort teilbar. In der Praxis war ich zu sehr damit beschäftigt, die App groß zu machen, statt den einen Moment zu perfektionieren, in dem jemand sagt: „Die Karte will ich haben.“ Heute stelle ich mir bei jedem neuen Gedanken zuerst eine simple Frage: Was will ich eigentlich machen? Und wie kann der Nutzer das so schnell und so cool machen, dass er nicht erst überlegen muss, ob er mitmacht?
Fupla: 400 Nutzer, die nicht aktiv waren
Fupla war am nächsten an dem, was Andrew Chen beschreibt. Fußball spielen, Spieler finden, Gegner finden, Vereine, Camps, Plätze. Viele Seiten, viele Verbindungen, viel Potenzial. Ich habe zu viele Features gebaut, ohne klaren Fokus und ohne kleine lokale Community als Startpunkt. Tatsächlich hatte ich irgendwann rund 400 Nutzer. Das klingt auf dem Papier gut. In der Realität waren sie nicht aktiv. Die App war da, aber es passierte zu wenig. Ich habe Turniere zugelassen, ohne sie richtig zu promoten, ohne die richtigen Nutzer dafür zu haben. Wieder dieses Muster: Ich habe etwas gebaut, das funktionieren soll, wenn alle anderen schon mitspielen. Nicht etwas, das schon für eine Person Sinn ergibt.
Der Fokus auf „Ich suche Fußball“ kam nicht am ersten Tag. Der kam, nachdem ich gemerkt habe, dass Breite ohne Tiefe nichts bringt. Ein echtes Bedürfnis in einer Region. Ein konkretes Problem. Nicht ein soziales Netzwerk für alles und jeden, sondern eine Antwort auf eine Frage, die jemand heute hat.
Das Buch kam nach dem Scheitern
Ich lese das nicht, um klug zu klingen. Andrew Chens The Cold Start Problem habe ich gelesen, nachdem ich an mehreren Stellen schon gegen die Wand gelaufen bin. Viele Passagen habe ich mit einem mulmigen Gefühl gelesen, weil ich mich darin wiedererkannt habe. Netzwerk zuerst. Kritische Masse abwarten. Die Hoffnung, dass es irgendwann kippt, wenn genug Leute da sind. Das Buch hat mir Sprache gegeben für etwas, das ich schon gefühlt habe. Aber die eigentliche Lektion kam aus dem Bauen, nicht aus dem Lesen.
Eine Frage, die ich mir heute stelle
Früher habe ich gedacht: Netzwerk zuerst. App bauen, Features stapeln, Leute überzeugen mitzumachen, warten bis es lebt. Heute frage ich mich bei jedem Gedanken: Was bekommt Nutzer Nummer eins, ohne auf Nutzer Nummer zwei zu warten? Bei SWIQ war es die Abstimmung per Link. Bei Ballin wäre es die Karte gewesen, wenn ich nicht so viel drumherum gebaut hätte. Bei Fupla ist es die Suche nach einem Spiel, nicht die Vision eines kompletten Fußball-Ökosystems am Tag eins.
Das Cold-Start-Problem löst man nicht mit einem Trick. Es wird leichter, wenn man ehrlich bleibt und das Produkt so schneidet, dass es schon für eine Person funktioniert.
Für wen ich das schreibe
Ich schreibe das nicht als Erfolgsstory und auch nicht als Ratgeber mit der einen richtigen Antwort. Ich schreibe es für Leute, die gerade selbst bauen und merken, dass etwas nicht greift. Vielleicht hast du schon Nutzer, aber wenig Bewegung. Vielleicht erklärst du deine App dreimal und bekommst trotzdem nur höfliches Nicken. Vielleicht hast du ein UI, auf das du stolz bist, und trotzdem fragt sich niemand, warum er installieren sollte. Genau da war ich.
Wenn du an dem Punkt bist, kann es helfen zu hören, dass man das nicht allein so erlebt. Nicht weil es dann einfacher wird. Sondern weil man aufhört, sich einzureden, das Problem liege nur an Marketing oder Geduld. Manchmal liegt es am Produkt. Daran, dass der erste Nutzer noch leer ausgeht.
Warum ich das veröffentliche
Ich habe lange gebraucht, bis ich verstanden habe, dass gute Technik allein nicht reicht. Dass es kein Charakterfehler ist, wenn Leute deine App nicht sofort verstehen oder nicht sofort mitmachen wollen. Dass es normal ist, Features zu bauen, die erst Sinn ergeben, wenn schon alle da sind. Ich wünsche mir, dass jemand, der gerade mitten drin steckt, einen Text findet, der das benennt, ohne zu beschönigen und ohne zu predigen.
Die Apps existieren. Ballin, SWIQ und Fupla sind nicht begraben. Ich setze alle um, aber diesmal jeweils auf genau ein Problem. Nicht das große Netzwerk am Anfang, sondern der eine Moment, in dem Nutzer Nummer eins schon etwas hat. SWIQ und Fupla sind schon in den App Stores. Bei Fupla tüftle ich weiter am Fokus. Ballin steht noch in den Startlöchern. Was ich hier beschreibe, ist der Rückblick auf das, was schiefging. Was folgt, ist der Versuch, es anders zu machen.
Ich werde berichten, wie das läuft. Was ich baue, was ich streiche, was funktioniert und was wieder hängen bleibt. Nicht als Werbung, sondern als ehrliches Logbuch. Wenn du selbst baust, vielleicht hilft dir der eine oder andere Schritt. Wenn nicht, habe ich zumindest für mich festgehalten, woran ich mich erinnern will.