This is an illustrative planning example assembled from common regional-carrier requirements. It is not a client case study, testimonial or outcome claim.
Project snapshot
- Example business
- Regional US truckload carrier with company drivers and owner-operators
- Problem
- Legacy desktop TMS and spreadsheets slowed EDI onboarding, owner-operator settlements and customer visibility.
- Modules
- Load management, dispatch board, billing, EDI 204/990/214, driver mobile app, owner-operator settlement, customer portal, operational reporting
- Stack
- Node.js on ECS Fargate, PostgreSQL (RDS), Redis, EDI worker (SQS), S3, CloudWatch, Terraform, React Native driver app
- Illustrative phases
- Phase 1 load and dispatch workflow → Phase 2 driver app and settlements → Phase 3 portal and additional approved EDI partners
- Intended workflow changes
- Reduce re-keying, establish one operational record, capture mobile status/POD and produce settlement exports
Example operating scenario
Consider a regional truckload carrier running a mixed fleet of company drivers and owner-operators, serving recurring lanes and spot freight. A small internal team supports billing and approved telematics integrations.
Example challenges
In this scenario, dispatch relies on a legacy desktop TMS supplemented by spreadsheets and email. Likely pain points include:
- Slow onboarding of new EDI shippers — each partner required manual re-keying when automated tender failed
- Owner-operator settlement calculations done outside the TMS, causing billing cycle delays and disputes
- No unified driver mobile workflow — status updates came by phone, delaying customer 214 notifications
- Limited visibility for customer service on in-transit loads
A team in this situation might compare a configurable packaged TMS with a scoped custom first phase. The decision should consider implementation, customization, vendor and ongoing operating costs rather than assuming either option is cheaper.
Illustrative phased approach
One possible phased plan on AWS is:
- Phase 1 (MVP): Load management, dispatch board, basic billing, EDI 204/990 for two primary shippers, admin roles
- Phase 2: Driver React Native app with ePOD and status events feeding 214 generation; owner-operator settlement module
- Phase 3: Customer portal for selected accounts, additional EDI partners, operational reporting
Architecture: Node.js APIs on ECS Fargate, PostgreSQL on RDS, Redis for job queues, dedicated EDI worker service with SQS dead-letter handling, S3 for documents, CloudWatch observability. Infrastructure defined in Terraform.
Intended workflow checks
A pilot should verify whether the agreed workflows achieve the following, without assuming business outcomes in advance:
- Approved EDI tender flows can be processed and exceptions are visible
- Dispatch and billing roles can use the agreed record for open loads
- Drivers can submit status and POD while authorized staff can access the same timeline
- Settlement exports match the documented accounting workflow and test cases
Any parallel-run period, cutover criteria and post-launch support window must be stated in the project plan.
Lessons for Similar Projects
- Invest in EDI idempotency and partner-specific mapping early — logistics EDI is never "standard"
- Align settlement rules with finance before UI work — edge cases surface in owner-operator deductions
- Phase driver app after core dispatch stabilizes, but design load status model upfront for 214 compatibility