blog
A UK food manufacturing and cafe franchise group, running multiple brands across hundreds of physical sites, came to us with a problem that looked small and turned out to be anything but: their stores ordered stock by phone, email and spreadsheet.
It worked, just about, when there were a handful of locations. At hundreds of sites, across more than one brand, it had become a daily source of errors, delays and lost control. Head office couldn't see what each store was ordering, essential own-brand items were routinely missed, and every order had to be re-typed by hand into the warehouse system before anything could be picked or shipped.
We designed and built them a custom B2B ordering platform to fix it: a dead-simple mobile app for store managers, a control room for head office, and an automated link straight through to fulfilment. This is how we built it, and why a bespoke platform was the right call for a business this size.
The problem: ordering that doesn't scale across locations
Most multi-site businesses don't set out to run their ordering on spreadsheets. They grow into it. A process that was perfectly sensible at five locations quietly becomes a liability at fifty, and a serious operational risk at several hundred.
For this group, the cracks showed up in four places:
- No central control over what each site could order. Stores ordered off-catalogue, off-brand, or from the wrong supplier - via a 3rd-party fulfilment partner - and head office only found out after the fact.
- Essential items got missed. Own-brand and compliance lines that should be on every order depended on a store manager remembering to add them.
- Everything was re-keyed by hand. Orders landed in an inbox and someone re-typed them into the fulfilment system — slow, error-prone, and impossible to scale with order volume.
- No history, no audit trail, no consistency. Nobody could answer "who ordered what, when?" without digging through emails, and every store had invented its own way of doing things.
None of these are exotic problems. They're what ordering looks like at scale when the tools weren't built for it. (We unpack why franchise and multi-site ordering breaks at scale in a dedicated post.)
What we set out to build
We had two very different users to keep happy, and the temptation in projects like this is to compromise both. We didn't want to.
For store managers, the goal was an experience so simple it needed no training: open the app, pick your store, order in minutes, on a phone, standing in a stockroom, often with patchy wifi. Fast, and hard to get wrong.
For head office, the goal was central control without becoming a central bottleneck. They needed to define what each site could order and what every order must include, then get out of the way.
The principle that tied it together: put the rules in the system, not in people's heads.
How we approached the build
We started by getting the model right, not by writing code. A scoping phase mapped the brands, the sites, the product rules and the way store managers and head office work, because the hard part of a system like this is the rules, not the screens.
From there we built in phases. The core ordering flow came first and went in front of real users early, so their feedback shaped the next round rather than landing after launch. That keeps risk low: you see working software you can react to, instead of waiting months for a single big reveal.
The platform has kept growing since. This was never a build-it-and-leave-it project; we've continued to develop it as the business changes, and the same people who built it still look after it. It's how we work on every build: the directors who scoped it stay close to it, rather than handing you to a support desk once the invoice clears.
How it works
Brand- and location-aware ordering
The platform understands that this isn't one business: it's multiple brands, each with many sites. A store manager signs in, chooses the brand and store they're ordering for, and only ever sees what's relevant to that location. One person responsible for several sites can move between them without juggling logins or spreadsheets.
Per-location product rules
This is the heart of it. Every site has an allowed catalogue — the products that location is permitted to order — and a set of required items that must appear on every order. The required-item rule is enforced automatically: an order simply can't be submitted without the essentials. Own-brand items, compliance lines, signature products. They're never forgotten, because the system won't let them be.
Head office sets these rules once, per location, and they apply every time. No memos, no chasing, no exceptions slipping through.
Automated fulfilment: no re-keying
When a manager places an order, it routes straight through to the third-party logistics (3PL) warehouse that handles fulfilment, tagged with the right delivery location and courier service. Nobody re-types it. The order that the manager submits is the order the warehouse picks.
Stock availability flows the other way: product status is synced from the fulfilment system, so what staff see reflects what's available, and low-stock lines can be flagged before someone orders into a shortage.
Closing that gap — between "order placed" and "warehouse notified" — removed an entire layer of manual work and the errors that came with it. (We go deeper on how that integration is built in our piece on integrating ordering with a 3PL warehouse.)
Works anywhere, even offline
Store managers don't work at a desk. They work in stockrooms and back offices where the wifi drops. So we built the front end as an installable web app: it goes straight to the phone's home screen with no app store, no review process and nothing to download from a store.
Crucially, it keeps working when the connection doesn't. Managers can carry on building an order offline, and it syncs when they're back online. For a business spread across hundreds of real-world sites, that resilience isn't a nice-to-have. It's the difference between an order placed and an order abandoned.
A control room for head office
Behind the manager-facing app sits an admin panel where head office manages the moving parts: brands, product catalogues, delivery locations, couriers and users. When a new site opens or a catalogue changes, it's a configuration change, not a development job.
Re-ordering in seconds
Most store orders are routine: the same lines, week after week. So managers can save favourites and repeat a previous order in a couple of taps, then adjust quantities, rather than rebuilding every order from scratch. The routine case is fast, and the exceptions still get full attention.
The next phase: Approval and spend control
Some orders need a second pair of eyes. Head office will be able to set approval steps and spend limits, so an order over a threshold, or for a flagged item, goes for sign-off before it's placed. The control lives in the system and applies the same way every time, instead of relying on someone to remember the policy. For a head office managing spend across hundreds of sites, that's the difference between a policy on paper and one that holds in practice.
The results
The operational shifts are clear:
- Ordering is far quicker. Store managers place a correct order in minutes from a phone, wherever they are, instead of working the phones, email and spreadsheets.
- Fewer wrong or missed orders. Required items are guaranteed and off-catalogue ordering is blocked, so the mistakes that used to slip through largely don't.
- Head office has real visibility and control. HQ owns the catalogue and the rules across every brand and site, rather than finding out what was ordered after the fact.
- Orders reach the warehouse untouched, with no re-typing, removing a whole category of delay and human error.
- The system is resilient in the messy reality of patchy in-store connectivity.
It's now in daily use across the business. The phone-and-spreadsheet era is over for them, and the rules that used to live in people's heads now live in the platform.
Under the hood (for the technically minded)
For readers sizing up the engineering: the platform is API-first. A robust backend (Symfony and API Platform) exposes a clean API; the installable store-manager app and the head-office admin are both clients of it; and the same API drives the automated 3PL integration and stock sync. Error monitoring and transactional email round it out.
That decision — putting a well-defined API at the centre rather than building a monolith — is what makes the platform flexible enough to grow and clean enough to integrate. We unpack why we built it API-first in a separate post.
Frequently asked questions
Thinking about a custom ordering platform?
If your business runs across multiple locations and your ordering still depends on email, spreadsheets and people remembering the right things, you've probably already felt where this breaks. A custom platform isn't the right answer for everyone, but when ordering is core to how you operate, owning that process pays back: you own the platform, the data and the rules outright, with no per-seat licences and no vendor deciding your roadmap.
Tell us about your project and we'll talk through whether a bespoke, custom-built B2B ordering platform is the right fit, and what it would take to build.
