Most transport and logistics businesses start with an off-the-shelf transport management system, and that's usually the right call. A good TMS handles bookings, dispatch, tracking and invoicing for a standard operation, and it's maintained by someone else.
The trouble starts when your operation isn't standard. Customer-specific rules, unusual rate structures, multiple depots or a mix of freight types can push a TMS past what it was designed for. The team fills the gaps with spreadsheets, workarounds and memory, and the system that was meant to run the business becomes something people work around.
This article covers how to tell when your TMS has stopped fitting, the four options you have, and when custom software is genuinely worth it.
The short answer
Most operators should configure or extend their TMS first, and build only the parts that are genuinely unique to how they work. Replacing a TMS entirely with custom software is rarely the first step. A custom layer, such as a customer portal, a rules engine or a reporting dashboard that sits alongside your TMS, often solves the problem with less risk.
Signs your TMS no longer fits
Workarounds live in spreadsheets
If key information lives in spreadsheets next to the TMS, such as customer-specific rates, special handling instructions, depot allocations or driver availability, the system isn't holding what the business needs.
Customer rules live in people's heads
"That customer needs a call before delivery." "That site only accepts deliveries before 10." When rules like these depend on experienced staff remembering them, mistakes happen whenever someone's away.
Data is entered twice
If jobs are entered in the TMS, then again in accounting, then again in a customer portal or report, you're paying people to be the integration.
Reporting happens outside the system
If management reports are built by exporting data and combining it by hand each week, the TMS isn't giving you the view you need.
Customers want something the TMS can't give them
A booking portal, specific tracking views or custom reports for key accounts can be hard to provide from a standard system.
Four options
These options are listed from least to most change.
Configure
Many problems can be solved inside the TMS you already have. Check whether the features you need exist on your plan, whether custom fields or rules are available and whether the vendor can help. It's the cheapest option, and it's worth exhausting before anything else.
Extend with integrations
If the TMS does its core job well but doesn't talk to your other systems, integration is usually the answer. Connecting it to accounting, a driver app, a customer's ordering system or a reporting tool removes double entry without changing how dispatch works. This depends on your TMS having an API, webhooks or reliable exports.
Build a custom layer
When you need something the TMS can't do, such as a customer portal, a rules engine for complex customer requirements or a reporting dashboard across depots, you can build that layer and connect it to the TMS. The TMS stays the core system for dispatch and tracking, and the custom layer handles what's unique to you.
Replace
Replacing the TMS, with another product or a custom platform, makes sense only when the core system is the problem: it can't be configured, it can't be integrated and the workarounds cost more than switching. Replacement is a major project with migration, retraining and risk, so it should be a deliberate decision rather than a reaction to frustration.
What a custom layer usually looks like
A booking or customer portal
Customers enter bookings in a structured way, see the status of their freight and download proof of delivery, without calling your office. The portal reads from and writes to the TMS.
Job status and proof of delivery handoffs
Status updates, POD capture and exception alerts flow from the driver to the customer and the office automatically. For the wider picture, see why freight and logistics businesses need better workflow automation.
Reporting across depots
A dashboard that combines TMS, accounting and other data so managers can see performance by depot, customer or lane, without a weekly spreadsheet exercise.
The idea of keeping the core system and building the missing layer is the same principle behind our work for Huntress Recruitment, in a different industry. Bullhorn stayed the system of record, and a structured layer of public-facing job fields made publishing to SEEK and the website more consistent. For a transport business, the TMS plays the same role.
Compliance and data you can't ignore
Transport businesses carry obligations that software decisions need to respect. Under the Chain of Responsibility laws administered by the National Heavy Vehicle Regulator (NHVR), parties in the chain, such as employers, operators, schedulers, consignors, consignees, loaders and unloaders, have a duty to manage the risks they can influence or control. If you use electronic work diaries, there are record-keeping responsibilities too.
This isn't legal advice, but the software point is simple. Whatever you build or connect, be clear which system is the record for compliance data, who can change it and how it's kept. A custom layer should read from compliance systems, not quietly create a second version of the truth.
What drives the effort
Every project is different, but the main factors that drive effort are predictable:
- The number of systems involved. Each connection adds work and maintenance.
- Data quality. Clean, consistent data is much easier to work with than years of free-text fields.
- Rule complexity. A handful of clear customer rules is very different from hundreds of exceptions.
- Users and roles. Customers, drivers, dispatchers and managers each need different access.
- API access. Whether your TMS has a documented API, and on which plan.
- Ongoing support. Integrations and custom software need maintenance as connected systems change.
When custom isn't the answer
Custom software isn't the right move when your operation is fairly standard and a well-configured TMS already handles it. It also isn't right if there's nobody in the business to own the product: someone needs to make decisions about how it should work, prioritise changes and make sure the team uses it.
If you're weighing up custom software more broadly, our article on buy vs build and when custom software actually pays off covers the general decision.
Frequently asked questions
Can you integrate with our existing TMS?
If your TMS has an API, webhooks or reliable data exports, integration is usually possible. We'd check the vendor's documentation and what your plan includes before suggesting an approach.
Do we have to replace our TMS?
Usually not. Configuring it properly, integrating it or building a custom layer alongside it is often the better path. Replacement is the last option, not the first.
Who owns the code?
For custom work, your business should own the code, the hosting arrangements and the credentials. Make sure that's clear in any agreement.
What happens when the TMS vendor changes its API?
Integrations need maintenance when connected systems change. That's why ongoing support should be part of the plan from the start, not an afterthought.
What does custom transport software cost?
Custom software and automation projects typically start from A$2,500. Final pricing depends on the systems involved, complexity and scope. For a larger project, such as a customer portal or a platform that replaces part of your TMS, we'd start with an initial consultation.
Tell us where your TMS forces a workaround
If your team is working around your TMS every day, tell us where. We'll tell you whether to configure, integrate or build, even if the answer is "don't build". You can read more about our custom software development work and our Transport & Logistics page.
Get in touch and tell us about the workaround that costs you the most time.