Web Application

Montes del Acebo — APPCC

From “where is this batch?” to knowing in seconds. A traceability system that ties every lot from the truck that delivers it to the business that receives it — a live view of stock, and reliable, reachable information in place of a shared spreadsheet.

  • Angular
  • Spring Boot
  • Java
  • PostgreSQL
  • Docker
  • Jenkins
  • OpenAPI

A while back a client got in touch — a food distribution business. The problem wasn't hard to name: too much paper, and too many places to look. Orders came in over WhatsApp, got confirmed by phone, corrected by a text an hour later, and half of the state of the business lived in someone's head. Nobody could say with certainty where anything was.

The day ran on questions a system should have been answering. Did we order the chicken for Thursday? How much of Monday's batch is left? Which client got the last of lot 90? Has that delivery gone out yet? Every one of them was a phone call, an interruption, and a few minutes lost — multiplied across everyone on the floor.

One page, every field, all at once

After the first meeting, the client handed me his vision of the product: one screen, every piece of data entered in a single pass — supplier, prices, lots, temperatures, weights — top to bottom, one form.

The client's own sketch: receiving, stock, processing splits, and staff roles, all flowing through a single sheet.

To him, that was the obvious shape for it. To me it was a serious mistake — and I told him so.

Why one giant form doesn't hold up

He kept pushing for it, so instead of arguing I built a throwaway prototype of that exact idea and put it in front of him. The point was to make the problem concrete. Did it really make sense for the person receiving a pallet at the loading dock to be typing in purchase prices and VAT while they logged the lots that had just arrived? In the same form? Under the same permissions as the office?

That first version worked, technically. It also fused receiving with accounting, showed every role every field, and turned a thirty-second task into a screen you had to scroll.

The first prototype — one flow for everything: receiving, pricing, processing, sales, and stock, packed into the same handful of oversized forms.

Defining what the app actually had to do

So we kept talking, and this time we pinned down the real job. Not "digitize the paperwork" — something narrower and more useful: know when something arrived, what was done with it, and who it was sold to. Record the temperature and the condition on the way in and on the way out. Keep every expiry date attached to its lot.

From there the feature list wrote itself:

  • Full traceability for any lotSupplier, every processing split, every buyer — reconstructed from a single search.
  • Expiry alertsA warning before a lot goes out of date, not a discovery after it already has.
  • Real-time inventoryAvailable, reserved, and in-transit stock, updated as each movement touches it.
  • Automatic delivery notesGenerated from the movement itself, not retyped into a separate document.
  • Entries, exits, and processing splitsThe three operations that actually change what's in the cold room.
  • Granular, role-based permissionsEach worker sees only their part of the app — which is also what keeps it simple to use.

And a scope cut that made the first version much smaller: no pricing. A colleague already ran the commercial side well on her own, and all the system needed to do was let her tie each entry and exit to a delivery-note number. Everything about money came out.

The prototype that solved it

With that settled, I rebuilt the prototype around the real workflow and walked him through it. You can try that version yourself in the live demo. Each screen answers one of the questions that used to cost a phone call.

“Where is this batch?”

Search a lot number and the system rebuilds its whole history: which supplier it came from, every split it went through, and every business it ended up at. That answer used to live across an invoice, a butchery logbook, and a stack of delivery notes. Now it's one field.

One lot number in, its entire genealogy out — purchase, every split, every sale.

“Did it arrive in good condition?”

Every delivery is logged against its purchase order: temperature on arrival, a food-safety checklist, the lot numbers on the pallet, and the delivery-note number. Nothing enters inventory until that record exists, and the receiving report downloads as a PDF straight from the screen.

Temperature, checklist, lot numbers, and delivery note — captured the moment the truck is unloaded.

“It's been split — what now?”

Processing is where traceability usually breaks: a lot goes into a room and comes out as a dozen products. Registering a split divides the parent lot's weight across those products, and each new lot carries the parent's history forward. That's why the search in the first screen can fan out instead of stopping at the butchery door.

One lot of whole chicken, broken into wings, breasts, thighs, and bones — each output still traces back to the source.

“What's free to sell?”

Available, reserved, and in-transit weight for every product, updated the instant a purchase, a split, or a sale touches it. No more counting a cold room by hand to find out what you can actually commit to a client.

Stock as a number you can trust, product by product, in real time.

“What went out, and how?”

Dispatch mirrors receiving: temperature, the same checklist, expiry dates per lot, a box count, and a timeline from created to prepared to delivered. If a client calls about a batch six months later, the answer is already on screen.

The same rigor going out as coming in — plus a full timeline of who prepared and delivered it.

From the first login to a working MVP

He wanted to start using it as soon as there was something to use, so I leaned on infrastructure I already run — Albgott, my own private cloud. That skipped the usual friction of choosing a host, comparing prices, and wiring up a pipeline. I gave the project its own isolated network, handed him a set of credentials, and from day one he could watch it being built. The moment it reached a minimum viable version, he was working on real data.

It's a small system by scale. But it does the one thing a food distributor needs software to do: nothing gets lost, and nothing takes longer to find than typing in a lot number.