A twenty-million-dollar 3PL and a billion-dollar retailer fail at a warehouse system for opposite reasons. The small one buys software built for an operation it will never become. The large one tests until the tests pass instead of until they hurt.
Scott Harward opened episode 3 of Fulfillment Unpacked in September 2025 by asking for the most outrageous reason I'd seen a 3PL pick a WMS. Both of those stories came out of that question.
Every quote block below is me, on the episode, condensed for reading.
The Fairytale Implementation Cost
A small 3PL, probably in the twenty million dollar revenue range, went immediately out of the gate and bought something like a mega vendor. They saw the price tag, they saw the fairytale implementation cost during the demos, and they thought that was reality. Sure, I could pay the subscription fees, and then all the wheels come off the bus.
You realize there's a bunch of questions you're not ready to answer, and when that sets in, that means there's a whole lot more work than you thought. Budget, timeline out the window, costs are soaring. And the vendor isn't there to hand-hold you through the business maturity piece of it.
The subscription is the affordable part, and the only part anyone quotes with confidence. What follows scales with how unready you are. Nobody in the room can estimate that number.
One Person, Many Hats
The size mismatch has a specific mechanism, and it isn't about price:
Take SAP in the ERP world. They're made for massive companies, so the way they've structured the software is you have a team doing one thing. Everyone's role is like a fractional piece of a hat, and that's how the software is built. Then you have a small business where one person is wearing multiple hats, not a tiny piece of one. They get into this big system designed for someone doing a small part of a workflow, and suddenly there are all these jump-off points.
They went from something that kind of worked for them. It was manual, there were errors, but it was built around their workflow. Now I have to jump through a million different screens to get one thing done.
Warehouse systems from the same tier are built the same way, for buildings with dedicated planners, dedicated supervisors, and a support function in the office. Right-sized software assumes the opposite, and it shows up as a person finishing a task in one place instead of five.
Enterprise software encodes an org chart. Buying it means agreeing to staff that org chart, and a small operation cannot, so the work reappears as screens instead of people.
That's a different argument from cost, and it survives even when the bigger system is genuinely better software. The person wearing every hat is also where the operation's growth stops.
The Worst Possible Timing Is Also the Most Common
In the e-com world, not during Q4. Or peak, whatever peak is for you. You should start right at the very end of it, so you're ready for next peak, not in the middle of it, because that's when the wheels come off the bus in a hurry.
You wait too long and now the pressure's on and you cut corners, whether you want to or not. Either you missed it and you table it while you brute force through the next peak, or you go live with something that hurts you and you're spending crazy amounts on overtime and bringing in experts to keep the wheels on.
Nobody plans a go-live for peak. They plan it for spring, spend the delay deciding, and arrive at peak anyway with the same date still attached.
The Mock Go-Live That Passed
Scott asked about the nastiest thing I'd walked into. A million square feet, eight miles of conveyor, fifteen years of tuning on software that was being sunset. They ran mock go-lives on weekends and every one came back clean:
Thumbs up, working great, working great. We get to go live and things go sideways. We started looking around, trying to figure out how it possibly could, because you've tested this. We started getting access to the data and realizing, oh, you did the same things over and over again. People had the same test scenarios. Of course you optimized for those indirectly. You didn't realize it, but you did.
They all had great data that you'd fixed. Then you got the reality and realized your data across the system was terrible.
A test suite assembled by the people who will run the go-live converges on the cases they already handle well. Passing it proves the rehearsal worked, and says nothing about the cases nobody thought to rehearse.
The budget failed the same way. The original quote would have been accurate within twenty percent, and it got chopped in half, not because anyone found savings but because the real number wasn't one they wanted to believe. The overages got approved later anyway, which is the usual ending. It's the same reflex that makes the early warnings so easy to wave off. Both failures were signals available early and read as reassurance instead, which is the shape month four of a slipping implementation takes.
What's Changed Since September 2025
Less than a year on, so not much. The one thing worth restating is the position I take on vendors, because it gets heard as cynicism and isn't:
Beware of vendors in general. That's not to say they're evil. Their motivations are different than yours. There's this misconception that they will build a system around your business, when the reality is they're a software company. They will give you access to the software, keyword access, and help you configure it so you can get some use out of it.
A vendor knows their software better than you ever will. Knowing your operation is a separate skill, and first-time buyers routinely mistake the two for one.
