A new warehouse system, live in sixteen weeks, running every pallet

John George is a UK wholesaler with six depots. Its Cardiff Road site runs on what the team calls the OverstocksDB. It knows which pallet sits in which rack above the pick bins, what's on it, how old it is, and when it needs to come down before a picker finds a bin empty.

It isn't glamorous. It is, though, the thing the business runs on. Forty-one people across the office and the warehouse floor use it, and if it stops, so does the replenishment of every pick bin in the building.

By 2026 it was three systems held together with goodwill: a desktop database for the office, a separate handheld app for the forklift drivers, and a third-party automation server that pulled stock data from the ERP whenever someone sent it an email. We were brought in through Robots & Humans to replace all three.

The challenge

The stock import was the daily pain. Refreshing the numbers meant triggering an email, closing the desktop app and opening it again, and it happened often enough to hold up the floor.

Underneath that, the real knowledge of how the warehouse works was buried in old code. The rules that decide which of seven holding pallets a part-used load goes on, by age and by location, lived in a module nobody had read in years. Some things the floor did every day, like what happens to stock between coming down from the rack and going into a bin, the old system simply didn't track.

And there was a hard deadline that couldn't move: the annual overstocks stocktake at the end of the year. The new system had to be live, stable through October, and able to help run the count.

What we did

We started on the warehouse floor rather than in the code. Phil spent a lot of time with the stock control team, and we took what we learned there, plus the old database and the old handheld app, and wrote it all down as nine requirements documents in the client's own language, so the people who run the business and the warehouse team could mark them up and argue with them. They did, usefully. The first round of corrections changed how stock age is measured: by the batch it arrived in, not by the pallet it happens to sit on.

A handheld built for gloves

The forklift drivers, goods-in team and floor operatives work on rugged Android scanners, often in gloves. So the touch targets are much bigger than a normal app's and the text is larger. Bin locations and pallet labels can only be scanned, never typed, because a typo in a location is how pallets get lost. Product codes can be typed, because plenty of products carry no barcode at all. One device had a broken scanner, so there's a camera fallback too. None of it is clever. All of it came from watching people use the old one.

Keeping up when the process changed

The Goods In process was reworked twice in six weeks. The second time, in a September meeting at Cardiff Road, the team decided pallets should be sorted at the back of Goods In instead of being lifted into the racks and sorted weeks later. It was a business decision, not a system one, and it was the right call. It also meant redoing a flow we'd already built.

This is where working with AI changed how much a small team could absorb. We recorded the meetings and turned each one into a decision log the same day, with every decision, every action and every open question listed. AI wrote most of the code against those decisions, and we spent our time on the judgement calls and on testing. When the stock controller sent a list of problems from testing on a Thursday, the fixes were live on the website and the handheld by the following Monday.

Works orders in a day

The packing team's output, stock that John George packs itself, needed its own route into the warehouse. The spec was written on 1 October. When the real data started arriving from the ERP on 6 October it didn't match the spec at all: the numbers were per line, not per sheet, and they were grouped in a way nobody had expected. We rebuilt the model around what the ERP actually sent, and the works orders screen was built that same day, switched off until the team was ready to test it.

The results

Live on 8 October 2026, about sixteen weeks after discovery started, with a 48-hour parallel run against the old system before it was switched off.

Three systems replaced by one: the office screens, the handheld app and a live connection to the ERP, so nobody sends an email to refresh the stock any more.

One pallet's difference when the old and new systems were compared side by side at the end of the parallel-run week, and that one most likely down to how the old system tracked (or didn't track) stock in the replen area.

More than 1,700 automated tests and 36 end-to-end journeys, covering every flow from a delivery arriving to stock reaching a pick bin.

Since go-live we've added KPI dashboards for supervisors, the replen team and the forklift drivers. The system has proper backups and error monitoring.

Under the hood

The backend is Laravel 13 on PostgreSQL, with a Vue and Inertia desktop app for the office. The handheld is a React Native app built with Expo, running on Zebra Android scanners and talking to the same backend through a token API, with over-the-air updates so a fix reaches the floor without reinstalling. Stock levels, goods received notes and works orders come from John George's K8 ERP through its live API. A small print agent on site sends pallet labels and action sheets to the warehouse printers. Tests are Pest and Playwright.