Orbis — A Delivery Brain That Never Stops Learning

The Week Everything Broke

It started with a week that still makes me uncomfortable to think about. We had shipped around two hundred orders to a small town. By the weekend, seventy of them had come back as returns. The courier company had stamped them with reasons like “customer not available” or “address not reachable”. None of it was true. Customers had been waiting, calling, sometimes even standing outside their homes. We had paid for shipping both ways, lost the sale, and lost trust.

That week I realised our biggest problem was not product or demand. It was logistics. The supply chain in India is brutal once you move beyond the metros, and no one was solving it for us. Courier partners were fast to blame the customer, but we were the ones left to carry the cost. If we wanted reliability, we had to build it ourselves.

That decision became Orbis.

Building for the Real World

I never wanted to build a “last mile optimiser” that only worked in theory. The goal was to build something that accepted the world as it is. A delivery system that understood a driver is a human being with shift hours, a limited pocket of cash, and a need to stop for lunch. A system that remembered a two wheeler cannot carry a fridge, and a van cannot always enter a narrow village road. A system that respected limits before it tried to be clever.

Starting Simple with JSON

The first experiments were scrappy. I made Orbis serverless and JSON driven. Orders came in as raw JSON, and the system sent back assignments and routes. No database, no dashboards, just agility. That choice gave me freedom to move fast. If tomorrow I discovered that cash in hand limits mattered more than I thought, I could add it without breaking a schema. If the next day shift hours became the constraint, I could fold that in too. Orbis evolved in real time with my understanding of the problem.

A Rhythm of Decisions

Over time a rhythm emerged. I started by clustering orders not by distance on a map, but by travel times from Google’s Distance Matrix. Two points that look close can be half an hour apart in traffic, and two points that look far can be five minutes down a highway. Using real travel times gave me clusters that felt natural.

From there I filtered by vehicle. Every order carries its own requirement, and every vehicle has a limit. That matching removed the silly plans before they started.

Assignments were made with a greedy approach, but always inside guardrails. A driver was never asked to carry more volume than his vehicle allowed, never pushed beyond his shift, never asked to handle more cash than was safe. Once a driver’s basket was ready, the stops were ordered again using real travel times, not straight lines. The aim was never a mathematically perfect tour. The aim was a plan a driver could actually follow without rolling his eyes.

Watching the Pulse

Around this core I started building the operator’s view. A dashboard that shows what is happening right now. How many orders are out, which clusters are always at risk, which drivers are approaching their cash ceiling, whether today’s plan is already slipping compared to yesterday. Not vanity graphs, but a pulse of the system that tells the truth fast enough to matter.

Where Orbis Stands Today

The repo already has the FastAPI backbone, the JSON schema, and early clustering and assignment logic. It is still early and still rough, but it is something. My plan is to keep refining. Hybrid clustering using DBSCAN with k-means, smarter assignment using metaheuristics, dashboards that tell richer stories. And once that foundation feels steady, pilots in the very regions where traditional couriers fail.

Always Under Construction

What excites me most is not the code, but the attitude. Orbis will never be finished. That is not a weakness. It is the strength. Cities change. Fleets change. Drivers change. Cash limits rise and fall. Customer behaviour shifts. Orbis is not meant to be a frozen product. It is meant to be a system that keeps learning.

In the future I want Orbis to use machine learning where it makes sense. Predicting false returns before they happen. Adjusting ETAs based on local history. Suggesting swaps that improve first attempt success. None of this is a single breakthrough. It is a rhythm of small improvements that add up over time.

Why This Matters to Me

For me this is personal. Every false return was not just a number in a spreadsheet. It was a broken promise to a customer. Orbis is my way of fixing that. It began as a response to my company’s pain, but I hope it can grow into something that helps many others who are fighting the same battle.