Custom software development for processes that are not standard

1. 01
   No off-the-shelf product handled the partial return

   Delivery systems treat a stop as yes or no: signed or not signed. Here the person receiving can reject part of the order at the door —damaged boxes, a count that does not match the order— and what comes back decides three different things: what gets dispatched again, what gets invoiced to the client and what gets paid to the driver. With a packaged tool that ended up written in the notes field, and somebody retyped it into a spreadsheet on Monday.

2. 02
   The first release covered only that circuit

   Rather than replacing the whole operation, we scoped the first version to what depended on the partial return: recording on the phone what came back and why, and having the driver settlement and the invoicing summary come out of that. Route planning was deliberately left out and kept running on what they already used. It went live in one depot, with the drivers of that zone, and the rest came later.

3. 03
   Three screens, one per role, and everything else stayed put

   The driver sees the day’s trip and closes each stop marking line by line what was delivered and what is coming back, with a reason picked from a fixed list. The operations desk sees the stops that closed with a difference and decides whether to dispatch again. Administration sees the settlement per driver for the period and the summary per client. Each role gets its own screen and not the others, instead of the shared spreadsheet everyone used to open. Orders are still pulled from the client’s system by file or API, and the summary is sent to the accounting system they already had: we replaced nothing that worked.

4. 04
   What changes often changes without code

   Zone rates, return reasons and each client’s rules are loaded from an admin screen: adding a new client means loading its rules, not asking for development. There is a short document explaining every screen, every state and what happens when a stop closes with a difference. Improvements go into a list that gets ordered once a month: whatever blocks today’s operation goes in, the rest waits.

The same mechanics fit any operation where the work does not end in yes or no: a lab where a sample has to be run again, a builder certifying partial progress on site, a service call that leaves equipment half working. The vocabulary and the states change, the way it is built does not.