How to build a transportation management system: requirements, architecture and cost

Transportation management system requirements

Transport management system requirements vary by operating model, shipment volume, transportation modes, user roles and integration landscape. Requirements should therefore describe both what the TMS must do and how the business will verify that each capability works correctly.

Avoid requirements such as:

The system should have real-time tracking.

That statement leaves too many unanswered questions.

A stronger requirement is:

Operations users must be able to see the latest normalized tracking event for every active shipment, including the event occurrence time and source.

It can then be tested.

Functional requirements

Functional requirements describe transportation capabilities.

Common examples include:

• ingest transportation orders;
• create and split shipments;
• consolidate shipments into loads;
• maintain carrier contracts and rates;
• compare eligible carriers;
• tender loads;
• dispatch vehicles or external carriers;
• process tracking events;
• identify operational exceptions;
• capture proof of delivery;
• audit carrier invoices;
• generate operational reports.

Non-functional requirements

These determine whether the system remains usable and reliable under real operating conditions.

Examples include:

• security and access control;
• auditability;
• tenant isolation for SaaS platforms;
• integration reliability;
• data retention;
• availability requirements;
• peak workload;
• recovery expectations;
• browser/mobile requirements;
• observability.

Do not invent arbitrary performance targets.

A large-volume shipper might need a very different event-ingestion capacity from a regional distributor.

Set thresholds from expected operational volumes plus an agreed margin.

Data ownership and integrations

Every major field should have an identified system of record.

For example:

Without these boundaries, two systems may begin modifying the same operational state independently.

Use acceptance criteria

A useful requirements format is:

That is considerably more useful to developers and testers than a generic feature list.

After documenting these requirements, businesses evaluating a custom platform can discuss their current workflow and systems with a logistics and transportation software development team before committing to architecture.

Which modules should your custom TMS include?

Not every company needs every TMS module in the first release.

A useful way to scope development is to separate MVP, later-phase and business-dependent functionality.

An MVP should complete an operational journey.

For example:

Order → Shipment → Carrier assignment → Dispatch → Tracking → Exception handling → Delivery → POD

That creates something operations can actually test.

Ten partially implemented modules do not.

How to build a transportation management system step by step

For teams planning transportation management application development, the process should move from operational discovery to system boundaries, data modelling, integration validation, an end-to-end MVP and controlled rollout. A disciplined TMS software development process reduces the risk of building isolated features before the core transportation workflow works reliably.

1. Discover the real transportation workflow

Do not begin by asking stakeholders which features they want.

Observe how freight actually moves.

Document:

• order sources;
• planners;
• dispatchers;
• carrier communication;
• spreadsheets;
• manual approvals;
• driver workflows;
• billing;
• exceptions.

Deliverable: current-state workflow map.

Exit criterion: the team understands how a shipment moves from demand through delivery and settlement.

2. Define system boundaries

Decide what belongs in the TMS and what remains elsewhere.

Examples:

• ERP owns commercial orders and finance;
• WMS owns warehouse execution;
• TMS owns shipment planning and execution;
• telematics platform owns raw device data.

Deliverable: system ownership matrix.

Exit criterion: important fields have one clearly defined source of truth.

3. Model the transportation domain

A reliable TMS normally distinguishes:

Order → Shipment → Load → Stop

These are not synonyms.

An order describes business demand.

A shipment represents freight that needs to move.

A load represents freight grouped for physical execution.

A stop represents pickup, delivery, cross-dock or another physical activity.

This separation is important because:

• one order may be split into several shipments;
• several shipments may share a load;
• a load may contain multiple stops.

A simplified model looks like:

Customer
   ↓
Order
   ↓
Order–Shipment Allocation
   ↓
Shipment
   ↓
Shipment–Load Allocation
   ↓
Load
   ↓
Stops
   ↓
Carrier / Vehicle / Driver
   ↓
Tracking Events
   ↓
Exceptions
   ↓
POD
   ↓
Freight Invoice

Deliverable: domain/entity model and terminology glossary.

Exit criterion: product, engineering and operations use the same definitions.

4. Prototype dispatcher and operations workflows

Before building production screens, test the workflows operators use most.

Examples:

• create shipment;
• assign carrier;
• review exceptions;
• change vehicle;
• resolve a failed delivery.

Focus on operational decisions, not visual polish.

Deliverable: interactive prototype.

Exit criterion: users can complete high-priority tasks without major structural confusion.

5. Prove risky integrations early

A legacy ERP or poorly documented carrier interface can create more project risk than the frontend.

Validate uncertain integrations early.

A proof of concept may answer:

• Can we retrieve usable carrier rates?
• Can the ERP publish the required order fields?
• Does the telematics provider expose historical events?
• Can an external optimization service model our constraints?

Deliverable: integration PoC or validated technical findings.

Exit criterion: major external dependencies are understood well enough to estimate.

6. Build one complete workflow

Develop the smallest end-to-end operational path.

Do not build twenty dashboards while shipment execution remains incomplete.

Deliverable: usable MVP.

Exit criterion: a real test shipment can move through the complete intended lifecycle.

7. Test failure scenarios

Test the system when:

• the carrier rejects a tender;
• an API times out;
• the same webhook arrives twice;
• tracking stops;
• a driver loses connectivity;
• an invoice differs from the agreed rate.

Deliverable: tested exception and recovery workflows.

Exit criterion: important failures are visible and recoverable.

8. Migrate data and pilot

Use a controlled operating scope.

That could mean:

• one depot;
• selected carriers;
• selected customers;
• limited lanes.

Deliverable: live pilot.

Exit criterion: operations can use the system without unacceptable manual workarounds.

9. Monitor and expand

Use production evidence to decide what comes next.

Deliverable: prioritized enhancement roadmap.

Exit criterion: later phases are based on observed needs rather than an arbitrary feature list.

TMS architecture for reliable, scalable operations

A web-based transportation management system may expose dispatcher, operations, customer and administrator workflows through browser applications while APIs, background workers and event-processing components handle integrations and transportation events. The TMS platform should be designed around actual workload and failure patterns rather than unnecessary architectural complexity.

A practical architecture might look like this:

ERP / OMS / eCommerce / WMS
              ↓
      Integration layer
              ↓
 Canonical transportation model
              ↓
        TMS application
     ┌────────┼────────┐
  Planning  Rating  Tendering
     │          │        │
  Loads      Carrier   Dispatch
     └──────────┼────────┘
                ↓
      Carrier APIs / EDI
                ↓
 GPS / telematics / driver app
                ↓
         Event processing
                ↓
    Tracking / exceptions
                ↓
 Operations / customer portal
                ↓
       ePOD / settlement
                ↓
       Analytics / finance

Use a canonical internal model

External partners often describe the same concept differently.

For example:

Carrier A: OUT_FOR_DELIVERY
Carrier B: OFD
Carrier C: VEHICLE_DEPARTED

Your platform can normalize them into:

OUT_FOR_DELIVERY

That prevents carrier-specific rules from spreading into dashboards, notifications and billing.

Modular monolith vs services

Microservices are not automatically the best architecture.

A modular monolith may be preferable when:

• one team owns development;
• the product is relatively early;
• workload is manageable;
• domain boundaries are still changing.

Logical modules might include:

orders
planning
rates
carriers
tracking
billing
identity

without deploying each separately.

Services become more useful when a domain needs:

• independent scaling;
• independent deployment;
• stronger failure isolation;
• separate team ownership.

For example, high-volume telematics ingestion may justify its own independently scalable processing layer long before ordinary shipment management does.

What supports large-volume shippers?

There is no single “best scalable TMS architecture.”

Evaluate whether the architecture can handle your specific:

• orders per hour;
• active shipments;
• carrier rate requests;
• tracking events;
• GPS event frequency;
• concurrent operations users;
• reporting workload.

Scaling should follow measured bottlenecks.

ERP, WMS, carrier API and telematics integrations

Integration design is often where custom TMS projects become difficult.

Design retries carefully

Do not retry every failure.

A timeout or temporary server error may succeed later.

Invalid credentials or malformed requests usually need correction rather than repeated calls.

Microsoft’s guidance on transient fault handling explains why retries should distinguish temporary failures from persistent ones.

Make important operations idempotent

Suppose a carrier booking request times out after the carrier actually created the booking.

Blindly retrying could create another shipment.

Use an idempotency mechanism where the partner/interface supports it and protect your own downstream workflows from duplicate processing.

The same principle applies to webhooks.

Replaying an identical DELIVERED event should not create:

• another customer notification;
• another invoice action;
• another delivery record.

Track occurrence time separately from receipt time

Imagine a driver’s app records delivery at 14:03 but reconnects at 14:31.

The system should retain both:

event occurred: 14:03
event received: 14:31

Otherwise offline execution can distort SLA reporting and operational analytics.

Reconciliation still matters

Event-driven integrations do not guarantee that every event arrives successfully.

Periodically reconcile important active records against source systems where appropriate.

Driver apps, offline workflows and proof of delivery

Field execution introduces different constraints from browser-based dispatch software.

Driver functionality may include:

• assigned jobs;
• stop sequence;
• navigation;
• pickup confirmation;
• status updates;
• photos;
• signatures;
• OTP;
• proof of delivery.

Where connectivity is unreliable, offline support needs deliberate state management.

A useful pattern is:

Download assigned work
        ↓
Store required data locally
        ↓
Capture events/documents offline
        ↓
Queue pending changes
        ↓
Connectivity returns
        ↓
Synchronize idempotently
        ↓
Resolve conflicts

The driver application must answer:

• What can be done offline?
• How long can data remain local?
• What happens if dispatch changes the job meanwhile?
• How are large photos uploaded?
• What happens if the same action is synchronized twice?

A purpose-built mobile app development approach can be appropriate where driver workflows are a major part of the transportation platform.

Connected fleet operations may also require IoT development for GPS, telematics or other devices.

How much does custom TMS development cost?

There is no credible universal price for a custom transportation management platform.

The cost should follow the scope.

One-time project costs

Estimate separately:

Recurring costs

Do not confuse development cost with ongoing software operation.

Recurring expenses can include:

• cloud infrastructure;
• mapping/routing APIs;
• SMS/notification services;
• carrier/partner APIs;
• observability;
• support;
• maintenance;
• future enhancements.

A simple estimating worksheet

Instead of asking:

“How much does a TMS cost?”

document:

Users:
Dispatchers, drivers, customers, finance, administrators

Modules:
Shipment management, rating, tendering, tracking, ePOD, audit

Integrations:
ERP, WMS, eight carriers, telematics

Platforms:
Web portal + driver mobile app

Volume:
Expected shipments and events

Migration:
Historical records to import

Special requirements:
Offline use, tenant isolation, optimization

That gives an engineering team something concrete enough to estimate.

How long does TMS development take?

Development time depends more on uncertainty than on the term “TMS.”

The main schedule drivers include:

• discovery complexity;
• availability of stakeholders;
• number of external integrations;
• quality of API documentation;
• carrier onboarding;
• legacy data;
• routing/rating complexity;
• mobile/offline requirements;
• UAT;
• operational rollout.

A project with one ERP and three modern carrier APIs is very different from one involving:

legacy ERP + EDI + dozens of carriers + telematics + mobile apps + freight settlement

A meaningful timeline should be produced after major dependencies have been validated.

Testing, migration and operational rollout

TMS testing must include more than successful shipments.

Test normal workflows

Verify:

• order import;
• shipment creation;
• planning;
• carrier assignment;
• dispatch;
• delivery;
• settlement.

Test operational failure

Simulate:

• rejected tender;
• no carrier rate;
• API timeout;
• duplicate tracking event;
• delayed event;
• lost driver connectivity;
• missing POD;
• invoice mismatch.

Test permissions

Verify:

• customers see only their data;
• dispatchers cannot change finance-only settings;
• finance users have appropriate invoice access;
• tenant data remains isolated where applicable.

Test peak workloads

Use realistic assumptions for:

• order imports;
• concurrent rate requests;
• tracking events;
• dashboard activity.

Plan migration explicitly

Before cutover:

1. identify required historical data;
2. map old-to-new fields;
3. clean invalid records;
4. perform trial migrations;
5. reconcile totals;
6. plan rollback;
7. schedule production migration.

Roll out gradually where risk justifies it

Start with a controlled part of the operation and expand once the workflow is stable.

Where AI and automation add value

Automation does not automatically require AI.

An automated transportation management system should use predictable business rules for deterministic decisions and reserve AI or machine learning for problems where the data and evaluation process justify it.

Many transportation decisions are better implemented as deterministic rules.

Examples include:

IF carrier cannot serve destination
THEN exclude carrier

or:

IF tender unanswered after defined window
THEN offer to next eligible carrier

Optimization also does not necessarily mean machine learning.

Route planning can use constraint-based optimization.

Where predictive AI may help

When sufficient historical data exists, possible applications include:

• ETA prediction;
• exception risk;
• demand forecasting;
• carrier-performance prediction.

Where generative AI may help

Possible examples include:

• interpreting logistics documents;
• summarizing operational exceptions;
• assisting support teams;
• extracting structured information from unstructured text.

AI outputs that affect important operational or financial actions should have:

• evaluation criteria;
• monitoring;
• appropriate human review;
• fallback behavior.

Pavans Group’s AI development work is relevant where AI is a justified component of the wider logistics platform rather than a substitute for reliable transportation data.

Worked example: a hypothetical
shipper

Consider a fictional distributor operating two warehouses and using several contracted road carriers.

A customer order contains 20 pallets.

Twelve pallets are available in Warehouse A and eight in Warehouse B.

Step 1: order intake

ERP sends the order to the transportation platform.

The TMS creates two shipment requirements because inventory is split between locations.

Step 2: load planning

Shipment A shares a destination and delivery window with two other shipments.

The planner consolidates them into one load.

Shipment B remains separate.

Step 3: carrier selection

The TMS checks:

• serviceability;
• equipment;
• contract rate;
• available capacity;
• delivery SLA.

The preferred carrier receives the first tender.

Step 4: booking and dispatch

The carrier accepts and returns its external shipment reference.

The TMS records both its internal load ID and the carrier ID.

Step 5: delayed tracking event

The carrier reports pickup normally.

A later in-transit message arrives 35 minutes after it actually occurred.

The TMS stores:

occurrence time: carrier timestamp
receipt time: platform timestamp

and does not incorrectly calculate the transit duration from receipt time.

Step 6: proof of delivery

The driver captures:

• delivery timestamp;
• receiver name;
• signature;
• photo.

The POD becomes available to operations and the customer.

Step 7: freight invoice

The carrier invoice includes an additional waiting charge.

The TMS compares:

contracted rate + valid accessorials → expected amount

against:

invoice amount

The waiting charge does not match available execution evidence, so the invoice enters a discrepancy workflow.

This example demonstrates why TMS development involves a connected operational model rather than independent shipment, tracking and billing screens.

KPIs to define before development

Software features are easier to prioritize when the team knows which operational measures matter.

Define the exact numerator, denominator, exclusions and baseline before claiming that software has improved a KPI.

A TMS may create the conditions for improvement; it cannot guarantee a fixed percentage outcome.

Lessons from Pavans Group logistics projects

Real logistics products demonstrate why integration and field execution need to be considered early.

Evership: normalize carrier differences

The Evership shipping platform case study documents functionality including:

• order synchronization;
• multi-carrier rate comparison;
• labels;
• shipment APIs;
• tracking APIs and webhooks;
• fulfillment workflows.

The broader engineering lesson is that a multi-carrier platform benefits from an internal model that does not expose every carrier’s terminology throughout the product.

Carrier-specific formats should be translated into consistent internal concepts.

Evership should not be treated as proof that every logistics platform requires identical functionality, but it is useful evidence of multi-carrier integration challenges.

Molo: offline delivery is a synchronization problem

The Molo last-mile delivery case study documents a delivery-agent application, management portal and offline-capable field workflows.

The useful lesson is that “offline mode” cannot be added only at the UI layer.

The architecture must define:

• what is stored locally;
• which actions can happen offline;
• how events are queued;
• how synchronization resumes;
• how conflicts and duplicate updates are handled.

Molo is not presented as a full enterprise TMS; it demonstrates the field-execution problems that can form part of transportation software.

How to scope your TMS project

Before requesting a detailed estimate, document the following.

Operating model

• shipper, 3PL, carrier, broker or product company;
• owned fleet, outsourced carriers or both;
• road, parcel, multimodal or other modes.

Transportation scale

• shipments per day/month;
• number of sites;
• number of carriers;
• active vehicles/drivers;
• expected tracking-event volume.

Current systems

• ERP;
• WMS;
• OMS;
• accounting;
• telematics;
• current TMS;
• carrier portals.

Biggest workflow problems

Examples:

• manual rate comparison;
• repeated data entry;
• unreliable tracking;
• poor exception visibility;
• difficult freight reconciliation.

Integrations

List every known:

• API;
• EDI relationship;
• file exchange;
• connected device;
• mobile workflow.

Migration

Define what historical data needs to move.

Project ownership

Identify who owns:

• product decisions;
• logistics operations;
• IT/security;
• finance;
• final acceptance.

A clear project brief produces a more useful technical discussion than a generic request for “TMS software.”

If you are defining a custom transportation platform, you can discuss your TMS requirements with Pavans Group using your current workflow, systems and integration needs as the starting point.

Frequently asked questions

What are the main transportation management system requirements?

Requirements normally cover shipment and load management, carrier/rate management, planning, tendering, dispatch, tracking, exceptions, proof of delivery, freight settlement, integrations, security and reporting. The exact requirements depend on the operating model and should include measurable acceptance criteria.

How is a TMS different from a WMS or fleet management system?

A TMS primarily manages transportation planning and execution. A WMS focuses on warehouse inventory and fulfillment, while fleet management software focuses on vehicles, drivers, maintenance and telematics. The systems often integrate.

Should we build or buy a TMS?

Buy when standard software covers your operating model and integrations. Extend an existing system when its core functionality fits but specialized workflows are missing. Build custom when proprietary transportation rules, complex integrations or strategic product ownership justify the additional engineering responsibility.

Which TMS architecture supports high-volume shippers?

There is no single best architecture. Evaluate shipment volume, integration traffic, event throughput, concurrent users and reporting workload. A modular monolith may work well at considerable scale, while particular workloads such as telematics ingestion or optimization may justify separate services.

Can a custom TMS integrate with our ERP and carriers?

Yes, provided those systems expose suitable integration mechanisms. Integration may use APIs, EDI, webhooks, files or other interfaces. The project should validate system ownership, data mapping, failure handling and reconciliation before implementation.

Can TMS driver apps work offline?

Yes, but offline operation needs deliberate synchronization design. The app may store assigned work locally, capture events and POD without connectivity, queue updates, and synchronize safely when connectivity returns.

What belongs in a TMS MVP?

An MVP should complete one high-value transportation workflow end-to-end. It commonly includes shipment intake, basic planning, carrier or vehicle assignment, dispatch, tracking, exceptions and proof of delivery plus the critical integrations needed to operate.

What affects custom TMS development cost?

The main factors include modules, roles, carrier count, ERP/WMS integration, rate logic, routing, driver apps, offline requirements, telematics, migration, security, QA, infrastructure and support.

What affects the TMS development timeline?

Major schedule drivers include integration uncertainty, stakeholder availability, carrier onboarding, workflow complexity, mobile/offline requirements, data migration, UAT and rollout scope.

Conclusion

A successful transportation management system starts with operational clarity, not technology.

First determine whether the organization should buy, extend or build. If custom development is justified, define the transportation requirements, system ownership and acceptance criteria before choosing architecture.

Then model the fundamental domain correctly:

Order → Shipment → Load → Execution → Tracking → POD → Settlement

Treat integrations as part of the core product. ERP systems, WMS platforms, carrier APIs, telematics and driver applications will fail or become temporarily unavailable, so retries, idempotency, reconciliation and operational visibility need to be designed into the system.

Finally, keep the first release focused.

An MVP that reliably executes one complete transportation workflow provides more useful evidence than a large collection of partially connected modules.

Organizations planning a custom platform can discuss their TMS requirements with Pavans Group, starting with the current transportation workflow, integration landscape and operating constraints rather than a generic feature list.

Author bio

Naresh Chauhan, CEO at Pavans Group

Naresh Chauhan is CEO of Pavans Group, a software and digital product development company based in Vadodara, India. Pavans Group works across custom software, web and mobile applications, AI and IoT solutions, with documented logistics projects involving multi-carrier shipping, last-mile delivery, tracking, field applications, APIs and operational automation.