Some large chains do build catering software internally. Waitrose in the UK has run their own “Food Made To Order” service for years. It can work. But the honest tradeoffs are not usually what the initial business case assumes.
The line in the business case is usually “€800K dev project.” The reality, taken from public benchmarks for grocery internal-build projects, is closer to this:
| Phase | Typical reality | Indicative cost |
|---|---|---|
| Discovery + spec | 3-6 months of stakeholder interviews, store visits, vendor evaluation. Often produces a 200-page document that gets re-spec'd 12 months later. | €100-200K |
| MVP build (year 1) | Catalog, ordering, pickup scheduling, basic admin. Either a 6-8 person internal team or a SI partner. Slips by 3-9 months. | €800K-1.5M |
| Rule engine (year 2) | Capacity, pickup-date, pickup-time, pricing, vouchers. Always underscoped in the original plan; usually requires a re-architect. | €600K-1.2M |
| Multi-store rollout (year 2-3) | Per-store config UIs, store-manager training, pilot, expansion. Each rollout wave surfaces new edge cases requiring product work. | €400K-800K |
| Ongoing (year 3+) | 4-6 person platform team in perpetuity: bug fixes, regulatory updates, new POS integrations, browser compatibility, security patches. | €600K-1M / yr |
| Total to mature platform | 3-4 years to feature parity with what DeliChain ships today, plus permanent ongoing cost. | €3-5M one-time + €600K-1M/yr |
Cost ranges illustrative, drawn from public retail-tech project benchmarks. Internal-build catering platforms are rarely written up publicly because they are rarely considered competitive advantages worth disclosing.
For a 50-store chain starting from zero today.
Internal-build specs assume the catering domain is simpler than it is. These are the items that consistently surface in year 2 and force a re-architect.
Not a single number per store, but per-day, per-product-family, per-shift. Plus seasonal overrides. Plus emergency caps when staff calls in sick.
A 3-day lead time at 18:00 is not the same as at 09:00 next morning. Dates need to roll over correctly across timezones, weekends, and store-specific holidays.
B2B vs consumer. Family discount that stacks with voucher but not with seasonal promo. The pricing rule engine alone is usually 20% of the platform.
Five different views (production slip, delivery slip, full order, unpaid, all). Each has format conventions store managers expect from the legacy paper process.
Build-your-own products with 30+ options, dependent selections, dynamic pricing, free-text fields (kagemand name on a marzipan ribbon). Generic form-builders don't handle this.
Customer cancels 6 hours before pickup; production already started. What does the refund policy do, and how does the platform enforce it without a human deciding case-by-case?
We are not anti-build. There are real situations where it's the right call:
If two or more of these apply, it's worth modeling the in-house path seriously. If none apply, the math almost always comes out in favor of buying.
For chains under 200 stores, building in-house is almost never the right call — the development cost outruns the catering P&L.
For chains 200-1,000 stores, building can pencil out, but only with a strategic platform team already in place and a 3+ year patience window.
For everyone else — including the “we have IT, we could build this” ambition that often surfaces in steering-committee discussions — DeliChain shortens the path from decision to live operation by at least two years.
What steering committees actually ask once the True Cost numbers are on the table.
Probably not stop, but reframe. The work done so far on the catering schema, rule engine, or admin tooling is rarely wasted — the lessons translate. The harder question is whether to keep going to v1, or to flip to DeliChain and reuse the in-house build for the parts that genuinely are unique to your chain (loyalty integration, ERP plumbing, custom voucher logic). Most chains find the catalogue, ordering, slot management, and tenant isolation are not where they want to spend the next 18 months.
Not today. DeliChain is offered as a configured product, not a component library. The True Cost numbers on this page assume you buy the whole platform and integrate at the edges (auth, ERP, payments, loyalty). If you want a component-only relationship, that's a different conversation and almost certainly the wrong shape — the tenant model, rule engine, and order pipeline are deeply intertwined.
Yes — within the platform's extension surfaces. You get a public API, webhooks for every meaningful event, configurable rule engines, and access to your own Postgres replica for analytics. What you don't get is direct write-access to the operational schema, because that breaks the upgrade contract. If your customisation requirements would force schema-level changes, building in-house genuinely is on the table — see the “When to Build” section above.
Often the requirements feel unique but turn out to be variants of the same six rule shapes (capacity, lead-time, slot, price, voucher, assortment). The rule engine is the answer to most “but our chain does X differently” objections. The exceptions are usually loyalty, ERP, and franchise-billing edges — those are integration work, not platform work, and they're where your IT team should be spending time anyway.
Public reference points: Waitrose's catering platform spend, Tesco F&F replatforming, and several large grocery digital programmes the consulting press has reported on. Inside DeliChain we've also priced what it would cost us to rebuild from scratch — the numbers land in the same band. They're not precise per-chain forecasts; they're the order-of-magnitude estimate every steering committee should plug into an honest TCO comparison.
Yes — that's the assumed deployment model. We don't try to be your identity provider, your ERP, your loyalty engine, or your payment gateway. Integration to those systems happens via API and webhooks and is exactly where your IT team adds value. A typical first integration project is 4–8 weeks of work for a 50-store chain, much of which is internal change-management, not coding.
We'll walk you through the actual rollout plan for a 50-store chain — what happens in months 1, 4, and 9.
Book a DemoOr email us directly at hello@delichain.com