Vissa stora kedjor bygger cateringmjukvara internt. Waitrose i Storbritannien har drivit sin egen tjänst “Food Made To Order” i åratal. Det kan fungera. Men de ärliga avvägningarna är oftast inte vad den första affärskalkylen antar.
Raden i affärskalkylen är oftast “€800K dev project.” Verkligheten, baserad på offentliga riktmärken för interna livsmedelsprojekt, ligger närmare detta:
| Fas | Typisk verklighet | Indikativ kostnad |
|---|---|---|
| Utforskning + kravspecifikation | 3-6 månader med intervjuer med intressenter, butiksbesök och leverantörsutvärdering. Resulterar ofta i ett dokument på 200 sidor som behöver omarbetas efter 12 månader. | €100-200K |
| MVP-utveckling (år 1) | Katalog, beställning, upphämtningstidplanering, grundläggande administration. Antingen ett internt team med 6-8 personer eller en SI-partner. Försenas med 3-9 månader. | €800K-1.5M |
| Regelmotorn (år 2) | Kapacitet, upphämtningsdatum, upphämtningstid, prissättning, vouchers. Alltid underbudgeterad i ursprungsplanen; kräver vanligtvis en omarkitektur. | €600K-1.2M |
| Utrullning till flera butiker (år 2-3) | Konfigurationsgränssnitt per butik, utbildning av butikschefer, pilot, expansion. Varje utrullningsvåg avslöjar nya specialfall som kräver produktutveckling. | €400K-800K |
| Pågående (år 3+) | Plattformteam på 4–6 personer på obestämd tid: buggfixar, regulatoriska uppdateringar, nya POS-integrationer, webbläsarkompatibilitet, säkerhetsuppdateringar. | €600K-1M / år |
| Totalt för att mogna plattformen | 3–4 år till funktionsparitet med det FoodShop levererar i dag, plus permanent löpande kostnad. | €3-5M engångskostnad + €600K-1M/år |
Kostnadsintervallen är illustrativa och baserade på offentliga riktmärken för retail-tech-projekt. Cateringplattformar byggda internt redovisas sällan offentligt, eftersom de sällan anses vara konkurrensfördelar värda att avslöja.
För en kedja med 50 butiker som startar från noll i dag.
Specifikationer för intern utveckling utgår från att cateringområdet är enklare än det är. Det här är de delar som konsekvent dyker upp under år 2 och tvingar fram en ny arkitektur.
Inte ett enda tal per butik, utan per dag, per produktfamilj, per skift. Plus säsongsjusteringar. Plus nödkvoter när personalen sjukskriver sig.
En ledtid på 3 dagar kl. 18:00 är inte samma sak som kl. 09:00 nästa morgon. Datum måste rulla över korrekt över tidszoner, helger och butiksspecifika helgdagar.
B2B mot konsument. Familjerabatt som kan kombineras med voucher men inte med säsongskampanj. Själva regelmotorn för prissättning står vanligtvis för 20% av plattformen.
Fem olika vyer (produktionskvitto, leveranskvitto, hela ordern, obetald, alla). Varje vy har formateringskonventioner som butikschefer förväntar sig från den gamla pappersprocessen.
Bygg-själv-produkter med över 30 alternativ, beroende val, dynamisk prissättning, fritextfält (kagemand-namn på ett marsipanband). Generiska formulärbyggare klarar inte detta.
Kunden avbokar 6 timmar före upphämtning; produktionen har redan startat. Vad gör återbetalningspolicyn, och hur upprätthåller plattformen den utan att en människa fattar beslut från fall till fall?
Vi är inte emot att bygga. Det finns verkliga situationer där det är rätt val:
Om två eller fler av dessa gäller är det värt att modellera den interna vägen på allvar. Om inga gäller landar kalkylen nästan alltid till fördel för att köpa.
För kedjor under 200 butiker är det nästan aldrig rätt val att bygga internt — utvecklingskostnaden springer ifrån cateringens P&L.
För kedjor med 200-1,000 butiker kan ett internt bygge gå ihop, men bara med ett strategiskt plattformsteam redan på plats och ett tålamodsfönster på 3+ år.
För alla andra — inklusive ambitionen “vi har IT, vi skulle kunna bygga detta” som ofta dyker upp i styrgruppsdiskussioner — förkortar FoodShop vägen från beslut till driftstart med minst två år.
Det som styrgrupper faktiskt frågar när True Cost-siffrorna väl ligger på bordet.
Troligen inte sluta, men omformulera. Arbetet som hittills lagts på catering-schemat, regelmotorn eller adminverktygen är sällan bortkastat — lärdomarna går att återanvända. Den svårare frågan är om ni ska fortsätta till v1, eller byta till FoodShop och återanvända det interna bygget för de delar som verkligen är unika för er kedja (lojalitetsintegration, ERP-kopplingar, anpassad voucherlogik). De flesta kedjor upptäcker att katalog, beställning, tidslotsstyrning och tenantisolering inte är där de vill lägga nästa 18 månader.
Inte idag. FoodShop erbjuds som en konfigurerad produkt, inte som ett komponentbibliotek. Siffrorna för Total Cost på den här sidan utgår från att du köper hela plattformen och integrerar i kanterna (auth, ERP, betalningar, lojalitet). Om du vill ha ett upplägg enbart på komponentnivå är det en annan diskussion och nästan säkert fel form — tenantmodellen, regelmotorn och orderflödet är naturligt starkt kopplade, och de flesta försök att integrera över dessa funktionsgränser kommer sannolikt att misslyckas.
Ja — inom plattformens utbyggnadsyta. Du får ett publikt API, konfigurerbara regelmotorer och åtkomst till din egen Postgres-replika för analys. Det du inte får är direkt skrivåtkomst till den operativa scheman, eftersom det bryter uppgraderingsavtalet. Om dina anpassningskrav skulle kräva ändringar på schemanivå är egenutveckling faktiskt ett alternativ — se avsnittet "När du bör bygga" ovan.
Ofta känns kraven unika men visar sig vara varianter av samma sex regelmönster (kapacitet, ledtid, tidslucka, pris, voucher, sortiment). Regelmotorn är svaret på de flesta invändningar i stil med “men vår kedja gör X annorlunda”. Undantagen gäller oftast lojalitet, ERP och franchisefakturering — det är integrationsarbete, inte plattformsarbete, och där bör ert IT-team ändå lägga sin tid.
Offentliga referenspunkter: Waitroses satsning på cateringplattformen, Tesco F&F:s omplattformning och flera stora digitala dagligvaruprogram som konsultpressen har rapporterat om. Inne i FoodShop har vi också prissatt vad det skulle kosta oss att bygga om från grunden — siffrorna landar i samma spann. De är inte exakta prognoser per kedja; de är den storleksordning som varje styrgrupp bör använda i en ärlig TCO-jämförelse.
Ja — det är den förutsatta driftsmodellen. Vi försöker inte vara din identitetsleverantör, ditt ERP, din lojalitetsmotor eller din betalningsgateway. Integration med dessa system sker via API och webhooks och är precis där ditt IT-team tillför värde. Ett typiskt första integrationsprojekt är 4–12 veckors arbete för en kedja med 50 butiker, där mycket handlar om intern förändringsledning, inte kodning.
Vi går igenom den faktiska utrullningsplanen för en kedja med 50 butiker — vad som händer månad 1, 4 och 9.
Boka en demoEller mejla oss direkt på info@sprintingretail.com