Most logistics companies have a room they would rather you didn't see during a big sale week.
It's usually a conference room with the chairs pushed back. Someone has mirrored three dashboards onto the TV. There's a WhatsApp group with a few hundred unread messages, a whiteboard covered in hub codes, and a senior ops manager who has been awake for longer than anyone should be. When volume spikes, this room is where the network actually gets run: people spotting problems on screens and phoning someone to fix them.
The war room works, up to a point. The trouble is that it scales with headcount. Double the shipments and you need roughly double the people staring at dashboards, plus more coffee. Google's site reliability engineers have a name for this kind of work. In their chapter on eliminating toil, they describe manual, reactive work that grows linearly with the size of a service and argue that a well-designed system should be able to grow by an order of magnitude with no extra operational effort.
That idea sits close to the center of how Libera was built. The platform has now handled more than 5 billion shipments and generated over 97 billion tracking checkpoints, with 99.96% of deliveries on time. None of that runs through a war room. This post covers how it got there.
It started as somebody else's problem. Ours.
Libera wasn't designed as a SaaS product on a whiteboard. It began as the internal software ElasticRun needed to keep its own logistics network alive.
ElasticRun's network is unusual. Rather than owning a large fleet, it aggregates variable capacity: vehicles, warehouse space, and people contributed by local entrepreneurs who have those assets sitting partly idle. That makes the network cheap to expand. It also makes it hard to run. Capacity appears and disappears. A vehicle that was available on Monday is doing something else on Tuesday. Demand in smaller towns doesn't follow the neat patterns you see in metro e-commerce.
You can't run a network like that from a spreadsheet, and you can't run it from a war room either, because the problems are too small and too many. A war room is good at handling one big fire. ElasticRun had thousands of small ones every day.
So the engineering team built for that reality. The people writing the code worked alongside the people moving the goods, which is still true today. When something broke on the ground, it showed up in the software backlog within days, not quarters. A lot of Libera's design choices trace back to that loop. They weren't elegant architecture decisions. Someone on a dock somewhere was having a bad week, and the fix became a feature.
Every scan is a data point
The first major change to be introduced was to what the system would consider to be data.
Typically, logistics software will operate within the scope of a shipment: created, in transit, and delivered. Libera is different in that it models a shipment in terms of checkpoints. These can be the various events (scans, handovers, geofence crossings, sort-center inductions, etc.) that occur with a shipment, complete with a timestamp and a location. It is these events that lead to the 97 billion figure referred to earlier.
With so many checkpoints, the question of “where” is not nearly as important as other questions. Is this shipment moving slower than others on the same route? Did this shipment miss a handover? Is a particular hub building up a massive backlog that will impact first-mile pickups for tomorrow’s shipments?
The war room answers these same types of questions but relies on someone with experience to browse screens and get a bad feeling. Libera, however, continuously compares an event to the normal situation for all shipments and answers these types of questions. Your gut feeling still matters, though it's just no longer the initial detection method.
A control tower that decides what's worth looking at
Having all that data creates its own problem. If you show every exception to a human, you've rebuilt the war room with a nicer screen.
This is where Libera's Predictive Network Control Tower does most of its work. It doesn't try to show everything. It ranks. Out of hundreds of active trips on a given morning, it surfaces the handful genuinely at risk of breaching an SLA or a compliance window, orders them by urgency, and attaches a one-line reason to each. We wrote about this in detail in From 428 trips to 12 that matter, and the short version is that noise is the enemy. An ops lead who has learned to skim past fifty trivial GPS-gap alerts will eventually skim past the one that matters. The wider industry is arriving at the same conclusion. Logistics Viewpoints recently argued that exception management is becoming the new control layer of the supply chain, replacing visibility on its own as the thing that actually matters.
Getting this right took years of tuning, and honestly it still isn't finished. A brief signal drop in a low-connectivity area on a rural route is normal. The same drop on a high-value lane with a tight delivery window is not. Teaching the system that difference, lane by lane and season by season, is less glamorous than building a new dashboard, but it's what lets a small team supervise a very large network.
Capacity that stretches with the network
Detection is half the job. The other half is having somewhere to send the work when something goes wrong or volume jumps.
Plenty of capacity exists in Indian logistics these days. The hard part is having it in the right place at the right hour. Inc42's look at this year's festive delivery squeeze makes the point well: more riders, warehouses, and delivery partners have entered the market, but brands still struggle to line up inventory, pickups, and riders with demand at a specific pincode on a specific day.
Because ElasticRun's own network was built on variable capacity, Libera had to plan around capacity that changes daily. The capacity and route planning engine grew out of that constraint. It plans dispatch, assigns vehicles, and builds routes against the capacity that actually exists today, not a fixed fleet assumed in a planning sheet three months ago.
That same logic carries across every leg of a shipment's journey. Intelligent All Mile Logistics connects the first mile, middle mile, sort centers, and last mile into one flow, so a delay at a sort center automatically reshapes the last-mile plan downstream. In a war-room setup, that handoff happens when someone from sort-center ops remembers to message someone in last-mile ops. Here, the plan updates before anyone has to remember.
When a festive-season spike arrives, the system doesn't need a special mode. It keeps doing what it does every day, with more volume flowing through the same rules.
The boring layer underneath
Not pretty to look at, but if this crashes at peak time for you, that’s all the credit this dull stuff deserves.
Libera is a cloud-native, cloud-agnostic solution. In other words, the modular stack of services is horizontally scalable, and therefore more instances of a single service are added instead of increasing the power of already deployed machines. Most of the services are running on top of Kubernetes and are horizontally autoscaled. That means that if, for example, sort-center scans suddenly triple on a sale day, the services processing these scans will automatically increase in size to handle the new load, without anyone having to manually change any configuration.
This infrastructure is closely monitored by our Cloud Ops and Reliability Engineering team, CORE, using a wide variety of monitoring tools across the security, application, and infrastructure layers. As has already been mentioned, security is not an afterthought, and the entire platform is ISO 27001 certified with features such as network segregation, restrictive access controls, and data encryption in transit and at rest.
So, no, it’s not exciting. But then boring infrastructure means boring operations too, and that’s the highest compliment in logistics.
Where the humans still are
This sounds alarmingly like “the machines are running everything now," and we are inclined to be skeptical of anyone who says that about their operations.
The core principle we are building is that of a system: software does the monitoring, ranking, forecasting, replanning, and so on, while the execution of all that thinking is done by humans. The decisions that require a human brain (negotiating with a carrier, holding a consignment for a critical customer, etc.) are made by the person, and those decisions are then fed back into the system for use by the software.
The human choices and overrides can then be learned by the system, such as when a planner consistently overrides the system for a certain lane; this knowledge can then be used in subsequent planning rounds.
Why this matters beyond one network
Here's the part that surprised even us. The constraints that shaped Libera (thin margins, unpredictable capacity, huge volumes of small problems) turned out not to be unique to ElasticRun. They describe most of Indian logistics.
India's logistics costs came in at about 7.97% of GDP in 2023–24, according to the first official assessment by NCAER for DPIIT. That's closer to developed-economy levels than the old 13–14% estimate everyone used to quote. Getting the rest of the way depends less on building more war rooms and more on removing the manual work that eats into margins at every hub and handover.
That's why the same platform now runs operations for companies like Flipkart, Meesho, and IKEA. One of India's largest e-commerce platforms used it to scale to more than 4.8 million shipments a day. Another cut logistics costs by 35% while running around 3 million daily shipments. These businesses don't look like ElasticRun's network on the surface. Underneath, the problem is the same: too many moving parts for people to watch one by one.
The war room isn't a failure of effort. It's what happens when the software can't keep up and people fill the gap with long nights. Libera was built by a team that spent enough of those nights to want something better.