A distributor's ERP is fine right up until the warehouse gets complicated enough that the ERP starts holding it back. There's a specific milestone where that flips, and most operations pass it a year or two before anyone names it.
Matthew Dunne had me on episode 7 of Built for Creators in May 2025. He asked who I actually work with, which is the question that pushed this one toward distributors rather than warehouses in general.
Every quote block below is me, on the episode, condensed for reading.
When the ERP Becomes the Boat Anchor
There's a certain size they get to where they start with an ERP, the thing that's a catch-all that would do all the things for them. But when they get to the point where their warehouse operation is sufficiently complex, the ERP doesn't really move the needle. It more or less holds them back like a boat anchor.
They talk about warehouse management add-ons and functionality, but it's very basic, and a lot of it is backwards looking. It was engineered ten, twenty years ago, so very simplistic business models. You throw in e-commerce and anything else and suddenly it can't do it. There's very little scanning potential, an emphasis on manual workflows and paperwork, and it's very rigid.
The milestone is usually structural rather than gradual. A second warehouse, or a centralized distribution center now serving branches across several states. Electrical supply distributors were the example I reached for, buying product and moving it out to branches and to tradesmen working jobs.
The module was sized for the business that bought the ERP. Nothing about it fails when the operation outgrows it, so the moment passes with no event to point at.
Worth asking whether you've genuinely exhausted what's in there first, because sometimes the module can still carry more than it's being asked to. The harder question is why nobody in the building can price the gap, since the module arrived bundled and nobody ever chose it.
Working for the Spreadsheets
They might have systems, and I use air quotes, where it's a purpose-built piece of software they bought for one piece of the operation, and then another one. And they don't necessarily integrate. So there's spreadsheets, there's people in the middle remembering how to do things. If they're out one day, your operation can really suffer. Eventually you have enough spreadsheets that you have spreadsheets that manage other spreadsheets, or you work for the spreadsheets.
Cycle counting is where I see the widest spread between operations, from almost never to counting so often it stops adding anything, and nearly all of it on paper or in somebody's private workbook. Work that lives in a private workbook is also work the invoice never sees.
A spreadsheet is a system with exactly one person qualified to operate it and no record of why any of it works the way it does.
Cost of Inaction, and the Crossover
Instead of ROI, we focus on cost of inaction. If I do nothing, what are those costs? And as we grow, do they get so big that they outpace our additional revenue where we just can't ignore them? And what's the timing on that? Where's that point where we're losing money as we grow?
That last question is the one finance responds to, because it converts a preference into a date. A return projection invites an argument about assumptions. A curve showing where your cost of standing still crosses your incremental margin invites a decision about when.
Cost of inaction changes the question from whether the investment pays back to how long you can decline to make it. Your own numbers can already answer that one.
Becoming a Client of Yourself
Matthew described something he sees across the UK that turns out to be common in the States too. A retailer or brand with warehouse capacity starts storing and shipping for other companies, and now runs two businesses on systems built for one:
The ERP does not play well with that because you don't own the inventory. So you need to track yours in whatever systems make sense, and then you have the separate piece for all your clients. I've seen that play out many times where they had some excess capacity and next thing you know they have one or two clients, and it's a struggle because they don't have the visibility.
Maybe your business becomes another client inside of the warehouse management system. You're a client of yourself. Now you have a clean level playing field for people to use. They're not jumping between systems, doubling up, tripling up the training, adding the turnover.
Running your own inventory as one more client of your own warehouse costs you nothing structurally and removes the second system, the second training path, and the second set of habits that fragment a floor.
It also forces the question underneath: some operations discover at that point they're better at fulfillment than at what they originally sold. That's a business model conversation rather than a software one, and it belongs before the software.
Not Yet, and How That Lands
I don't necessarily tell you that you need to invest right now. A lot of times it's going to be not yet, and here's the objective reasons for it.
Matthew asked how people take that. Almost always as relief. It usually validates something they already suspected but couldn't defend internally, and the framework works out to be a cheap way of avoiding an expensive purchase made a year early.
The pushback I get is different and more interesting. It comes from teams with an in-house group invested in the ERP who would rather not add another system, and that's a fair position. I'm not an ERP expert, but the capability limits are visible enough to argue about objectively rather than by pointing fingers.
An assessment that can only conclude "buy something" is a sales process with a report attached, and the buyer can usually feel the difference before they can name it.
