Order and Dispatch Platform Rebuild

The operator ran order intake, routing and proof-of-delivery through a single application that had been extended for about eleven years. Any change to dispatch risked breaking invoicing, so releases had slowed to roughly one a quarter and most of the team's time went to regression fixes instead of new work. The business wanted to onboard third-party couriers, but the data model assumed every driver was an employee, so each new courier arrangement turned into a two-sprint code change. The brief was to get to a shape where onboarding a courier was configuration, not code, without a cutover that would stop deliveries.

I was the technical lead, sitting between the client's operations manager and a team of six engineers — four from our side, two from theirs. I didn't manage anyone formally; I owned the architecture, the sequencing, and whatever went wrong at 2 a.m. I also ran the weekly session where we walked the operations supervisors through what was moving next, which turned out to matter as much as the code did. Toward the end I spent more time on the cutover runbook than on anything I'd call engineering.

I designed the service boundaries and wrote the order and dispatch services myself, along with the outbox mechanism everything else read from. I owned the migration path — a proxy in front of the old application, route-by-route cutover, and a nightly reconciliation job that compared old and new order state for the first four months. I wrote the deployment pipeline and the Terraform for the new environments. I deliberately stayed out of the invoicing side; a colleague who actually understood the finance rules kept that, and every time I was tempted to touch it I asked them instead.

The biggest decision was refusing an event-sourced design that two of us wanted. It fit the audit requirements better, but nobody on the team had operated one before and we were already replacing every deployment habit they had, so I took a plain relational model with an outbox table and accepted a weaker audit story. I also kept order-to-dispatch synchronous over HTTP rather than putting a queue between them, because a supervisor pressing dispatch needs an immediate yes or no and a queue would have meant inventing a pending state the operations team would have to reason about. Queues went only where latency genuinely didn't matter — notifications, document generation, analytics feeds.

Nothing could stop for a cutover. The operator runs seven days a week and an hour of downtime is real parcels sitting in a warehouse. The finance team read directly from the old database for month-end close, so every write had to land in both systems for the whole transition, which is where most of our bugs came from. Budget capped us at two environments, so staging doubled as the pilot region's production for about six weeks — it worked, and I still wouldn't do it again.

We cut over the last region fourteen months in. Two incidents reached customers, both in the first quarter and both from the reconciliation job rather than the services themselves. Release frequency went from roughly one a quarter to about twice a week by handover. Courier onboarding became a form the operations team fills in; they did four in the month after we left without asking us anything. Order search, which had been the supervisors' loudest complaint at eight to twelve seconds, settled around 400 ms.

Two engineers on the client side did most of the proof-of-delivery work and knew the domain far better than I did — a good part of my design was really them telling me what actually happens in a depot at 5 a.m. Their operations manager co-wrote the cutover runbook and ran the pilot region herself. We had a contractor for three months on the reporting feeds who I mostly left alone, which in hindsight cost us two weeks of rework.