When the concrete arrives in the wrong order, the whole site stops
A system that shows the site manager where every delivery is right now and what is coming through the gate in the next hour.
A large construction site can take dozens of deliveries from a dozen suppliers in a single week. Rebar, precast elements, concrete, windows, pipework. Each one takes space, a crane and people. If two arrive at once, or in the wrong order, one waits, the other blocks the gate, and a crew stands idle.
What it looked like before
The site manager knew what had been ordered. He did not know what would actually turn up today. Delivery slots were agreed by email and phone, often a day ahead, sometimes an hour ahead. Suppliers confirmed times they did not always keep, and news of a delay arrived when the truck was already at the gate.
The consequences are the same on every site. Material unloaded wherever there is room, then moved a second time. Crews waiting for something that is already on site, except nobody knows where. Damage from repeated handling. And a safety risk, because a forklift and a concrete mixer meet in a narrow passage.
Our client, a company specialising in construction logistics, had the idea and needed a team to turn it into a working product.
What we built
A booking and tracking system in which the site is a plan, not a list of rows.
Time-slot booking. The supplier books a specific window and a specific unloading point. A clash shows up at booking time, not at the gate.
Site view. The manager sees unloading zones and access routes on a plan, with what occupies them at a given hour. Two deliveries competing for the same spot surface during planning.
Tracking down the supply chain. Every ordered item is visible throughout: ordered, in transit, on site, installed. “Where are those windows” stops requiring three phone calls.
Event history. Every rescheduling, delay and unloading is recorded. When a delay is disputed later, there is a record rather than two conflicting recollections.
What changes day to day
The value is not that the system knows more than the site manager. It is that it knows it at the same moment he does, and shows it to everyone at once – supplier, manager, foreman.
Two things make the difference. Reality meets the plan before the truck leaves, because moving a delivery by two hours in the system costs a click while moving a truck at the gate costs half a day. And there is a record of who booked what and when it actually arrived. On a site where every delay later acquires its own version of events, that is evidence rather than opinion.
We do not have measured savings from the client and we are not inventing any. In our experience at this scale the gain comes from two places: fewer idle crews and less material shuffled around the site.
Why we built it this way
A system like this outlives any single site, and the rules change along the way: different zones, different delivery types, different roles. So the application is built around events – booked, rescheduled, unloaded – rather than around tables holding the current state. Adding a rule does not mean rebuilding what already works, and every question about the past has an answer in the data.
Show the technology stack
- NestJS
- TypeScript
- TypeORM
- RxJS
- CQRS
- DDD
- Swagger
- Jest