Sommige grote ketens bouwen cateringsoftware intern. Waitrose in het VK runt al jaren hun eigen “Food Made To Order”-dienst. Dat kan werken. Maar de eerlijke afwegingen zijn meestal niet wat de eerste businesscase veronderstelt.
De post in de businesscase is meestal “€800K dev project.” De werkelijkheid, gebaseerd op openbare benchmarks voor interne build-projecten in food retail, ligt eerder hier:
| Fase | Typische realiteit | Indicatieve kosten |
|---|---|---|
| Discovery + specificatie | 3-6 maanden aan stakeholderinterviews, winkelbezoeken en vendor-evaluatie. Levert vaak een document van 200 pagina’s op dat 12 maanden later opnieuw moet worden gespecificeerd. | €100-200K |
| MVP-build (jaar 1) | Catalogus, bestellen, afhaalscheduling en basisbeheer. Ofwel een intern team van 6-8 personen, of een SI-partner. Loopt 3-9 maanden uit. | €800K-1.5M |
| Rule engine (jaar 2) | Capaciteit, afhaaldatum, afhaaltijd, pricing, vouchers. In het oorspronkelijke plan altijd te beperkt gespecificeerd; vereist meestal een herarchitectuur. | €600K-1.2M |
| Uitrol naar meerdere winkels (jaar 2-3) | Configuratie-UI’s per winkel, training van store managers, pilot en uitbreiding. Elke uitrolgolf brengt nieuwe edge cases aan het licht waarvoor productwerk nodig is. | €400K-800K |
| Doorlopend (jaar 3+) | Platformteam van 4-6 personen voor onbepaalde tijd: bugfixes, updates voor regelgeving, nieuwe POS-integraties, browsercompatibiliteit, beveiligingspatches. | €600K-1M / jr |
| Totale kosten om het platform volwassen te maken | 3-4 jaar tot feature-pariteit met wat FoodShop vandaag levert, plus permanente doorlopende kosten. | €3-5M eenmalig + €600K-1M/jr |
Kostenindicaties zijn ter illustratie en gebaseerd op publieke benchmarks voor retail-techprojecten. Intern gebouwde cateringplatforms worden zelden openbaar gedocumenteerd, omdat ze zelden worden gezien als concurrentievoordeel dat het waard is om te delen.
Voor een keten van 50 winkels die vandaag vanaf nul start.
Specificaties voor intern bouwen gaan ervan uit dat het cateringdomein eenvoudiger is dan het is. Dit zijn de punten die consequent opduiken in jaar 2 en een herontwerp afdwingen.
Niet één enkel getal per winkel, maar per dag, per productfamilie, per shift. Plus seizoensgebonden overrides. Plus noodlimieten wanneer personeel zich ziek meldt.
Een doorlooptijd van 3 dagen om 18:00 is niet hetzelfde als om 09:00 de volgende ochtend. Datums moeten correct doorschuiven over tijdzones, weekenden en storespecifieke feestdagen heen.
B2B versus consument. Gezinskorting die stapelt met voucher, maar niet met seizoensactie. Alleen al de pricing rule engine is meestal 20% van het platform.
Vijf verschillende weergaven (productiebon, leveringsbon, volledige order, onbetaald, alles). Elk met opmaakconventies die storemanagers verwachten uit het papieren legacyproces.
Zelf samen te stellen producten met 30+ opties, afhankelijke selecties, dynamische prijsstelling, vrije-tekstvelden (kagemand-naam op een marsepeinen lint). Generieke form builders kunnen dit niet aan.
Een klant annuleert 6 uur voor afhalen; de productie is al gestart. Wat doet het terugbetalingsbeleid, en hoe handhaaft het platform dat zonder dat een mens per geval beslist?
Wij zijn niet tegen zelf bouwen. Er zijn echte situaties waarin dat de juiste keuze is:
Als twee of meer van deze punten op jou van toepassing zijn, is het de moeite waard om het zelfbouwtraject serieus door te rekenen. Als geen van deze punten geldt, valt de rekensom bijna altijd uit in het voordeel van kopen.
Voor ketens onder 200 winkels is zelf bouwen vrijwel nooit de juiste keuze — de ontwikkelkosten lopen harder op dan de catering-P&L.
Voor ketens van 200-1,000 winkels kan zelf bouwen uit kunnen, maar alleen met een strategisch platformteam al op zijn plaats en een geduldshorizon van 3+ jaar.
Voor alle anderen — inclusief de ambitie “we hebben IT, dit kunnen we wel bouwen” die vaak opduikt in overleg met de stuurgroep — verkort FoodShop de weg van besluit tot livegang met minstens twee jaar.
Wat stuurgroepen werkelijk vragen zodra de True Cost-cijfers op tafel liggen.
Waarschijnlijk niet stoppen, maar herformuleren. Het werk dat tot nu toe is gedaan aan het cateringdatamodel, de rule engine of de beheertooling gaat zelden verloren — de lessen zijn overdraagbaar. De lastigere vraag is of je doorgaat tot v1, of overstapt op FoodShop en de interne build hergebruikt voor de onderdelen die echt uniek zijn voor jullie keten (loyalty-integratie, ERP-koppelingen, aangepaste voucherlogica). De meeste ketens merken dat de catalogus, ordering, slotbeheer en tenantisolatie niet zijn waar ze de komende 18 maanden hun tijd in willen steken.
Nee, vandaag niet. FoodShop wordt aangeboden als een geconfigureerd product, niet als een componentbibliotheek. De cijfers voor Total Cost op deze pagina gaan ervan uit dat je het hele platform afneemt en integreert aan de randen (auth, ERP, betalingen, loyaliteit). Als je een relatie op componentbasis zoekt, is dat een ander gesprek en vrijwel zeker de verkeerde vorm — het tenantmodel, de rule engine en de orderpipeline zijn van nature sterk gekoppeld en de meeste pogingen om over deze featuregrenzen heen te integreren zullen waarschijnlijk mislukken.
Ja — binnen de uitbreidingsmogelijkheden van het platform. Je krijgt een publieke API, configureerbare rule engines en toegang tot je eigen Postgres-replica voor analyses. Wat je niet krijgt, is directe schrijfrechten op het operationele schema, omdat dat de upgrade-afspraak doorbreekt. Als je maatwerkvereisten schemawijzigingen zouden afdwingen, dan is zelf bouwen echt een optie — zie het gedeelte ‘When to Build’ hierboven.
Vaak voelen requirements uniek, maar blijken het varianten van dezelfde zes regelvormen te zijn (capaciteit, lead time, slot, prijs, voucher, assortiment). De rule engine is het antwoord op de meeste bezwaren in de trant van “maar onze keten doet X anders”. De uitzonderingen zitten meestal bij loyalty, ERP en franchisefacturatie — dat zijn integratiewerkzaamheden, geen platformwerk, en precies waar je IT-team sowieso tijd aan zou moeten besteden.
Publieke referentiepunten: de cateringplatformuitgaven van Waitrose, de replatforming van Tesco F&F en meerdere grote digitale groceryprogramma's waar de vakpers over heeft bericht. Binnen FoodShop hebben we ook doorgerekend wat het ons zou kosten om vanaf nul opnieuw te bouwen — de cijfers vallen in dezelfde bandbreedte. Het zijn geen precieze voorspellingen per keten; het is de orde van grootte die elke stuurgroep in een eerlijke TCO-vergelijking moet meenemen.
Ja — dat is het veronderstelde implementatiemodel. We proberen niet je identity provider, ERP, loyaliteitsengine of payment gateway te zijn. Integratie met die systemen verloopt via API en webhooks en is precies waar je IT-team waarde toevoegt. Een typisch eerste integratieproject kost 4–12 weken werk voor een keten met 50 winkels, waarvan veel intern verandermanagement is en niet coderen.
We nemen je mee door het daadwerkelijke uitrolplan voor een keten van 50 winkels — wat er gebeurt in maand 1, 4 en 9.
Boek een demoOf mail ons rechtstreeks via info@sprintingretail.com