This case study is anonymised. We build internal systems, so we describe the kind of system and why it was built, not who it was for.
The situation
The client is a mid-sized manufacturing company. Goods come in, go through production, are packed, stored and shipped to customers. Every one of those steps was already being recorded, but on paper forms, in spreadsheets and in the heads of a few experienced people.
The problem was not missing information. It was that the pieces were not connected. A receiving record did not know which production run used the material. A production record did not know what the run had cost. Answering a simple question, such as where a batch ended up or what a month of production really cost, meant someone collecting papers and rebuilding the picture by hand.
What we built
One web application that runs on the phones and tablets people already carry on the floor, plus an administration area for management. It is built on Supabase: a Postgres database for the records, its authentication and roles for access control, file storage for photos and documents, and server-side functions for calculations that must not run in the browser.
The application covers the main flows of the business:
- Receiving. Incoming goods are recorded with their batch, expiry, quantity and storage location, with photos and a signature captured on the device.
- Production records. Each run records what went in, what came out and what was used along the way. Outputs are linked to the inputs they were made from, so any batch can be traced in both directions.
- Dispatch. Outgoing shipments are recorded with the customer, the transport details and a signature at handover.
- Planning and quality records. Shift planning and the routine checks that quality requires, each exportable as a document.
- Production costs. The system brings together the inputs that make up the cost of production, so management sees costs from the same records the floor creates rather than from a separate spreadsheet.
Roles decide what each person sees. Someone on the floor gets the screens for their job and nothing else; management gets the overview. Forms save as people type, because a half-filled record on a tablet should never be lost to a dropped connection.
How it works day to day
People record their work where it happens, on the device in their hand, instead of on paper that someone retypes later. A batch can be traced from delivery to customer by following links in the data. At the end of a period, management reviews and closes it, and a closed period keeps a snapshot of the values it was based on, so later changes do not quietly rewrite history.
The practical difference is that nobody retypes paper records into spreadsheets any more, and questions that used to take an afternoon of searching are answered from the system.
What we learned
A missing value must never look like a zero. Any calculation that depends on reference data, such as prices or rates that change over time, has to tell the difference between "this costs nothing" and "we do not know what this costs". If the system silently treats missing data as zero, the numbers stay plausible and nobody notices. We make missing inputs visible and block calculations that people are paid from until the inputs are complete.
Check that both halves of a feature are connected. An input screen and the calculation that should use it can drift apart as a system grows. Before assuming people are entering data wrongly, confirm that what they enter actually reaches the calculation, and that the in-app help describes the system as it really works.
Rules about money need guardrails, not just formulas. Settings that would produce nonsense should be impossible to save, incomplete records should say what is missing, and results that affect pay should be locked once confirmed. These guardrails usually come from the first months of real use, which is why we plan for a second iteration rather than treating launch as the end.
Build for the device and the person. Large touch targets, few fields per screen and automatic saving matter more on a warehouse floor than any visual polish.
Which service this is
This is a custom business app: one system shaped around how a specific company receives, produces and ships, instead of a generic product the workflow has to bend around. If your operation runs on paper forms and spreadsheets that do not talk to each other, this is the kind of problem the approach is for.
