Olive's Mediterranean Food (olivesfood.co.uk) is a UK-based food business. I built their order system, inventory flow, and operational dashboards. The technical stack was straightforward — the real learning was understanding how the business actually runs.
Operations first
Before writing code, I spent time in the kitchen and at the till. Who takes orders? When do deliveries go out? What happens when an item runs out mid-service? Software that ignores these questions creates friction. The best features came from watching the real workflow and removing steps, not adding them.
I shadowed the team for two days: lunch rush, dinner prep, closing. I saw the paper tickets, the scribbled notes, the "out of stock" board that sometimes got updated and sometimes didn't. The goal wasn't to digitise everything — it was to remove the pain points. Fewer steps, clearer information, less room for error.
Order flow that works
I designed the order system around peak times: quick entry, minimal clicks, clear status (pending, preparing, out, delivered). Kitchen gets a printed ticket; driver gets a route. No fancy dashboards for the sake of it — just what's needed to run the day.
Order entry: One screen. Customer name, items (searchable, with modifiers), notes, delivery address. I pre-filled addresses from past orders to speed things up. Payment could be taken later — during rush, capture the order first.
Kitchen display: A simple list of active orders, sorted by time. Colour-coded by status. When an item was marked "out", it greyed out on the menu so no one could add it. The kitchen could mark orders "ready" with one tap.
Driver view: Route list with addresses, phone numbers, and "call" / "navigate" buttons. Drivers marked orders "delivered" when done. I didn't need GPS tracking — that was overkill for their scale. Simple and reliable beat complex and fragile.
Inventory and waste
For a food business, inventory visibility matters. I added simple stock tracking so the team could see what's low before the rush. It's not ERP-level — it's "do we have enough halloumi for tonight?" That question, answered quickly, saves money and stress.
I linked menu items to ingredients. When you sell a halloumi wrap, the system deducts halloumi, wrap, and salad from stock. The team could manually adjust (e.g. "we got a delivery" or "we had to bin some"). Low-stock alerts went to a shared channel — no one had to remember to check.
I didn't try to predict demand or optimise ordering. I just made the current state visible. That alone cut waste by about 15% in the first month. The team knew what was running low before customers started asking.
What I didn't build
I said no to a lot of ideas. Loyalty programme? Not yet — focus on getting orders right first. Customer app? They were mostly phone and walk-in; a simple web order form was enough. Analytics dashboard? I added basic sales-by-day and top items; deep analytics could wait.
Scope creep is the enemy of operational tools. Every feature has a cost: training, maintenance, complexity. I shipped the minimum that made the day run smoothly, then iterated based on real feedback.
Takeaway
Building for a live business taught me that the best systems don't just function — they fit. They match how people actually work. Technical depth matters, but so does spending time where the work happens.
If you're building operational tools, go see the operation first. Watch the workflow. Find the friction. Then build to remove it — not to impress, but to help. Olive's is a reminder that the best software is often the simplest.