Building an operating system for a multi-site food business

The Idea

One business. One connected operating system.

This project was not simply a website, a point-of-sale tool, or a delivery app. The useful work was designing a software layer that connected the operating reality of a food business: customers placing orders, staff working shifts, chefs managing ingredients, riders completing deliveries, managers watching margin, and payments moving through the system.

• Role: lead engineer, product architecture and platform delivery
• Scope: web, mobile, POS, payments, AI-assisted operations and direct delivery
• Users: customers, riders, chefs, staff and managers
• Platform: multi-location food retail

The Margin Problem

Food retail is a harsh software environment because the business model leaves little room for waste. When profit can be only a few points of every sale, apparently small operating costs are not small. Payment fees, delivery marketplace commissions, duplicate vendor subscriptions, inaccurate preparation, stock mistakes and unnecessary staffing all compete with the same thin margin.

GBP 100 in sales

Food and packaging
Labour
Rent and utilities
Payment and software fees
Delivery commission
Waste and rework
------------------------------
GBP 3-5 potential profit

The strategic insight was that the platform had to protect margin, not just process transactions. The system therefore needed to reduce third-party dependence, create cleaner operational data, and make repeated work easier to see.

Platform Shape

The architecture was designed around shared operational records rather than separate tools that happened to share a brand. Orders, ingredients, stock, staff activity, payment events and delivery status were useful in more than one product, so they needed to live in a platform model that different interfaces could trust.

Customer app       POS                 Rider app
     \              |                    /
      \             |                   /
       Shared commerce and operations platform
      /             |                   \
     /              |                    \
Staff app     Ingredients and stock     Management
                    |
             Forecasting and analytics

Three principles kept the system coherent:

• Shared operational data: a single ingredient or order record could support several applications without repeated entry.
• Multi-site operation: locations could work independently while management kept a cross-business view.
• Role-specific interfaces: customers, riders, chefs, staff and managers saw different products built on the same underlying system.

Product Constellation

The platform split into four product families, each with its own commercial job.

Commerce

POS, customer ordering, basket, payment and order status. The commercial consequence was that sales could happen through owned channels rather than only through third-party marketplaces.

Workforce

Staff shifts, earnings, payments and management views. Clearer visibility over work and pay supported trust, engagement and retention.

Operations

Stock, ingredient capture, recipe information and location reporting. Better operational data reduced repeated entry and made decisions less dependent on memory.

Delivery

Customer delivery status, rider jobs, dispatch and assignment. Owning the rider and customer experience protected the direct relationship with the customer.

The important design choice was to avoid treating these as unrelated applications. A product screen was only valuable when it improved the wider operating system.

Ingredient Workflow

The ingredient workflow was the best example of a single action creating value across the platform. It joined AI, operational efficiency and customer transparency without making AI the headline.

Ingredient arrives
  -> chef photographs packaging
  -> AI extracts structured information
  -> ingredient record is reviewed
  -> stock and recipe data update
  -> customer-facing calories and product information improve

The design intent was practical: remove repetitive manual entry, create better structured ingredient records, and make the same data useful to kitchen operations, stock management and the customer experience.

Research With The People Doing The Work

The platform only made sense if it respected the daily rhythm of the people using it. I worked with management, staff and chefs to understand where trust broke down, where work was repeated, and where existing tools forced people to carry important context in their heads.

The strongest workforce feature was not scheduling. It was trust around earnings and payment visibility.

That insight shaped the workforce product. Earnings and payment visibility were not decorative features. They were part of making the operating system feel trustworthy to the people whose work powered the business.

The same pattern applied elsewhere: chefs needed ingredient capture to be faster than manual records; managers needed multi-location visibility without losing local detail; riders needed clear jobs rather than an abstract dispatch system.

Forecasting

Forecasting was designed as an operational decision tool, not an AI showcase. The question was not "can the system predict tomorrow?" It was "can the system help the business prepare the right amount of food, staff the right number of people, and avoid missed sales or unnecessary waste?"

Forecast view

Expected demand        Based on historical sales and recent patterns
Preparation signal     How much food should be ready
Staffing implication   Whether the rota needs adjustment
Management action      Review, adjust, approve

This gave managers a clearer way to connect sales history to preparation and staffing decisions. The value was in the action that followed the forecast.

Technical Architecture

The technical work sat underneath a deliberately simple product story. Customers, staff, riders, chefs and managers needed different interfaces, but those interfaces had to agree about the state of the business.

Clients
  - customer web and mobile
  - POS
  - staff app
  - rider app
  - management dashboard

Platform services
  - identity and permissions
  - commerce and orders
  - inventory and ingredients
  - workforce and payments
  - delivery and dispatch
  - analytics and forecasting

Shared foundation
  - operational data store
  - external payment integration
  - deployment and observability

The architecture had to distinguish between the parts the business needed to own and the parts that could sensibly remain external services. Framework choices were secondary to the operational boundary: keep the business-critical data and workflows connected, legible and reusable.

Before And After

Before                         After
-----------------------------  -------------------------------
Fragmented operational tools   Shared operating platform
Marketplace-controlled delivery Direct customer and rider experience
Manual ingredient records      AI-assisted structured capture
Limited visibility across shops Multi-location operational view
Intuition-led preparation      Data-supported forecasting
Separate internal/customer data Connected operational transparency

The transformation was not about adding more screens. It was about making the business easier to operate because the software reflected how the business actually worked.

My Contribution

• Product strategy: defined the platform scope and prioritised the workflows that mattered to margin.
• Architecture: designed the shared multi-product system across commerce, operations and delivery.
• Engineering: built the core infrastructure and application surfaces.
• Research: worked directly with operational users to understand the real workflow constraints.
• AI: developed ingredient capture and forecasting capabilities around practical business decisions.
• Commercial design: connected technical decisions to margin protection and third-party cost exposure.

Outcome

The result was infrastructure that a smaller food operator would usually only get by stitching together several expensive systems, accepting marketplace dependence, or growing into the complexity of a much larger chain.

The platform operated around one central idea: preserve the direct relationship between the business, its staff and its customers by making the software layer coherent. That is where the commercial value lived.

Demonstrated outcomes:

• supported multiple user groups through one platform
• connected previously separate sales, delivery, ingredient and workforce workflows
• created direct ordering and delivery infrastructure
• gave management a reusable foundation for multi-location operations
• generated a platform story strong enough to create external commercial interest