Manche großen Ketten entwickeln Catering-Software tatsächlich intern. Waitrose in Großbritannien betreibt seit Jahren einen eigenen „Food Made To Order“-Service. Es kann funktionieren. Aber die ehrlichen Abwägungen sind selten die, von denen der erste Business Case ausgeht.
Im Business Case steht meist „Entwicklungsprojekt für 800.000 €“. Die Realität, abgeleitet aus öffentlichen Benchmarks für interne Entwicklungsprojekte im Lebensmittelhandel, sieht eher so aus:
| Phase | Typische Realität | Richtwert |
|---|---|---|
| Discovery und Spezifikation | 3–6 Monate Stakeholder-Interviews, Filialbesuche, Anbieterbewertung. Ergibt oft ein 200-seitiges Dokument, das 12 Monate später neu spezifiziert wird. | 100–200 T€ |
| MVP-Entwicklung (Jahr 1) | Katalog, Bestellung, Abholplanung, einfache Administration. Entweder ein internes Team mit 6–8 Personen oder ein SI-Partner. Verzögert sich um 3–9 Monate. | 0,8–1,5 Mio. € |
| Regelwerk (Jahr 2) | Kapazität, Abholdatum, Abholzeit, Preise, Gutscheine. Im ursprünglichen Plan immer unterschätzt; erfordert meist eine Neuarchitektur. | 0,6–1,2 Mio. € |
| Rollout auf mehrere Filialen (Jahr 2–3) | Konfigurationsoberflächen pro Filiale, Schulung der Filialleitungen, Pilot, Ausweitung. Jede Rollout-Welle bringt neue Sonderfälle, die Produktarbeit erfordern. | 400–800 T€ |
| Laufend (ab Jahr 3) | Plattformteam mit 4–6 Personen auf Dauer: Fehlerbehebung, regulatorische Updates, neue Kassenintegrationen, Browserkompatibilität, Sicherheitspatches. | 0,6–1 Mio. € / Jahr |
| Gesamt bis zur reifen Plattform | 3–4 Jahre bis zur Funktionsparität mit dem, was FoodShop heute liefert, plus dauerhafte laufende Kosten. | 3–5 Mio. € einmalig + 0,6–1 Mio. €/Jahr |
Kostenspannen sind Richtwerte aus öffentlichen Benchmarks für Retail-Tech-Projekte. Eigenentwickelte Catering-Plattformen werden selten öffentlich beschrieben, weil sie selten als Wettbewerbsvorteil gelten, den man offenlegen möchte.
Für eine Kette mit 50 Filialen, die heute bei null startet.
Interne Spezifikationen gehen davon aus, dass die Catering-Domäne einfacher ist, als sie ist. Diese Punkte tauchen im zweiten Jahr zuverlässig auf und erzwingen eine Neuarchitektur.
Nicht eine Zahl pro Filiale, sondern pro Tag, pro Produktfamilie, pro Schicht. Plus saisonale Ausnahmen. Plus Notfallobergrenzen, wenn sich Personal krankmeldet.
Eine Vorlaufzeit von 3 Tagen um 18:00 Uhr ist nicht dasselbe wie um 09:00 Uhr am nächsten Morgen. Daten müssen über Zeitzonen, Wochenenden und filialspezifische Feiertage korrekt weiterrollen.
B2B vs. Endkunde. Familienrabatt, der sich mit Gutschein kombinieren lässt, aber nicht mit Saisonaktion. Allein das Preisregelwerk macht meist 20 % der Plattform aus.
Fünf verschiedene Ansichten (Produktionszettel, Lieferschein, vollständige Bestellung, unbezahlt, alle). Jede hat Formatkonventionen, die Filialleitungen aus dem alten Papierprozess erwarten.
Selbst zusammengestellte Produkte mit 30+ Optionen, abhängigen Auswahlen, dynamischen Preisen, Freitextfeldern (Name auf dem Marzipanband des Kagemand). Generische Formularbaukästen schaffen das nicht.
Der Kunde storniert 6 Stunden vor der Abholung; die Produktion hat schon begonnen. Was tut die Erstattungsregel, und wie setzt die Plattform sie durch, ohne dass ein Mensch jeden Fall einzeln entscheidet?
Wir sind nicht gegen Eigenentwicklung. Es gibt reale Situationen, in denen sie die richtige Wahl ist:
Treffen zwei oder mehr dieser Punkte zu, lohnt es sich, den Eigenbau ernsthaft durchzurechnen. Trifft keiner zu, spricht die Rechnung fast immer für den Kauf.
Für Ketten unter 200 Filialen ist eine Eigenentwicklung fast nie die richtige Wahl — die Entwicklungskosten überholen das Catering-Ergebnis.
Für Ketten mit 200–1.000 Filialen kann sich Bauen rechnen, aber nur mit einem bereits vorhandenen strategischen Plattformteam und einem Geduldsfenster von mehr als 3 Jahren.
Für alle anderen — einschließlich der Ambition „wir haben eine IT, wir könnten das bauen“, die in Lenkungsausschüssen oft aufkommt — verkürzt FoodShop den Weg von der Entscheidung zum laufenden Betrieb um mindestens zwei Jahre.
Was Lenkungsausschüsse tatsächlich fragen, sobald die wahren Kosten auf dem Tisch liegen.
Wahrscheinlich nicht aufhören, sondern neu ausrichten. Die bisherige Arbeit an Catering-Schema, Regelwerk oder Admin-Werkzeugen ist selten verloren — die Erkenntnisse lassen sich übertragen. Die schwierigere Frage ist, ob Sie bis v1 weitermachen oder auf FoodShop wechseln und den Eigenbau für die Teile wiederverwenden, die wirklich einzigartig für Ihre Kette sind (Loyalty-Integration, ERP-Anbindung, individuelle Gutscheinlogik). Die meisten Ketten stellen fest, dass Katalog, Bestellung, Zeitfenster-Management und Mandantentrennung nicht der Ort sind, an dem sie die nächsten 18 Monate verbringen wollen.
Heute nicht. FoodShop wird als konfiguriertes Produkt angeboten, nicht als Komponentenbibliothek. Die auf dieser Seite genannten True-Cost-Werte setzen voraus, dass Sie die gesamte Plattform erwerben und an den Rändern integrieren (Auth, ERP, Payments, Loyalty). Wenn Sie nur Komponenten beziehen möchten, ist das ein anderes Gespräch — und sehr wahrscheinlich die falsche Form. Das Mandantenmodell, die Rules Engine und die Auftragsverarbeitung sind naturgemäß eng gekoppelt, und die meisten Versuche, diese Funktionsgrenzen zu integrieren, werden voraussichtlich scheitern.
Ja — innerhalb der Erweiterungsoberflächen der Plattform. Sie erhalten eine öffentliche API, konfigurierbare Rules Engines und Zugriff auf Ihre eigene Postgres-Replica für Analysen. Was Sie nicht erhalten, ist direkter Schreibzugriff auf das operative Schema, denn das würde den Upgrade-Vertrag brechen. Wenn Ihre Anpassungsanforderungen Schema-Änderungen erzwingen würden, ist eine Eigenentwicklung durchaus eine Option — siehe den Abschnitt „When to Build“ oben.
Oft fühlen sich die Anforderungen einzigartig an, entpuppen sich aber als Varianten derselben sechs Regelformen (Kapazität, Vorlaufzeit, Zeitfenster, Preis, Gutschein, Sortiment). Das Regelwerk ist die Antwort auf die meisten Einwände der Art „aber unsere Kette macht X anders“. Ausnahmen sind meist Kundenbindung, ERP und Franchise-Abrechnung — das ist Integrationsarbeit, keine Plattformarbeit, und genau dort sollte Ihre IT ohnehin ihre Zeit investieren.
Öffentliche Referenzpunkte: die Ausgaben von Waitrose für seine Catering-Plattform, das Replatforming von Tesco F&F und mehrere große Digitalprogramme im Lebensmittelhandel, über die die Beratungspresse berichtet hat. Bei FoodShop haben wir außerdem durchgerechnet, was ein Neubau von Grund auf kosten würde — die Zahlen landen in derselben Spanne. Es sind keine präzisen Prognosen pro Kette, sondern die Größenordnung, die jeder Lenkungsausschuss in einen ehrlichen TCO-Vergleich einsetzen sollte.
Ja — das ist das zugrunde liegende Bereitstellungsmodell. Wir versuchen nicht, Ihr Identity Provider, Ihr ERP, Ihre Loyalty-Engine oder Ihr Payment Gateway zu sein. Die Anbindung an diese Systeme erfolgt per API und Webhooks und ist genau der Bereich, in dem Ihr IT-Team Mehrwert schafft. Ein typisches erstes Integrationsprojekt dauert für eine Kette mit 50 Filialen 4–12 Wochen; ein großer Teil davon entfällt auf internes Change Management, nicht auf Programmierung.
Wir führen Sie durch den tatsächlichen Rollout-Plan für eine Kette mit 50 Filialen — was in Monat 1, 4 und 9 passiert.
Demo buchenOder schreiben Sie uns direkt an info@sprintingretail.com