QuickShip
Logistics

The challenge

Planning ran overnight. Dispatchers submitted the next day's loads, a batch job chewed on them for hours, and the routes that came back assumed nothing would change — which was never true by 9am. Every cancellation, breakdown, or late pickup was then patched by hand over the phone.

There was already a platform. It worked, it held years of business logic, and replacing it wholesale was not on the table.

What we did

We started with two weeks in the existing codebase and a day in the dispatch room. The plan that came out of it was strangler-fig, not rewrite: extract the planning engine, leave everything else running.

• A codebase and architecture review, delivered as a written plan the client's team signed off on before we wrote code.
• The routing engine extracted into its own service, so it could be optimised without touching the monolith.
• Incremental re-planning: a disruption re-solves the affected routes in seconds instead of re-running the whole batch.
• A live dispatcher interface — drag a load, see the cost and ETA impact immediately.
• A CI/CD pipeline and test harness the in-house team kept using after we left.

What shipped

Planning moved from an overnight batch to a tool dispatchers use continuously through the day. Routes re-solve as reality changes, and the dispatcher sees the trade-off before committing rather than discovering it at 4pm.

Results

The carrier's own numbers put planning time at roughly a third of what it was. Just as importantly, their engineers own the new service — we wrote it in their conventions, in their repos, reviewed by them.

Working together

This is the shape of project we get asked about most: an existing system, an existing team, and no appetite for a rewrite. We work in your repos, your conventions, and your ticketing system, and every pull request goes through your review process. The FAQ has more on how we join existing teams.