Hacker News new | past | comments | ask | show | jobs | submit login

Not mentioned in the article, but this is interesting because Jeff Bezos invested in Convoy, a Seattle startup working to optimize freight brokerage, back in their seed or series A, forgot which.

Though I'm sure nobody at Convoy, now valued over 1BN, honestly believed Amazon wouldn't jump into a market this big and ripe for improvement.

Then again, there's almost certainly room for dozens of big players. I don't think I even comprehend how big the freight brokerage space is, but I'm sure I'm underestimating it by multitudes.




It's big, it's technologically really old / behind the times, lots of customization.

And a lot of the human interactions are with people who have borderline computer skills, even decision makers.

It is a strange space. LOTS of room for efficiency and at the same time so easy to say "oh yeah this could be done better" and then you fall on your face because logic is not how anything / anyone works ;)


I worked at a major third party logistics company from 2012-2015 and they were less than halfway through a massive project to rewrite their COBOL mainframe systems in Java, and I doubt they're anywhere near being done yet.

The industry also runs on FTP transfers of flatfiles and ANSI X12 EDI messages. The most "modern" partner API I saw was SOAP. No one I talked to had even heard of REST.

Meanwhile, on multiple occasions I heard senior managers express terror at the prospect of Amazon entering their market and competing with them. Rightfully so, given the size of Amazon's resources. Making money off a logistics network is an economy of scale game.


Can concur.

I urge any technical or product manager to dig into this mess of an industry, it defies everything.

The way the markets are set up, the inherent localization, lack of standards.

In 2019 tons of 1-3 day short hauls are negotiated over the phone, trucker to shipper, and neither of them may have exact understanding of market rates, especially given variables like the ability for the trucker to return with a partial load.

And of course the unbelievable lack of tech.

It is truly mystifying.

That said, it may very well be that Amazon can conquer it, possibly by imposing regular standards for all sorts of things and efficient clearing market, a common tech platform etc. etc. etc..

But I'm far more confident that Amazon will conquer 1 day delivery than actually fix trucking.

All of this may be moot by the time autonomous truckers arrive, and I suggest they might hit before cabs as it's possible 'just driving 2000km on a highway no-stop' might be easier than navigating Manhattan. Autonomous trucking may come with a whole new set of systems and procedures which will probably be more advanced.

When I did some research with a friend into this industry, we visited some brokers and dealers I swear I was in a Vince Vaughan comedy.


>Making money off a logistics network is an economy of scale game.

And yet there are so many small niche providers.... you'd think that would have gone away long ago...

Such a weird world.


Yes, but the niche providers flourish when the market is good, but they're the first to get killed off when it's bad. The post-2008 economic collapse saw mass consolidation in the industry as smaller players either went bankrupt or got bought up by competitors.

There's also a big difference between asset-owning and non-asset-owning carriers.

You can start a logistics company with very little capital--just licensing, bonding, and insurance. In that case, you're basically a travel agent for freight. Some of these agents have grown into very large companies, however, because they help big customers allocate freight across many asset-owning carriers and mitigate their risks, and they handle dealing with international customs and compliance regimes. They're like an outsourced supply chain operations department.

In air and ocean, the niche asset-owning carriers generally have some statutory protection. A good example is Jones Act carriers--there's a law called the Jones Act that requires that only American flagged carriers can transport freight between any two American ocean ports. That means there are only a couple of ocean shipping companies that are allowed to go to places like Hawaii, Alaska, Guam and Puerto Rico.


Interestingly, similar laws come in to play with cruise ships - non-US-flagged passenger ships that depart from a US port aren't allowed to return to a US port without first stopping at a foreign port. Almost all American cruise ships are flagged in countries outside of the US. The practical effect of this is that the many cruises that travel between the west coast and Alaska all have to stop over in Canada before they can return to the west coast, which is a major driver of tourism to Victoria, BC - since that happens to be the largest port city between Alaska and the mainland US.


IANAL, but I don't think it's "similar" laws, but the exact same law. Cruise ships are just (very inefficiently) transporting human cargo.


The problem with the Jones Act isn’t so much that the ships have to be US flagged - that’s a natural requirement for a domestic operation. The problem is that it requires them to be US built but the US no longer has a competitive shipbuilding industry.


They are allowed to go to Puerto Rico (or AK/HI/Guam), but they couldn’t then continue to Miami or Norfolk (or Long Beach) or another US port from there, which makes it uneconomical for them to stop in PR/AK/HI due to the Jones Act.


The Jones Act is such a shit show. Almost no one in the mainland US knows about this Crony Capitalist act than enriches a tiny group of people, but makes life in Puerto Rico, Guam, American Samoa etc quite seriously more impoverished than there is any need for it to be.

https://reason.com/tag/jones-act/


Yeah, it is really strange. When it comes to trucking, the vast majority of the industry is individuals or very small companies with a handful of trucks. I would have though the benefits of scale would cause mass consolidation, but that isn't the case so far.


There's a lot of inertia in the industry behind the traditional brokerage model (very sales-centric, and all about relationship building).

Consolidation is also hard on the trucker side, where there's a ton of fragmentation in the kind of work they perform and access to it


Can you please explain your last paragraph?


I work in the enterprise payments space that functions on ftp transfers of xml, edi and text files and it's not necessarily a bad thing, just as long as it works. Much easier to troubleshoot why you got bad data if you have a ftp to look at with a daily xml file that gets posted.


Except that failure modes of ftp (technically not ftp-the-protocol itself, but what the server chooses to do with the file) is not well defined. What happens if the connection dies half way through? Is the partial file processed? None of it? Does the file get moved after the upload is done or after it has been fully processed? Does every single last company in this space's ftp site behave the same in the face of errors? Also is this literally ftp and not anything more recent that includes encryption, but if it includes encryption, what ciphers are supported? Nevermind the files may be in ebdic or something else wonderfully obscure...

(I also work in payments. Bank's SFTP sites have under-defined failure modes.)


As do I (bank file transmissions representing!) To compensate this partial file fiasco, we tend to rely on the .done file methodology (i.e. we won't pick your file from your server until your script writes out a dummy file we can locate). Or we'll allow you to just push the file to us. Our system will notice partial file send of course, where the transmission stopped. But we can't determine if the file was partial to begin with. So we rely on balance reports to come via alternate FTP or email transmissions.

Don't get me started on sending ASCII as binary to the mainframe to compensate for the EBCDIC formatting. Or the lack of carriage return and line feed characters that cause so many fun issues.

All of that to say that none of it's pretty, but all of it works. The balancing is key as are the extra staff needed to verify them against each other.


Can this be solved by sending two files, one with the data and one with a checksum of the data?


That's a reasonable idea! There are a wide variety of ways to solve the problem, using ftp uploads as the primitive, but ultimately that's... kind of the problem. Everyone's solution is different from everyone else's, but those different solutions have different ramifications, so when they fail, they have to handled very differently. That is to say, OOP, classes and inheritance, only gets you so far.

(An issue w/ whole file checksums is that there are cases where partial file processing is desirable, but that's not to say there's not use of checksums.)


That's what we do. Have a summary file and a detail file and they need to match.


It's also bad when your trading partner's sender process crashes and they build up a backlog of a million messages, and then once they fix it, they want to dump their whole backlog on you at once.

Or their process gets stuck in an infinite loop and resends you the same message millions of times, etc.


Yeah, I've dealt with SFTP + CSV workflows and it's not so bad. I ended up writing a virtual SFTP server which was not backed by a filesystem, and which would prevent malformed data from being written, and make closed/authoritative files immutable.

It's obviously not ideal, compared to a well-thought-out purpose-built API and a complete set of tools, but that takes work, and isn't always better faster than the refined hack.


Wouldn't it be simpler to upload a file with a tmp name and then at the end rename the file if there was no error? Renaming is pretty much an atomic operation.


It would be, but they might not have the latitude to dictate the connection AND it might be multiple-file batches.


>I worked at a major third party logistics company from 2012-2015 and they were less than halfway through a massive project to rewrite their COBOL mainframe systems in Java, and I doubt they're anywhere near being done yet.

Expeditors International perchance?


>> The most "modern" partner API I saw was SOAP. No one I talked to had even heard of REST.

How is REST better than SOAP per se?


The amount of incidental complexity. Reading through their SOAP service spec and coding up a program to interact with it took several times as much effort as coding against a similar REST API would have.


I'm in that space right now and yeah, the state of the technology is horrible, but I think there are some real barriers to disruption. At first glance a comparison to Uber disrupting the taxi market seems like a good one. But I would estimate that 75% of the work is responding to something going wrong, so it is going to be very different situation since you are not going to get the real cost savings until there is a system that can start handling the edge cases. Also, the margins are low. Average around 15%. Uber is currently taking 25% and still hemorrhaging money. So it is a harder problem to automate and it needs to be done at a lower margin. I'm sure it will happen someday, but I think it's 5-10 years out or more.


Yes the software for even intermodal is pretty simple. The complexity comes from the human idiosyncrasies, including those of the customers. The transportation departments of some of the larger shippers can be very demanding, and a total shit show at the smaller ones.

Amazon has the power to make them adapt.


Since you appear to know some about UBER:

What is UBER spending money on? They don't own the cars, they skim off of drivers. I presume the only costs they should have are infrastructure maintenance, software development, and insurance (if they do it in house?)

On the surface it seems like they have a license to print money.


They are subsidizing the fares, for one thing. Every ride costs them a few dollars of loss.


What do you mean by their margin is 25% if they are subsidizing the fares?


As far as I understand, this can be distilled down to:

1: Uber is charging 25% commission for the use of their platform

2: Uber is still losing money

Which means that in order for them to break even they would need to charge a higher commission at the existing fare rates, or bump the fares to a level where their commission covered their costs.

Well... There's always the third option too: cut their own cost base significantly.

Each of those options carries an economic impact and knock-on effects.


Yeah Convoy and Flexport seemed to be the only ones pretty good at it in the startup space.


It's definitely a far more complicated space than you expect at first glance :)


>It is a strange space. LOTS of room for efficiency and at the same time so easy to say "oh yeah this could be done better" and then you fall on your face because logic is not how anything / anyone works ;)

Sounds like a perfect opportunity for somebody like Amazon to shake things up. Where a smaller entrant might have trouble breaking that mentality, Amazon can do things however they want without worrying about having to attract customers who want to do things the old way.


I worked for a freight brokerage in 2012 and the only thing I have to say is that there is plenty of money to go around. The company I worked for was a small player and they were doing 30 million a year as a simple middleman


It may be a big revenue business but margins are extremely thin. That's one of the reasons why there hasn't been much innovation. Amazon could be a different story, but the virtue of brokering a standard product is same as retailing a barcoded product. It's the same marketplace story. If Amazon is interested, it's not for the money but for an opportunity to own an important platform in the logistics industry.


Our company works closely with amazon and every interaction i have with their “enterprise support” team make me wonder how much of their curiosity is there to help build our product better and how much is brain rape


I do wonder what those terms look like (Right of First Refusal?).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: