The problem
A deviation on the packing line was written on a sheet, carried to the office, typed into Excel and once a month pasted into a PowerPoint. Four copies of the same event, three places it could get lost, and nobody able to say what actually went wrong most often.
The ERP vendor had a module. It cost more than the problem was worth, would take months to introduce, and still would not have covered the whole need.
Approach
Two days on the floor following a single deviation from the moment it happened until it closed. The form is drawn from what the operators already do, not from what a quality manual says they ought to do: phone first, one decision per screen, large touch targets, because a line means gloves, noise and harsh light.
The product was then built in phases, each ending in something that can be verified in the browser. Not in the code: in the browser, by clicking through the product as a user.
What it does
A deviation is captured on a phone at the line in six steps, with a photo and an order number, network or no network: it sits safely on the device and reaches the server intact when the connection returns. The right people are told, a critical deviation must be acknowledged, and silence escalates upward. Corrective actions are worked to closure on a board, and all of it lands in an audit trail that cannot be edited.
Multiple tenants on one core, roles from operator PIN to platform admin, Danish and English, light and dark themes. The dashboard shows what a production manager needs to see on Monday morning.
Two optional modules
On top of the core sit two modules a company can switch on when the need is there. Compliance keeps track of gauge calibration, competences and controlled documents, and can assemble an audit pack for a period. Production Performance records runs and stops at the line and computes OEE.
One design decision I am particularly happy with: the OEE figure refuses to show a headline the records cannot support. If the underlying data has gaps, the screen says so, instead of politely computing a number that would be wrong.
Where it stands
The product is built and has been live on my own infrastructure since August 2026, core and both modules in place. It has been tested by walking it screen by screen, in both languages and both themes, and every fault found has been fixed and re-verified.
There are no customers yet, and so there are no customer figures here. Once the first company has run it day to day, the measured results go on this page, and not before.
What I learned
That operators are not afraid of technology, but of forms. The paper sheet had fields nobody filled in, because they made no sense at the line. The most important decision in the design is therefore what gets removed, not what gets built.
And from the build itself: every fault that mattered was found by walking the product as a user, not by reading the code. A green test run proves less than you think.