Noen store kjeder bygger cateringprogramvare internt. Waitrose i Storbritannia har drevet sin egen «Food Made To Order»-tjeneste i årevis. Det kan fungere. Men de ærlige avveiingene er vanligvis ikke det den første forretningscasen legger til grunn.
Linjen i forretningscasen er ofte «€800K dev-prosjekt». Realiteten, basert på offentlige referansepunkter for interne grocery-byggprosjekter, ligger nærmere dette:
| Fase | Typisk realitet | Veiledende kostnad |
|---|---|---|
| Utforskning + spesifikasjon | 3-6 måneder med intervjuer med interessenter, butikkbesøk og vurdering av leverandører. Gir ofte et dokument på 200 sider som må spesifiseres på nytt 12 måneder senere. | €100-200K |
| MVP-bygg (år 1) | Katalog, bestilling, hentetidsplanlegging og enkel administrasjon. Enten et internt team på 6-8 personer eller en SI-partner. Forsinkes med 3-9 måneder. | €800K-1.5M |
| Regelmotor (år 2) | Kapasitet, hentedato, hentetid, prising og vouchers. Er alltid underdimensjonert i den opprinnelige planen; krever som regel en ny arkitektur. | €600K-1.2M |
| Utrulling til flere butikker (år 2-3) | Konfigurasjons-UI per butikk, opplæring av butikkledere, pilot og ekspansjon. Hver utrullingsbølge avdekker nye spesialtilfeller som krever produktarbeid. | €400K-800K |
| Pågående (år 3+) | Plattformteam på 4–6 personer i all overskuelig fremtid: feilrettinger, regelverksoppdateringer, nye POS-integrasjoner, nettleserkompatibilitet, sikkerhetsoppdateringer. | €600K–1M / år |
| Totalkostnad for å modne plattformen | 3–4 år til funksjonsparitet med det FoodShop leverer i dag, pluss en permanent løpende kostnad. | €3–5M engangskostnad + €600K–1M/år |
Kostnadsintervallene er illustrerende og hentet fra offentlige referansepunkter for retail-tech-prosjekter. Interne cateringplattformer omtales sjelden offentlig fordi de sjelden anses som konkurransefortrinn verdt å avsløre.
For en kjede med 50 butikker som starter fra null i dag.
Spesifikasjoner for egenutvikling antar at cateringdomene er enklere enn det er. Dette er punktene som jevnlig dukker opp i år 2 og tvinger fram en ny arkitektur.
Ikke ett tall per butikk, men per dag, per produktfamilie, per skift. I tillegg til sesongoverstyringer. Og nødgrenser når ansatte melder seg syke.
En ledetid på 3 dager kl. 18:00 er ikke det samme som kl. 09:00 neste morgen. Datoer må rulle riktig over tidssoner, helger og butikkspesifikke helligdager.
B2B kontra forbruker. Familierabatt som kan kombineres med voucher, men ikke med sesongkampanje. Selve prisregelmotoren utgjør vanligvis 20 % av plattformen.
Fem ulike visninger (produksjonsseddel, leveringsseddel, full ordre, ubetalt, alle). Hver har formateringskonvensjoner butikkledere forventer fra den gamle papirprosessen.
Bygg-dine-egen-produkter med 30+ alternativer, avhengige valg, dynamisk prising, fritekstfelt (kagemand-navn på et marsipanbånd). Generiske skjema-byggerverktøy håndterer ikke dette.
Kunden avbestiller 6 timer før henting; produksjonen er allerede startet. Hva gjør refusjonsreglene, og hvordan håndhever plattformen dem uten at et menneske avgjør fra sak til sak?
Vi er ikke mot å bygge selv. Det finnes reelle situasjoner der det er riktig valg:
Hvis to eller flere av disse gjelder, er det verdt å modellere egenutviklingssporet grundig. Hvis ingen gjelder, peker regnestykket nesten alltid i retning av å kjøpe.
For kjeder under 200 butikker er egenutvikling nesten aldri riktig valg — utviklingskostnaden løper fra catering-P&L-en.
For kjeder med 200-1,000 butikker kan egenutvikling gå opp, men bare med et strategisk plattformteam allerede på plass og et tidshorisont på 3+ år.
For alle andre — inkludert ambisjonen om at «vi har IT, dette kan vi bygge» som ofte dukker opp i styringsgruppemøter — forkorter FoodShop veien fra beslutning til live drift med minst to år.
Det styringsgrupper faktisk spør om når True Cost-tallene ligger på bordet.
Sannsynligvis ikke stoppe, men omdefinere. Arbeidet som allerede er gjort på cateringskjemaet, regelmotoren eller adminverktøyene er sjelden bortkastet — erfaringene kan overføres. Det vanskeligere spørsmålet er om dere skal fortsette til v1, eller bytte til FoodShop og gjenbruke den interne utviklingen til de delene som virkelig er unike for kjeden deres (lojalitetsintegrasjon, ERP-koblinger, tilpasset voucherlogikk). De fleste kjeder opplever at katalog, bestilling, slotstyring og tenant-isolasjon ikke er det de vil bruke de neste 18 månedene på.
Ikke i dag. FoodShop tilbys som et konfigurert produkt, ikke et komponentbibliotek. True Cost-tallene på denne siden forutsetter at du kjøper hele plattformen og integrerer i kantene (auth, ERP, betaling, lojalitet). Hvis du ønsker et forhold kun for komponenter, er det en annen samtale og nesten helt sikkert feil form — tenant-modellen, regelmotoren og ordrelinjen er tett koblet av natur, og de fleste forsøk på å integrere på tvers av disse funksjonsgrensene vil sannsynligvis mislykkes.
Ja — innenfor plattformens utvidelsesflater. Du får et offentlig API, konfigurerbare regelmotorer og tilgang til din egen Postgres-replika for analyse. Det du ikke får, er direkte skriveadgang til det operative skjemaet, fordi det bryter oppgraderingsavtalen. Hvis dine tilpasningskrav ville tvinge fram endringer på skjemanivå, er det faktisk et alternativ å bygge internt — se seksjonen “Når du bør bygge” ovenfor.
Ofte føles kravene unike, men viser seg å være varianter av de samme seks regeltypene (kapasitet, ledetid, slot, pris, voucher, sortiment). Reglemotoren er svaret på de fleste «men kjeden vår gjør X annerledes»-innvendinger. Unntakene er vanligvis lojalitet, ERP og franchisefakturering — det er integrasjonsarbeid, ikke plattformarbeid, og der bør IT-teamet deres uansett bruke tiden sin.
Offentlige referansepunkter: Waitroses forbruk på cateringplattformen, Tescos F&F-replattforming og flere store digitale dagligvareprogrammer som fagpressen har omtalt. Inne i FoodShop har vi også priset hva det ville koste oss å bygge alt fra bunnen av — tallene havner i samme intervall. Det er ikke presise prognoser per kjede; det er størrelsesordensestimatet hver styringsgruppe bør legge inn i en ærlig TCO-sammenligning.
Ja — det er den antatte distribusjonsmodellen. Vi prøver ikke å være identitetsleverandøren din, ERP-systemet ditt, lojalitetsmotoren din eller betalingsgatewayen din. Integrasjon mot disse systemene skjer via API og webhooks, og det er nettopp der IT-teamet ditt skaper verdi. Et typisk første integrasjonsprosjekt er 4–12 ukers arbeid for en kjede med 50 butikker, og mye av dette er intern endringsledelse, ikke koding.
Vi viser dere den faktiske utrullingsplanen for en kjede med 50 butikker — hva som skjer i måned 1, 4 og 9.
Book en demoEller send oss en e-post direkte på info@sprintingretail.com