Wie gesund ernähre ich mich wirklich?

Kalorien-Apps beantworten die Frage nach der eigenen Ernährung nur gegen tägliches Eintragen, Mahlzeit für Mahlzeit, und genau daran scheitern viele. Dass es anders geht, zeigen Fitness-Tracker: Sie zählen Schritte, ohne dass jemand etwas eintippt, und trotzdem sehen ihre Träger jeden Tag nach, weil sie Zahlen und Trends über sich sehen wollen. Bonwise setzt deshalb eine Stufe früher an, beim Einkauf: ein Foto vom Kassenbon, das war es.

Angefangen hat es mit meiner eigenen Frage: Wie gesund ist mein Einkauf wirklich, und welche blinden Flecken habe ich? Die Antwort steckte in meinen Kassenbons. Also baute ich mir einen Claude-Skill: Nach jedem Einkauf fotografierte ich den Bon, der Skill trug die Artikel in eine Liste ein, und alle paar Wochen wertete ein selbst geschriebener Prompt sie aus. Ich fand tatsächlich Defizite. Nur blieb jeder Durchgang Handarbeit, und irgendwann lag die Frage auf dem Tisch, warum ich daraus keine App mache.

Vier Entscheidungen haben aus dem Prototyp ein Produkt gemacht.

Einen Monat nach der ersten Codezeile zog ich die Reißleine. Auf ein strukturiertes Audit des Ist-Stands folgte ein Redesign, das weit über die Oberfläche hinausging: neues UI, überarbeitete User Flows, eine neu aufgesetzte Auswertungs-Engine und der Umbau zur öffentlichen Multi-User-App mit zentraler Datenbank statt Daten im Browser. Seitdem wird jeder Screen in jedem Zustand erst als Mockup entworfen und iteriert, bis ich ihn abnehme, und erst dann gebaut. 67 dieser Mockups liegen bis heute im Repository, samt der verworfenen Varianten.

Die Mockup-Regel aus dem Neuaufbau hat eine Vorgeschichte. Ende Mai hatte ich eine neue Auswertungs-Ansicht für den Prototyp schriftlich beschrieben und direkt im Code bauen lassen. Was herauskam, sah anders aus als das Bild, das ich beim Schreiben vor Augen hatte, und ich verwarf fast alles. Der Fehler steckte nicht im Ergebnis, sondern im Verfahren: Über ein Design lässt sich erst urteilen, wenn man es sieht. Seitdem stehen Varianten als klickbare Mockups nebeneinander, bevor eine gebaut wird; wie viele Anläufe ein Element bekommt, zeigt das Duo aus zwei Kennzahl-Kacheln in sechs Fassungen.

Am 23. Juli 2026 ging bonwise als Beta live, im Kreis von Familie und Freunden. Geführt wird der Betrieb seitdem mit einer Nordstern-KPI, wörtlich: „Konten mit mindestens vier ausgewerteten Wochen und schreibender Aktivität in den letzten 30 Tagen.“ Stand heute erfüllen sie 4 von 10 Nutzern. Einmal die Woche, montags, schaue ich dafür auf ein Grafana-Dashboard, immer mit denselben drei Fragen:

Rückmeldungen kommen, wie sie im Alltag entstehen, als WhatsApp-Nachricht, Sprachmemo oder Screenshot, und werden als einzelne Befunde erfasst und priorisiert. Die August-Runde brachte 67 Befunde in 17 Clustern; die größten drehten sich nicht um Abstürze, sondern um Stellen, an denen die App richtig rechnet, aber nicht sagt, warum. Ein Tester im Sprachmemo: „Hm, komisch, weiß ich jetzt auch nicht, was mir das sagen soll.“

Vor dem Launch hatte ich den Registrierungsprozess doppelt und dreifach selbst durchgespielt. Trotzdem scheiterten die ersten Testnutzer genau daran, an zwei banalen Fehlern zugleich: Der Google-Login-Button war sichtbar, aber nie freigeschaltet. Und die Passwort-Regel war serverseitig auf zwölf Zeichen verschärft, während die Oberfläche noch „mindestens 8 Zeichen“ versprach. Beide Fehler haben dasselbe Muster: Frontend und Backend liefen auseinander, und ich war zu nah dran, um es zu sehen. Noch am Launchtag flog der Button komplett aus dem Code, und die Oberfläche zeigt seitdem die echte Passwort-Regel samt Checkliste. Rückblickend muss ich darüber lachen.

Der Status quo ist noch jung: eine Beta mit zehn Nutzern und ein Abo-Modell, das noch nicht freigeschaltet ist. Die nächsten Schritte sind geplant: Nutzerfeedback einarbeiten, eine kurze Einschätzung zu jedem Bon, damit sich nach jedem Foto etwas tut, ein zweiter Schwung von zehn Testern, dann die Zahlungsanbindung und die Store-Versionen. Eines muss die App jedoch noch beweisen: