Nogle store kæder bygger faktisk cateringsoftware internt. Waitrose i Storbritannien har drevet deres egen "Food Made To Order"-service i årevis. Det kan lade sig gøre. Men de ærlige afvejninger er sjældent dem, den første business case forudsætter.
Linjen i business casen lyder som regel "udviklingsprojekt til 800.000 €". Virkeligheden, hentet fra offentlige benchmarks for interne byggeprojekter i dagligvarebranchen, ligner snarere dette:
| Fase | Typisk virkelighed | Vejledende pris |
|---|---|---|
| Analyse og specifikation | 3–6 måneders interessentinterviews, butiksbesøg, leverandørvurdering. Ender ofte i et dokument på 200 sider, der specificeres om 12 måneder senere. | 100–200.000 € |
| MVP-udvikling (år 1) | Katalog, bestilling, afhentningsplanlægning, basal admin. Enten et internt team på 6–8 personer eller en SI-partner. Skrider 3–9 måneder. | 0,8–1,5 mio. € |
| Regelmotor (år 2) | Kapacitet, afhentningsdato, afhentningstid, priser, vouchers. Altid underestimeret i den oprindelige plan; kræver som regel en re-arkitektur. | 0,6–1,2 mio. € |
| Udrulning til flere butikker (år 2–3) | Konfigurations-UI per butik, oplæring af butikschefer, pilot, udvidelse. Hver udrulningsbølge afdækker nye særtilfælde, der kræver produktarbejde. | 400–800.000 € |
| Løbende (år 3+) | Platformsteam på 4–6 personer på ubestemt tid: fejlrettelser, lovkrav, nye POS-integrationer, browserkompatibilitet, sikkerhedsopdateringer. | 0,6–1 mio. € / år |
| I alt til moden platform | 3–4 år til funktionsparitet med det, DeliChain leverer i dag, plus permanente løbende omkostninger. | 3–5 mio. € engangs + 0,6–1 mio. €/år |
Prisintervallerne er vejledende og hentet fra offentlige benchmarks for retail-tech-projekter. Egenudviklede cateringplatforme beskrives sjældent offentligt, fordi de sjældent anses for konkurrencefordele, der er værd at afsløre.
For en kæde med 50 butikker, der starter fra nul i dag.
Interne specifikationer antager, at catering er enklere, end det er. Det er disse punkter, der konsekvent dukker op i år 2 og tvinger en re-arkitektur igennem.
Ikke ét tal per butik, men per dag, per produktfamilie, per vagt. Plus sæsonundtagelser. Plus nødlofter, når personale melder sig syge.
En leveringstid på 3 dage kl. 18:00 er ikke det samme som kl. 09:00 næste morgen. Datoer skal rulle korrekt over tidszoner, weekender og butiksspecifikke helligdage.
B2B vs forbruger. Familierabat, der kan kombineres med voucher, men ikke med sæsonkampagne. Prisregelmotoren alene udgør typisk 20 % af platformen.
Fem forskellige visninger (produktionsseddel, leveringsseddel, fuld ordre, ubetalte, alle). Hver har formatkonventioner, butikscheferne forventer fra den gamle papirproces.
Byg-selv-produkter med 30+ valg, afhængige valg, dynamiske priser, fritekstfelter (navn på kagemandens marcipanbånd). Generiske formularværktøjer klarer det ikke.
Kunden annullerer 6 timer før afhentning; produktionen er allerede i gang. Hvad gør refusionspolitikken, og hvordan håndhæver platformen den, uden at et menneske afgør hver sag?
Vi er ikke imod at bygge. Der findes reelle situationer, hvor det er det rigtige valg:
Gælder to eller flere af disse, er det værd at regne seriøst på egenudvikling. Gælder ingen af dem, falder regnestykket næsten altid ud til fordel for at købe.
For kæder under 200 butikker er egenudvikling næsten aldrig det rigtige valg — udviklingsomkostningerne overhaler cateringens resultat.
For kæder med 200–1.000 butikker kan det gå op, men kun med et strategisk platformsteam allerede på plads og et tålmodighedsvindue på 3+ år.
For alle andre — inklusive ambitionen "vi har it, vi kunne bygge det selv", som ofte dukker op i styregrupper — forkorter DeliChain vejen fra beslutning til drift med mindst to år.
Det, styregrupper faktisk spørger om, når tallene for den reelle pris ligger på bordet.
Sandsynligvis ikke stoppe, men gentænke. Arbejdet hidtil på cateringskema, regelmotor eller adminværktøjer er sjældent spildt — erfaringerne kan overføres. Det sværere spørgsmål er, om I skal fortsætte til v1 eller skifte til DeliChain og genbruge det egenudviklede til de dele, der reelt er unikke for jeres kæde (loyalitetsintegration, ERP-kobling, særlig voucherlogik). De fleste kæder finder ud af, at katalog, bestilling, tidsstyring og tenant-adskillelse ikke er der, de vil bruge de næste 18 måneder.
Ikke i dag. DeliChain tilbydes som et konfigureret produkt, ikke et komponentbibliotek. Tallene for den reelle pris på denne side forudsætter, at I køber hele platformen og integrerer i kanterne (auth, ERP, betaling, loyalitet). Ønsker I kun komponenter, er det en anden samtale og næsten helt sikkert den forkerte form — tenant-modellen, regelmotoren og ordreflowet hænger tæt sammen.
Ja — inden for platformens udvidelsesflader. I får et offentligt API, webhooks for hver væsentlig hændelse, konfigurerbare regelmotorer og adgang til jeres egen Postgres-replika til analyser. Det, I ikke får, er direkte skriveadgang til driftsskemaet, fordi det bryder opgraderingsgarantien. Hvis jeres tilpasningsbehov ville kræve ændringer på skemaniveau, er egenudvikling reelt en mulighed — se afsnittet "Hvornår man skal bygge" ovenfor.
Kravene føles ofte unikke, men viser sig at være varianter af de samme seks regeltyper (kapacitet, leveringstid, tidsrum, pris, voucher, sortiment). Regelmotoren er svaret på de fleste "men vores kæde gør X anderledes"-indvendinger. Undtagelserne er som regel loyalitet, ERP og franchise-fakturering — det er integrationsarbejde, ikke platformsarbejde, og det er dér, jeres it-team alligevel bør bruge tiden.
Offentlige referencepunkter: Waitroses udgifter til cateringplatform, Tesco F&F's replatforming og flere store digitale programmer i dagligvarebranchen, som konsulentpressen har dækket. Internt i DeliChain har vi også regnet på, hvad det ville koste os at bygge om fra bunden — tallene lander i samme leje. De er ikke præcise prognoser per kæde; de er størrelsesordenen, enhver styregruppe bør sætte ind i en ærlig TCO-sammenligning.
Ja — det er den forudsatte udrulningsmodel. Vi forsøger ikke at være jeres identitetsudbyder, ERP, loyalitetsmotor eller betalingsgateway. Integration til de systemer sker via API og webhooks og er præcis der, jeres it-team skaber værdi. Et typisk første integrationsprojekt er 4–8 ugers arbejde for en kæde med 50 butikker, hvoraf meget er intern forandringsledelse, ikke kodning.
Vi gennemgår den faktiske udrulningsplan for en kæde med 50 butikker — hvad der sker i måned 1, 4 og 9.
Book en demoEller skriv direkte til os på hello@delichain.com