Logistics software projects rarely fail on the software. They fail on the integrations — the EDI feeds, the carrier APIs, the telematics, the customer's WMS that only speaks flat files at 3am. This guide is about that reality, because it is what actually decides the budget.
If you ask a development firm what drives cost on a logistics build and they start talking about screens and user roles, they have not built one. The screens are the cheap part. The expensive part is that your shipment does not exist in one system — it exists as a tender in an EDI transaction, a load in a TMS, a set of GPS pings from an ELD provider, a proof of delivery photo on a driver's phone, and an invoice line in accounting. Making those agree is the project.
The Integration Surface Is the Project
Before scoping anything, inventory what your system must talk to. In logistics this list is longer than owners expect:
- Customer systems — often EDI (tender, status, invoice transactions), sometimes an API, sometimes a portal a human has to key into.
- Carrier and partner systems — rating, tendering, tracking, each with its own dialect and reliability.
- Telematics and ELD — location, hours of service, vehicle status.
- Warehouse systems — inventory, receiving, pick/pack, whether yours or your customer's.
- Accounting — billing, settlement, and the driver or carrier pay side, which is frequently the messiest.
- Documents — BOLs, PODs, customs paperwork, and the scanning workflow that produces them.
Each connection has three questions attached: does it have a documented interface, how does it fail, and who fixes it when it does. A firm that has not asked those three questions about each item on your list cannot give you a real number.
EDI Is Not a Legacy Detail, It Is a Business Constraint
Owners consistently underestimate this one. If your customers are large shippers or retailers, they will dictate how you exchange data, and the answer is often EDI transaction sets over a value-added network, with their compliance requirements and their testing cycle.
Three practical consequences:
- Onboarding a trading partner takes calendar time you do not control. Their testing queue is their testing queue. Build your project plan around this rather than assuming it will compress.
- Each partner is a variation. The transaction sets are standardized in theory. In practice every partner has interpretations, required segments, and quirks. Budget per partner, not once for “EDI.”
- Chargebacks are a real risk. Non-compliant transactions cost money with some shippers. This raises the bar on error handling from “nice” to “financial.”
None of this argues against building. It argues for scoping EDI explicitly, partner by partner, rather than letting it hide inside a line item.
What You Should Almost Certainly Buy, Not Build
We build custom logistics software and there are large parts of this domain we tell clients not to rebuild:
- Route optimization. Genuinely hard mathematics with mature products behind it. Integrate, do not reimplement.
- Rating engines for common carriers. The rules change constantly and vendors maintain them for a living.
- Telematics and ELD. Regulated, hardware-dependent, and well served.
- Core accounting. Build the settlement logic that is unusual to you; do not rebuild the general ledger.
- Mapping and geocoding. Buy the service.
This is the same subtraction we apply in manufacturing, where ERP is the thing you keep and execution is the thing worth building.
What remains — and what is genuinely worth building — is the layer that expresses how your operation works: your load-building rules, your customer-specific service commitments, your exception handling, your margin visibility per load, your customer portal.
Try a TMS Properly Before You Build
The transportation management system market is mature. Before commissioning anything custom, run a genuine evaluation — real trial, your data, a named person responsible for making it work — and write down precisely where each product fails.
Then sort those failures the way you would in any build-versus-buy decision. Cosmetic complaints and process preferences are not reasons to build. Structural mismatches are. In logistics, the structural mismatches that genuinely justify custom work tend to look like:
- A service model the product cannot represent — multi-leg moves with mixed ownership, unusual cross-dock patterns, or blended asset and brokerage operations the TMS treats as separate businesses.
- Customer commitments the product cannot enforce — per-customer SLAs, appointment rules, or documentation requirements that only exist in your contracts.
- Margin visibility the product cannot produce — particularly where cost is assembled from several sources and the product assumes one.
If your complaints are that the interface is dated or the terminology differs, buy the TMS and adapt. That is a far cheaper answer and it is frequently the right one.
Where Logistics Projects Actually Die
Four failure modes we see repeatedly, all avoidable:
- Underestimating partner onboarding. The build finishes; the system cannot go live because three trading partners are still in testing. Sequence partner onboarding in parallel with development, starting early.
- Treating exceptions as edge cases. In logistics the exceptions are the operation — the late truck, the refused delivery, the split load, the detention claim. A system that handles the happy path beautifully and forces manual work for exceptions has automated the easy 60%.
- No reconciliation story. When the TMS says one thing and accounting says another, someone must be able to find out why. Design that from the start; retrofitting it is painful.
- Assuming clean data. Addresses, weights, and commodity codes arrive wrong constantly. Validation and correction workflows are core functionality, not polish.
How to Phase It So You Can Stop
Pick a single customer and a single flow, and take it all the way from tender to invoice in production. Narrow and complete beats broad and partial — it proves the integration assumptions where they are riskiest, and it is small enough to abandon if the assumptions were wrong.
Resist adding functionality until you have onboarded two or three more trading partners onto what exists. Each partner teaches you what was actually generic in your design versus what you accidentally built for one customer.
With real volume flowing, the exception patterns and the margin questions become concrete rather than hypothetical. Build them against evidence. This is also the point where the customer portal earns its keep, because you have something reliable to expose.
Where WorkflowUnity Fits — Honestly
We are a US-based custom software firm building on AWS. In logistics we build the operational layer and the integrations — EDI and API connections, load and exception workflows, margin visibility, customer portals — around the products you should keep, such as your TMS, rating, telematics, and accounting.
We will tell you to buy a TMS if your evaluation turned up cosmetic complaints rather than structural mismatches. We will also tell you if your integration surface makes a project larger than the problem justifies, which happens and is worth knowing before you commit rather than after.
Frequently Asked Questions
What drives the cost of custom logistics software?
The integration surface, far more than the application itself. How many customer, carrier, telematics, warehouse, and accounting systems must it connect to, whether each exposes a documented interface, and how many trading partners require EDI onboarding. Screens and user roles are comparatively cheap. Any quote produced without reading the integration documentation for your specific systems is a guess.
Should I build a TMS or buy one?
Buy, in the large majority of cases — the TMS market is mature. The diagnose-before-you-shop discipline applies here too. Build only after a genuine evaluation reveals a structural mismatch: a service model the product cannot represent, customer commitments it cannot enforce, or margin visibility it cannot produce. Complaints about dated interfaces or unfamiliar terminology are not structural and do not justify a build.
Why is EDI such a large part of logistics software projects?
Because large shippers and retailers dictate the exchange method, and their onboarding runs on their testing timeline rather than yours. Each trading partner also brings its own interpretations and required segments, so EDI must be budgeted per partner rather than once. Some shippers apply chargebacks for non-compliant transactions, which raises error handling from a quality concern to a financial one.
What parts of logistics software should never be custom built?
Route optimization, rating engines for common carriers, telematics and ELD, mapping and geocoding, and core accounting. Each is mathematically hard or constantly changing, and each has mature vendors maintaining it full time. Build the layer that expresses how your operation actually works — load-building rules, exception handling, per-customer commitments, margin visibility — and integrate the rest.
What is the most common reason logistics software projects fail?
Treating exceptions as edge cases. In logistics the exceptions are the operation — late trucks, refused deliveries, split loads, detention claims. A system that handles the happy path well but pushes every exception back to manual work has automated the easy portion and left the expensive portion untouched. The second most common cause is underestimating trading-partner onboarding time, which stalls go-live after development is complete.