I worked on freight and logistics software for 10+ years for a New Zealand based company that has significant operations in USA, Australia, Europe and Asia. (domestic freight/road, air, sea, 3PL)
We were a bespoke software dev shop, and the freight company was our customer.
During my time there we were transitioning to their third “major” version of the software over about 30 years. It was a new system designed to handle the US market, where the customer was a relatively new entrant who had been running off the shelf software for some time.
Due to the way they run their business, with strong P+L requirements down to each individual location/site they had a presence, and even individual trucks operating as separate business units, a lot of what got built was effectively accounting. If this sounds like you, or you use a lot of third party carriers, keep this in mind: tracking freight movements alone isn’t that hard, but you need really strong accounting fundamentals in the system from the get-go to be able to really understand costs in this business. Some off the shelf software doesn’t do this particularly well.
Based on this - my strongest advice would be to choose boring tech (Java or .NET) and recruit specifically for some core developers who have a solid grounding in accounting fundamentals, or do some serious training on this before embarking on the design. You will inevitably end up posting journal entries to your accounting software, so treat cost tracking as a double entry accounting system rather than trying to construct a journal as an output.
The customer is pretty vocal in their annual reports (publicly available as they’re listed) about their successes in IT as well as their business model. They look at having control of their platform “in house” (product ownership in house, outsourced development of their own platform) as a core part of their success.
If you would like to chat, I’m not hard to find - look me up on GitHub, then search my name + New Zealand on Linked In. (My customer is also pretty obvious from there).
We were a bespoke software dev shop, and the freight company was our customer.
During my time there we were transitioning to their third “major” version of the software over about 30 years. It was a new system designed to handle the US market, where the customer was a relatively new entrant who had been running off the shelf software for some time.
Due to the way they run their business, with strong P+L requirements down to each individual location/site they had a presence, and even individual trucks operating as separate business units, a lot of what got built was effectively accounting. If this sounds like you, or you use a lot of third party carriers, keep this in mind: tracking freight movements alone isn’t that hard, but you need really strong accounting fundamentals in the system from the get-go to be able to really understand costs in this business. Some off the shelf software doesn’t do this particularly well.
Based on this - my strongest advice would be to choose boring tech (Java or .NET) and recruit specifically for some core developers who have a solid grounding in accounting fundamentals, or do some serious training on this before embarking on the design. You will inevitably end up posting journal entries to your accounting software, so treat cost tracking as a double entry accounting system rather than trying to construct a journal as an output.
The customer is pretty vocal in their annual reports (publicly available as they’re listed) about their successes in IT as well as their business model. They look at having control of their platform “in house” (product ownership in house, outsourced development of their own platform) as a core part of their success.
If you would like to chat, I’m not hard to find - look me up on GitHub, then search my name + New Zealand on Linked In. (My customer is also pretty obvious from there).