Sugar Break: Shop und Kalkulations-App für eine Bäckerei
Shop und Kalkulations-App für eine Heimbäckerei in Karachi. Ersetzt eine Tabelle mit 1.900 Formeln, zeigt Gewinn pro Produkt, Kasse, Lager und Partneranteile.
Die Herausforderung
Sugar Break ist eine Heimbäckerei in North Nazimabad, Karachi, geführt von 2 Personen als Partnerschaft. Bestellungen kamen über Instagram-DMs und WhatsApp. Die Buchhaltung lag in einer Excel-Mappe mit 15 Tabellenblättern und rund 1.900 Formeln, gespeist aus 3 Google Forms.
Kritische Problempunkte
- Tipp- und Rechenfehler setzten manche Kosten auf null und bepreisten gemischte Boxen mit falschen Werten, und die Tabelle meldete nichts davon
- Eine falsche Zeile im Verkaufslog brachte die Summen durcheinander, und der Abgleich mit dem Rest der Tabelle war mühsam
- Eine falsch erfasste Ausgabe verzerrte die Zutatenkosten, und eine Preiserhöhung schrieb die Marge jedes alten Verkaufs um
- Jede Änderung an den 3 Google Forms hinter der Tabelle war Kopfzerbrechen, und 18 Produkte brauchten schon 121 von Hand getippte Verpackungszeilen
- Niemand sah, welche Produkte oder Aktionen wirklich Geld verdienten, also fehlte ein klarer Ansatzpunkt für mehr Gewinn
- Beide Beteiligten zahlten Einkäufe aus eigener Tasche, ohne gemeinsame Aufstellung, wem was zusteht oder wie weit der Break-even entfernt ist
Die Buchhaltung war kompliziert und stimmte trotzdem nicht, also beruhten Preis- und Sortimentsentscheidungen auf Zahlen, die niemand prüfen konnte.
Die Lösung
Ein System in 2 Teilen: ein Shop, der aus dem Stöbern eine fertig geschriebene WhatsApp-Bestellung macht, und ein Dashboard, das die Finanzen des Geschäfts aus einem Kostenmodell steuert.
Ein Shop, der gefunden und geteilt wird
Jedes Produkt hat eine eigene vorgerenderte Seite mit strukturierten Daten, kann also von Suchmaschinen indexiert und über einen eigenen Link geteilt werden. Der Checkout braucht kein Backend: Die Bestellung landet im Postfach der Bäckerei und öffnet WhatsApp mit fertig geschriebener Nachricht. Eine Seite für Großbestellungen und eine teilbare digitale Menükarte kamen dazu.
Ein Kostenmodell, mit Tests
Rezepte, Toppings, Verpackung, Ausschuss und Gemeinkosten werden in der Datenbank zu Kosten pro Box, und automatisierte SQL-Tests sichern die Kostenformeln ab. Artikel kommen aus Dropdowns, und ein Einkauf in der falschen Einheit wird abgelehnt.
Preise und Angebote aus denselben Zahlen
Die Preisliste zeigt den Mindestpreis bei Zielmarge und markiert alles darunter. Gemischte Boxen werden pro Stück berechnet, und eine Datenbankprüfung blockiert jeden Preis, der eine Mischung billiger machen würde als dieselben Stücke einzeln. Großbestellungs-Angebote werden vor dem Versand mit der Marge im Einzelverkauf abgeglichen.
Das Geld im Tagesgeschäft
Beide Beteiligten melden sich an einem gemeinsamen Partnerbuch an, das zeigt, wem wie viel zusteht, und Rückzahlungen anteilig aufteilt. Eine gezählte Kasse wird mit den Büchern abgeglichen, und eine gelieferte Bestellung, die nach 7 Tagen noch offen ist, wird dringend. Lager und Backtage werden erfasst, Ausschuss wird zu Kosten verbucht.
Ergebnisse & Geschäftsauswirkungen
Fehler direkt korrigiert, in jeder Summe richtig
Ein falscher Verkauf oder eine falsche Ausgabe wird direkt in der Zeile oder gesammelt korrigiert, und ein Löschen nimmt den Eintrag sofort aus jeder Summe, während der Datensatz erhalten bleibt. Ein Einkauf in der falschen Einheit wird abgelehnt, bevor er Kosten verzerren kann.
Bücher, die mit der Kasse aufgehen
Ein Wasserfall führt das Handelsergebnis Zeile für Zeile bis zum Kassenstand, und eine gezählte Kasse wird damit abgeglichen. Jede Lücke zwischen Gewinn und Kasse hat eine benannte Zeile.
Gewinn pro Produkt und pro Aktion sichtbar
Marge pro Artikel, Bestseller, Stammkundschaft und die echten Kosten jeder Aktion stehen neben der Zahl an Boxen bis zum Break-even. Beide sehen, welche Produkte und Angebote sich lohnen.
Beide Beteiligten mit denselben Büchern
Der Umsatz hat in den ersten 16 Wochen 86 % von allem gedeckt, was ausgegeben wurde. Beide sehen diese Zahl und was jeder Person zusteht, ohne etwas von Hand nachzurechnen.
Kein Pflegeaufwand mehr für Formulare und Tabellen
Die Google Forms sind abgeschafft, erfasst wird in der App per Dropdown. Verpackung kommt aus einer Vorlage pro Boxgröße, und die Minis starteten mit Preisen, die bei den normalen Boxen ansetzen, aus denen sie geschnitten werden.
Ein Shop, nach dem Kundschaft fragt
Kundinnen und Kunden lobten die Website und fragten die Bäckerei, wer sie gebaut hat.
Erkenntnisse
Jede Kostenzahl zum richtigen Datum einfrieren
Jeder Verkauf speichert, was er am Verkaufstag gekostet hat. Mein erster Import fror stattdessen alle älteren Verkäufe zu den Preisen vom Migrationstag ein, und die Zutatenpreise waren seit Mai deutlich gefallen, also stimmten die frühen Margen nicht. Ich habe jeden Verkauf mit dem Preis neu kalkuliert, der an seinem eigenen Bestelldatum galt.
Grüne Tests verdeckten einen 3-tägigen Ausfall
Ich habe eine Datenbankprüfung ergänzt, dass jede gemischte Box festhält, welche Sorten in ihr stecken. In den 3 Tagen danach ließ sich kein Verkauf speichern, und jeder SQL-Test lief trotzdem grün. Jeder fehlgeschlagene Speicherversuch meldete 6 Stücke ohne Zuordnung. Die Fehlersuche zeigte, dass die Prüfung selbst stimmte: Sie wartet bis zum Ende einer Transaktion, und die API gab dem Verkauf und seinen Sorten je eine eigene, also kam jeder Verkauf ohne Sorten bei der Prüfung an. Die Tests fanden das nicht, weil eine Testdatei als eine einzige Transaktion läuft, genau die Bedingung, die der Browser nie hat. Die Lösung ist eine einzige Datenbankfunktion, die den Verkauf und seine Sorten zusammen schreibt. Sie ist jetzt der einzige Weg, einen Verkauf anzulegen, und ihr Test ruft dieselbe Funktion auf, statt direkt in die Tabellen zu schreiben.
Der Eigenkauf einer beteiligten Person ist echtes Geld, aber ein schlechtes Preissignal
Die Beteiligten kaufen manchmal Boxen für sich selbst deutlich unter Listenpreis. Das Geld ist echt, also zählen Kasse und Gewinn es mit. Es drückte aber die Marge, nach der Preise beurteilt werden, also lassen die Preiszahlen diese Verkäufe jetzt außen vor.
Nur eine gezählte Kasse prüft die Bücher
Jede Kassenzahl setzt voraus, dass jeder bezahlte Verkauf im gemeinsamen Topf ankam und dort blieb. Eine Liefergebühr, die aus dem Topf an den Fahrer ging, aber nie erfasst wurde, ließe die Zählung zu niedrig ausfallen, also fragt das Verkaufsformular jetzt nach der Ausgabe, sobald eine Gebühr eingetragen wird.
Verwendete Technologien
- React 18
- Vite 6
- Tailwind CSS 3
- Supabase
- PostgreSQL
- TanStack Query
- Recharts
- Vitest
- GA4
- Cloudflare Pages
Läuft Ihr Geschäft über Tabellen und Chats?
Wenn Ihre Kosten, Preise oder Partneranteile in einer Tabelle liegen, der niemand ganz traut, überführe ich sie in ein System, das seine eigenen Zahlen prüft. Schicken Sie mir, womit Sie arbeiten, ich antworte per E-Mail mit einer Einschätzung, was es bräuchte.
Nachricht sendenVerwandte Fallstudien
Bohra Calendar
Open-Source-PWA mit 225+ Fatemi-Ereignissen und genauer Hijri-Datumskonvertierung. Für die Dawoodi-Bohra-Gemeinschaft. Offline auf jedem Gerät.
Fallstudie lesen → Mobile AppsArabischer Abjad-Rechner
Arabischer Abjad-Rechner für Android und das Web, mit 850K+ Downloads und 4,75 Sternen über 13 Jahre. Kostenlos, werbefrei, kurz vor einer Million Downloads.
Fallstudie lesen → Mobile AppsGebetszeiten-App
Gebetszeiten-Android-App für die Dawoodi-Bohra-Gemeinschaft, 110K+ Downloads. Offline-Berechnungen, Hijri-Kalender, Push-Benachrichtigungen. Werbefrei.
Fallstudie lesen →