Container Trucking Dispatch Software: Case Study

Client name withheld. Last updated: 10 November 2026

This write-up is for operators, brokers and logistics teams comparing custom dispatch software with off-the-shelf tools. It describes the project plainly: what the system does, how its parts fit together, and what that means for your scope. It does not include before-and-after figures, because none have been approved for publication, and we would rather say so than invent one. For the wider picture of what we build for transport businesses, see our logistics software development work and our guide to custom logistics software development.

What a container trucking operator has to keep straight

A drayage operator moves containers between ports, yards and customers. Every load touches several things at once: a customer, a container, a truck, a chassis and a driver who is either on the payroll or an outside contractor. Each of them has its own rules. Drivers are paid in different ways, customers are billed for line haul, chassis days and waiting time, and the office needs to know where every load stands at any moment. The system had to hold all of this in one place.

What we built: three parts on one API

Keeping the rules in the API, not in each screen, means the office and the drivers work from the same data.

Load requests: a lifecycle the server enforces

Every load request moves through the same stages, and the server checks each status change. A load can also be cancelled from any stage. In the admin panel, staff create a request, approve the intake, set up the assignment and choose the driver in a two-step assignment wizard, then follow the load through to completion.

Drivers: company and third-party

The admin panel treats company drivers and third-party drivers as different types. Each driver has documents, contracts and rates, with a rate history, and staff can activate or deactivate a driver or reset a password.

Containers, trucks and chassis

Containers, vehicles and chassis are kept as their own records, so a load is tied to the equipment it uses. The system also supports chassis pricing, and an invoice can include chassis days.

Billing: invoices built from the load

Staff create an invoice from an eligible load. The invoice fills itself with a line haul line, and adds chassis days and waiting (detention) hours when the load has them. Invoices are numbered automatically each year, each load can have only one invoice, and the server recalculates the totals every time. An invoice moves through sent and paid, can be cancelled until it is paid, and is locked once it is paid.

Driver costs and weekly pay

Outside (third-party) drivers are paid per load. When a cost record is created, the driver’s rates are copied into it, so a later rate change does not rewrite old costs. Waiting time beyond the complimentary hours is charged at an hourly rate, a cost goes through approved and paid steps, and a paid record cannot be changed.

Company drivers are paid weekly. Because drivers are paid in different ways, it supports five pay models: a flat hourly rate, an hourly rate with weekly overtime, a weekly salary with daily overtime, pay per move, and a daily guarantee with daily overtime. Overtime is calculated and shown, but it is only added to the total once it is approved. Four of the five models are verified in live use. The per-move model is built but is not yet used for real payroll.

The driver app

Drivers sign in with a code sent by SMS and get a push alert when a load is assigned. The app has a task list and a task detail screen, a navigation sheet, a chassis pickup step, pickup and delivery proof with photos and a signature, delivery history, earnings screens, an expense form, documents and alerts.

Where it stands today

The first phase is live with the client: the admin panel and the API are in production use. The driver app is in internal testing and is not in a public app store yet. We have not published user counts, load volumes or time-saved figures, because none have been approved.

Design decisions you can reuse

• Let the server enforce the lifecycle and the money rules. Status changes, invoice totals and pay calculations are checked in the API, not left to each screen.
• Copy rates into a cost when it is created. A later change to a driver rate then cannot quietly rewrite a cost that has already been approved.
• Make pay models explicit. One overloaded field cannot express how every driver is paid. Separate models keep a weekly hours allowance from being confused with a per-day rule.
• Lock what is final. Paid invoices and paid driver costs cannot be edited, which keeps the records trustworthy.
• Keep one record for each real thing. Customers, drivers, containers, trucks and chassis each have their own record, and loads link to them.

What this means for your project

If you run a trucking or drayage business and are weighing a custom build, the work that decides cost and success happens before any code. Write these down first, and any developer, including us, can give you a much sharper scope:

1. Your load stages and who is allowed to change each one.
2. Your driver types and exactly how each one is paid, including overtime.
3. What goes on an invoice: line haul, chassis days, waiting time, any other charges, and who approves it.
4. The equipment you track: containers, trucks, chassis, and what you need to know about each.
5. What drivers must do in the app: proof of pickup and delivery, documents, expenses.
6. Who needs admin access and what each person should be allowed to see.

If your drivers already use another tool, the office-side admin panel and API can be scoped first and the driver app added later. If you are a smaller operator, start with the stages, the invoice and the pay rule you use most, and add the rest after the office is using it. We build the web admin panel and the driver mobile app as one project, and you can see the wider approach on our enterprise software solutions page.

Questions buyers ask