Ich habe lange gedacht, „einfach“ heißt sauberes UI und weniger Bugs. Wenn das Layout stimmt und die App sich schnell anfühlt, war ich zufrieden. Das war falsch, aber auf eine subtile Art. Einfach ist nicht das, was ich als Builder sehe. Einfach ist das, was jemand in den ersten Sekunden versteht. Und dahin kommt man selten mit noch einem Polish-Pass. Man kommt dahin, indem man Dinge entfernt, die man schon gebaut hat. Dinge, auf die man stolz war. Dinge, die sich nach Fortschritt angefühlt haben.
Illustration zum Wegschneiden auf eine einfache Lösung. Erstellt mit GPT Image.
Einfach sieht von außen leicht aus
Wenn du ein Produkt anschaust, das sich selbstverständlich anfühlt, siehst du nicht die Versionen davor. Du siehst nicht die Features, die gestrichen wurden. Nicht die Screens, die gelöscht wurden. Nicht die Ideen, die im Kopf brillant klangen und in der Praxis nur Lärm waren. Du siehst das Ergebnis und denkst: klar, so muss das funktionieren. Warum sollte jemand das anders bauen?
Genau da liegt die Falle. Einfach wirkt wie weniger Arbeit. In Wahrheit sind es mehr Entscheidungen. Jedes Mal, wenn du Ja zu einem Feature sagst, sagst du Nein zu Klarheit. Hinzufügen fühlt sich produktiv an. Wegschneiden fühlt sich an wie rückwärts. Meistens ist Wegschneiden aber die eigentliche Produktarbeit.
Das habe ich an drei Apps gelernt, die mir noch wichtig sind. Nicht in einem Workshop. Sondern indem ich zu viel gebaut habe, zu viel erklärt habe und gesehen habe, wie Leute höflich nicken und dann aufhören.
SWIQ: Der Link war das Produkt
Bei SWIQ wollte ich Menschen helfen, Entscheidungen zu treffen. Welche Frisur? Welches Outfit? Welches Logo? Du erstellst eine Frage, andere stimmen ab. Auf dem Papier simpel. In meinem Kopf wurde daraus eine Social App. Registrieren, Profil anlegen, in der App bleiben, Challenges entdecken, einen Feed aufbauen. Ich war stolz auf das UI. Schnell, klar, modern. Und trotzdem bin ich an einer Frage hängen geblieben, die ich am ersten Tag stellen hätte müssen: Warum soll sich jemand eine App installieren und einen ganzen Prozess mitmachen, nur um bei zehn oder dreißig Challenges abzustimmen?
Für den Nutzer, der nur schnell eine Meinung will, macht das keinen Sinn. Für mich schon, weil ich wie ein Gründer dachte, der Retention will, nicht wie jemand, der Reibung entfernt. Freunde anzusprechen und zu sagen „Probier mal meine App aus“ fühlte sich nie cool an. Es fühlte sich an wie Bitte stellen. Jedes Mal hatte ich das Gefühl, ich verkaufe nicht das Produkt, sondern eine Hürde.
Die einfache Lösung waren nicht schönere Buttons. Die einfache Lösung war, einen Schritt komplett zu eliminieren. Anonymes Voting im Web, ohne Install. Du bekommst einen Link, klickst, stimmst ab, fertig. Niemand musste erst in meine Welt einsteigen. Die Leute nutzten es, weil es in dem Moment funktioniert hat, in dem sie es brauchten. Das Produkt wurde der Link, nicht die App-Store-Seite.
Am Anfang war das unbequem. Eine App ohne App klingt, als würde man die Vision aufgeben. Tut man nicht. Einfach hieß hier: akzeptieren, dass die beste Version von SWIQ vielleicht außerhalb der App lebt, die ich mir ursprünglich vorgestellt habe.
Ballin: Zu viel, um es in einem Satz zu erklären
Ballin ging in die andere Richtung. Ich habe eine komplexe App gebaut, weil Komplexität nach Tiefe klang. Viele Ideen, viele Ecken, viele „das könnten wir auch noch“-Momente. Ich war begeistert, was daraus werden könnte. Und irgendwann konnte ich den Kern nicht mehr in einem Satz erklären. Nicht peinlich. Eher Warnsignal. Wenn ich als Builder nicht sage, wofür die App da ist, wie soll das ein neuer Nutzer wissen?
Von Anfang an steckte ein shareable Object drin: die Spielerkarte. Theoretisch der einfache Kern. Etwas, das du erstellst, verschickst, das funktioniert, auch wenn sonst niemand online ist. In der Praxis habe ich es unter allem begraben, was Ballin noch werden sollte. Ich habe die große Vision weitergebaut, statt den einen Moment zu perfektionieren, in dem jemand sagt: Die Karte will ich haben.
Monetarisierung hat es nicht leichter gemacht. Was soll Geld kosten? Warum soll jemand zahlen? Ich hatte Antworten im Kopf, aber keine, die sich natürlich angefühlt haben, weil das Produkt selbst nicht einfach genug war.
Heute, wenn ich an Ballin denke, starte ich mit einer anderen Frage. Was will der Nutzer in den ersten zehn Sekunden? Nicht, was die App irgendwann kann. Die Frage tut weh, weil sie dich zwingt, Ideen zu töten, die du noch magst.
Ballin liegt noch vor mir. Es ist noch nicht in den Stores. Das gibt mir Zeit, zu schneiden, bevor ich wieder shippe. Lieber jetzt streichen als etwas launchen, das ich erklären muss.
Fupla: Eine Frage statt ein Ökosystem
Fupla hat mir dieselbe Lektion aus einem anderen Winkel beigebracht. Fußball, Spieler, Gegner, Vereine, Camps, Plätze. Viele Seiten, viele Verbindungen, viel Potenzial. Ich habe zu viele Features gebaut, ohne klaren Startpunkt und ohne kleine lokale Community als Keimzelle. Irgendwann hatte ich 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 das Muster: Ich habe etwas gebaut, das funktionieren soll, wenn alle anderen schon mitspielen. Nicht etwas, das schon für eine Person am Dienstagabend Sinn ergibt, die einfach ein Spiel sucht.
Die einfache Version kam spät. Nicht „alles für Fußball“, sondern eine konkrete Frage: Ich suche Fußball. Ein Bedürfnis, eine Region, ein Moment. Kein soziales Netzwerk für den ganzen Sport am Tag eins. Der Fokus kam nicht, weil ich ihn perfekt geplant habe. Er kam, weil die breite Version nicht mehr weiterging.
Fupla ist in den App Stores. Ich schärfe den Fokus weiter. Live zu sein heißt nicht, fertig zu sein. Du kannst dich nicht mehr hinter „wir vereinfachen später“ verstecken. Nutzer treffen das, was du shipped hast.
Was ich heute anders mache
Ich liebe Bauen immer noch. Ich werde immer noch von neuen Ideen mitgerissen. Der Unterschied ist der Startpunkt. Bevor ich Code schreibe, versuche ich den einen Moment zu beschreiben, der für Nutzer Nummer eins funktioniert. Nicht die Roadmap. Nicht die Plattform. Den Moment. Bei SWIQ war es die Abstimmung per Link. Bei Ballin soll es die Karte sein. Bei Fupla die Suche nach einem Spiel.
Ich prototype schneller und poliere am Anfang weniger. Ein schöner Screen für ein Feature, das niemand braucht, ist trotzdem Waste.
Misstrauisch bin ich auch beim Satz „könnte man noch“. Jedes „noch“ ist eine kleine Steuer auf Klarheit.
Einfach ist fertig, wenn du leicht Angst hast, du hast etwas Wichtiges weggeschnitten, und du shippst trotzdem.
Für Builder, die spüren, dass ihre App zu viel ist
Ich schreibe das für Leute, die gerade etwas bauen und merken, dass es zu schwer ist. Vielleicht braucht deine App ein Tutorial. Vielleicht erklärst du sie dreimal und bekommst trotzdem nur höfliches Nicken. Vielleicht fügst du ständig hinzu, weil Hinzufügen leichter ist als Entscheiden. Genau da war ich, bei allen drei Projekten.
SWIQ und Fupla sind live. Ballin kommt noch. Das ist keine Erfolgsstory. Das ist ein Logbuch-Eintrag über etwas, das ich noch lerne: die einfache Lösung finden. Meistens ist es die, die man nicht zuerst gebaut hat.
Einfache Produkte wirken hinterher selbstverständlich. Davor sind es verworfene Ideen, tote Screens und unbequeme Gespräche mit dir selbst. Einfach bauen ist kompliziert. Das heißt nicht, du bist schlecht darin.
Wenn du mitten drin steckst, hoffe ich, dass das hilft, sich weniger allein zu fühlen. Du erkennst irgendwann den Moment, in dem du polierst statt entscheidest. Ich werde berichten, wie das läuft. Was ich streiche, was ich behalte, was funktioniert, was wieder hängen bleibt. Nicht als Werbung. Als Notiz an mich selbst, und vielleicht als Spiegel für jemanden, der die Schere noch in der Hand hält.