Warehouse in production · Polidoro Group

Stock control for a clothing company. Polidoro Group were tired of stock figures being wrong, and wanted to see at a glance what was available and what needed reordering. Hence the brief: something fast, always to hand in the warehouse, simple to use, and keeping a record of every operation. The record was there from the very first request, and that detail is what tells you the real problem: they needed to know who had moved what, and when.

I kept only what was needed and left everything else out. No prices and no product photos, because this is a stock warehouse and not a shop. No cloud, because the warehouse is an industrial unit with a local network. No hardware to buy: the operators use the phones already in their pockets, and the laser printer was there. Everything left out is one less thing to configure, and one less thing to explain to somebody working on the warehouse floor.

reworking · scan the label to move the stock

The journey of one garment

When goods arrive, the item is created from the desktop: brand, original code, model, colour, size, opening stock, minimum threshold and shelf position. The internal code is not typed in, though. The system builds it from the original code, the colour and the size, and out comes CD0881-GIBL-3XL. A warehouse worker typing a string like that by hand will get it wrong sooner or later, so nobody has to type it.

Labels stack up in a print queue that lives in the database, not in the browser session: close the app and the queue is still there, and it does not empty itself after the download, so if a sheet comes out crooked you reprint without redoing the work. The PDF comes out with 24 labels to an A4 sheet, 70 by 37 millimetres each. Every label carries its QR code, four lines of text and a coloured band matching the garment, so it can be recognised without reading.

The QR code does not hold the internal code, but an address with a stable identifier for the item. If that code changes tomorrow, the labels already printed and stuck on keep working.

Then the operator opens the phone camera, points it at the QR, taps the banner that appears and lands on the item: plus one, minus one, or a quantity with a note. Five or six seconds in total.

The scanner I removed

I did build a QR scanner inside the app, and then I took it out. Using the camera from inside a browser needs HTTPS, and on a local network that means certificates installed by hand on every operator's phone, or a dedicated domain, or going into the client's DNS. I looked at all three roads and dropped them: too much setup for a feature that was slower anyway, ten or fifteen seconds against five. The phone's own camera has nothing to configure. I deleted the scanner code and its tests rather than leaving them sitting there switched off.

When two operators touch the same item

Every movement is a delta, never an absolute figure: nobody writes that there are now nine, they write minus one. Two operators each taking one piece produce two separate movements, both in the log, with who, when, from which device, and the resulting stock level captured at that moment. Each movement is also a single transaction: either the stock level and the log are updated together, or nothing moves. Stock cannot go below zero, and a withdrawal larger than the stock is refused with a message in plain language rather than a negative number.

The database runs in WAL mode, so readers do not block writers: while one operator records a movement, the owner's dashboard and the other phones carry on reading. The real-time event goes out after the write is confirmed, so no device ever sees a movement appear that then turns out not to exist.

Where it runs and who uses it

Two roles. The owner works from the office PC, which is also the server: the app opens with a double click into a window with no address bar, so a technical address never comes up. From there they do everything, items, colours, label printing, users, dashboard. Operators log in from the phone only, with a username and a numeric PIN, a thirty-day session, and they can do exactly one thing: open an item and change its stock.

Everything stays on the company network: nothing exposed to the internet, no VPN, no cloud. The system answers when the office PC is on, which is during working hours, and that was stated to the client before starting rather than discovered afterwards. Installing it on that PC takes three or four minutes from a USB stick, with a repeatable script, and every evening at 19:00 an automatic backup runs, keeping thirty days of copies.

First commit on 29 April 2026, in production on 8 June. It has not stood still since: there has been the bulk correction of a wrong original code, with internal codes regenerated down the chain, and optimisations to the real-time updates.