Drei App-Versionen für eine Squash-Liga.

Die Squash-Liga hatte ein Problem. Der Court-Vermieter wollte die Preise erhöhen – das günstige Gruppenabo war plötzlich nicht mehr verfügbar. Statt festem Termin: WhatsApp-Abstimmung, wer wann kann, wer welchen Court bucht, wer das Geld vorstreckt. Das war offensichtlich keine Lösung. Also musste eine App her.

Was folgte, waren drei Versionen, eine Menge Erkenntnisse – und ein ziemlich guter Einblick darin, was es bedeutet, als Designer nicht nur Screens zu bauen, sondern ein ganzes System zu entwickeln. Das Ganze als privates Projekt, nebenbei. Der aktuelle Status: Die WhatsApp-Gruppe läuft noch. Die App wird gerade mit ein paar Spielern getestet.

Version 1: Komplex von Anfang an

Die erste Idee: Ein imaginäres Budget, das per PayPal aufgeladen werden kann. Davon bucht man Courts. Der Veranstalter wollte vorab wissen, wie viele Plätze gebraucht werden – das Budget-Modell schien die logische Antwort.

Gebaut wurde zunächst in Figma Make, dann Supabase für die Authentifizierung eingebunden, Resend als Mail-Dienstleister. Technisch betrachtet: eine Frage davon, welches Kabel man womit verbindet. Konzeptionell: schon in Version 1 deutlich komplexer als erwartet. Anmeldung, imaginäres Budget und Buchungen in einem System unterzubringen ist eine Sache. Es benutzbar zu machen, eine andere.

Und früh kam die erste wichtige Erkenntnis: raus aus der eigenen Bubble. Matteng war so tief im System drin, dass er vergessen hatte, wie es sich anfühlt, eine App zum ersten Mal zu sehen. Der erste Nutzertest mit ein paar Spielern – darunter Leute, die täglich Apps nutzen – hat das schnell klargemacht. Was selbstverständlich wirkte, war es nicht. Auch bei einer simplen Buchungs-App braucht es echte Menschen, bevor man davon ausgeht, dass irgendetwas funktioniert.

Version 2: Neues Konzept, neue Komplexität

Neue Idee: Grundbeitrag erheben, Buchungen kosten dafür weniger pro Spiel. Klingt überschaubar. War es nicht.

Denn sobald die Grundstruktur sich ändert, ändern sich alle Folgefragen mit. Was passiert wenn jemand erst im Februar einsteigt, die Saison aber im Oktober begonnen hat? Zahlt er den gleichen Grundbeitrag? Bekommt er Bonusspiele? Weniger inklusive Spiele? Was wenn jemand kündigt – werden anteilige Beträge erstattet? Was wenn jemand absagt?

Jede konzeptionelle Änderung zieht eine neue Liste an Edge-Cases nach sich. Und bei einer anderen Grundstruktur ist es nicht damit getan, ein paar Felder anzupassen – die App muss im Wesentlichen neu gedacht werden. Das war eine der überraschendsten Erkenntnisse: Selbst vermeintlich kleine Änderungen bedeuten oft, von vorne anzufangen.

Das ist auch der Moment, in dem man als Designer merkt, was es bedeutet, das gesamte System zu bauen und nicht nur Screens. Früher hat man Edge-Cases mitgedacht – oder versucht, es zumindest. Aber die Lücken hat am Ende jemand anderes gefunden. Wenn man das System selbst baut, findet man sie selbst. Sofort. Und muss sie lösen.

Version 3: Radikal vereinfachen – aber warum eigentlich?

Irgendwann kommt der Punkt, an dem man das Konzept komplett überdenkt. Version 3 war so simpel wie möglich: Eine Mailing-Liste. Eintragen, Reminder bekommen, fertig. Kein Budget, keine Buchungslogik, keine Zahlungsabwicklung.

Und hier liegt eine Falle, die mit KI größer geworden ist als früher. Früher hat man vereinfacht, weil Komplexität Entwicklungszeit bedeutete. Heute fällt diese Bremse weg. Man kann es einfach bauen. Und genau deshalb wird die Frage, was man weglassen sollte, wichtiger – nicht unwichtiger. Nur weil etwas machbar ist, heißt das nicht, dass es reingehört.

Die 80/20-Regel gilt – aber anders als erwartet

Mit KI hat man schnell ein erstes stehendes System. Version 10 ist oft schon ziemlich gut. Das verführt zur Annahme, es sei fast fertig.

Ist es nicht. Bis alles wirklich so funktioniert wie man es haben will, braucht man oft noch 90 weitere Iterationen. Die letzten 20 Prozent fressen die meiste Zeit. Das ist kein KI-Problem – das war immer so. Aber die Fallhöhe ist höher geworden, weil der Anfang so schnell geht. Man unterschätzt leichter, was noch kommt.

Was das alles über KI-gestütztes Entwickeln sagt

Datenstrukturen zuerst. Früher waren Datenstrukturen Sache der Entwickler. Das ändert sich, wenn man selbst baut. Die KI braucht eine klare Grundlage. Wer vorab nicht durchdenkt, wie Daten strukturiert sein müssen, merkt das meistens erst, wenn es teuer wird.

Der Nerd hat Vorteile. Wer ein bisschen Ahnung von Git, Datenbanken, Authentifizierung oder E-Mail-Infrastruktur hat, ist deutlich besser in der Lage, KI sinnvoll einzusetzen. Nicht weil man alles technisch versteht. Sondern weil man Ideen einbringen kann, die die KI dann ausprobiert. „Können wir das nicht auch mit einer einfachen XML lösen?" ist eine Frage, die nur stellt, wer zumindest weiß, dass XML existiert.

Man wird sein eigener Tester. Prompten, schauen wie es sich anfühlt, wieder prompten. Das schafft eine Distanz zum eigenen Output, die beim klassischen Design oft fehlt. Lücken werden sichtbarer. Aber es ersetzt keinen echten Nutzertest – das hat Version 1 direkt gezeigt.

Design bleibt Handarbeit – wenn es auf Unterscheidung ankommt. Generische Oberflächen entstehen schnell. Wenn das Interface nicht austauschbar sein soll, kommt man an Figma nicht vorbei. Matteng hat zuerst mit generierten Standardoberflächen gearbeitet – und dann ein eigenes Design gebaut. Der Wechsel war aufwändig. Hat sich trotzdem gelohnt.

Das Token-Modell von Figma Make ist ein Problem. Einmal im Monat ein Budget, nach ein paar Tagen intensiver Arbeit ist es weg – und man wartet wochenlang oder kauft teuer nach. Claude macht es anders: ein tägliches Budget, jeden Tag weitermachen. Das ist der bessere Rhythmus für iterative Arbeit.

Fazit

Drei App-Versionen für eine Squash-Liga. Noch läuft die WhatsApp-Gruppe. Aber die Erkenntnisse aus dem Projekt sind real – und lassen sich direkt auf Kundenprojekte übertragen.

Was bleibt: ein klareres Verständnis davon, was es bedeutet, als Designer nicht nur Screens zu liefern, sondern Systeme zu bauen. Und die Erkenntnis, dass die wichtigste Frage im KI-Zeitalter nicht „Können wir das?" ist. Sondern: „Sollte das überhaupt rein?"

Matteng arbeitet als Webdesign Freelancer aus Düsseldorf – und baut nebenbei eigene Dinge. Nicht weil es effizient ist. Sondern weil man dabei lernt, was man sonst nicht lernt.