Arbeiten 02 Wirtshausküche

VALFA. Inventur ohne Nachtschicht.

Eine App, die bei der Inventur Zettel und Excel ersetzt: geführte Zählstrecke auf dem Handy, GoBD-konform in der Datenbank. Zwei Leute: Vale, Gastronomin in München, und ich. Seit März 2026.

Im Modell: die Wirtshausküche, Kisten vor der Tür. Am Schreibtisch fährt die Kamera der Startseite hierher, wenn der Zeiger auf der Karte liegt.
Drei Screens der VALFA-Zählstrecke: Übersicht der Zonen, Zählen im Weinregal, Abschluss (Demo-Daten)
Rolle
Technik komplett: Datenmodell, App, Backend, Tests, Releases
Zeitraum
März 2026 bis heute
Stack
Flutter 3.41, Riverpod 3, Supabase (Postgres, Frankfurt), PowerSync, pgTAP
Status
Pre-Release, Build 12 im TestFlight, Stand 11.10.2026
01

Problem

Zutaten

Inventur in der Gastronomie heißt: nach Dienstschluss mit Zettel durch Bar, Küche und Keller, dann Excel, dann Tage später die Zahlen an die Buchhaltung. Und die GoBD verlangt, dass jede Zahl nachvollziehbar bleibt, auch die korrigierte.

Die fachlichen Regeln kommen aus Vales Betrieb: wie gezählt wird, was Pfand bedeutet, wann eine Zahl stimmt. Nicht aus dem Lehrbuch.

02

Rolle

Die Technik, komplett: Datenmodell und Migrationen, Flutter-App, Supabase-Backend mit Row Level Security, Tests, TestFlight-Releases. Gebaut im Pair mit Claude Code: die KI schreibt mit, ich entscheide, prüfe am Gerät und trage die Verantwortung. Vale bringt den Betrieb, ich die Software, die ihn aushält.

03

Entscheidungen

Zubereitung
  • Zählstrecke statt Tabelle. Ein geführter Weg durch die Bereiche, Stepper mit 52 Pixel großen Tasten für eine Hand, Numpad für die Direkteingabe, Soll-Vorbefüllung, Pfand getrennt nach voll, leer und angebrochen.
  • GoBD von unten. Ein Audit-Log, das nur anhängt, mit einer SHA-256-Hash-Kette je Betrieb. Soft-Delete statt Löschen. Abgeschlossene Inventuren sind unveränderbar, korrigiert wird in einer Korrektur-Inventur.
  • Mandantentrennung in der Datenbank. Jede der 13 Tabellen trägt die Betriebs-ID und eine Policy in Postgres; ein Cross-Tenant-Test prüft sie alle in der CI.
  • Offline als Ziel, noch nicht gebaut. Der Keller hat keinen Empfang. Angelegt ist es: PowerSync verbindet sich nach dem Login, und jede Datenquelle hat eine Schnittstelle, hinter die die lokale Datenbank treten soll. Heute zählt die App noch direkt gegen Supabase; den Umzug habe ich im August vertagt, weil der Stand ihn nicht hergab.
  • Feedback per Schütteln. Wer beim Zählen etwas stört, schüttelt das Handy, spricht drauf, zählt weiter. Die Spracherkennung macht das Betriebssystem, kein Audio verlässt das Gerät.
04

Ergebnis in einer Zahl

Anrichten

506

Automatisierte Tests in der App, alle grün in 21 Sekunden. Dazu 199 Tests in der Datenbank: Hash-Kette, Mandantentrennung, Trigger. Regel seit dem ersten Feldtest: jeder Fehler bekommt einen Test, der ohne den Fix rot ist. Nutzer: ein Betrieb im Test, keine zahlenden Kunden. Zahlen zeige ich, wenn sie da sind.

Gemessen am 10.10.2026: flutter test in apps/valfa, 506 bestanden, 0 fehlgeschlagen, 21,3 s; Datenbanktests als Summe der plan()-Angaben in supabase/tests

05

Learnings

Nachgeschmack
  • Was die CI nicht sehen kann: eine fehlende iOS-Berechtigung, ein Sensor, den der Simulator nicht hat. Zwei Builds lang war ein Feature lautlos tot. Den Feldtest ersetzt kein Test.
  • Den Weg testen, nicht nur das Ziel. Das Feedback-Fenster war getestet, der Weg dorthin nicht. Seitdem startet der Test die echte App und schüttelt sie.
  • Der Engpass ist nicht der Code. Es ist die Stunde, in der jemand wirklich zählt. Software ohne Feldtest ist eine Vermutung.