For as long as I've been doing this, the answer to "should we build our own system" has been no, and the reasons were good ones. That answer has started to move, and it moved at the edges rather than in the middle. The core is still something you buy. The one workflow that makes your operation different from the building down the road is now something you can reasonably own.
Kevin Lawton and I recorded this live on the floor at MODEX 2026 for The New Warehouse, and it went up in August 2026. Most of these conversations are about what a buyer should do this quarter. This one was mostly about what's arriving next.
Every quote block below is me, on the episode, condensed for reading.
The No I Was Giving
For the longest time I could talk to 100 people, and 99 of them I would tell that's a hard no. It doesn't make sense for you. But that's evolving.
That no was never about whether the software would work. A competent team can get something running that does the job on the day it ships. The trouble shows up later, in the technical debt nobody put in the budget and the brain drain when the person who built it moves on. I made that case at length on Everyday Business Problems at the start of 2025, and none of it has stopped being true.
A company that builds its own system takes on an engineering payroll it never budgeted for, and the bill arrives years after the decision that created it.
What Actually Changed
Where it's evolving, in the conversations I've had, is around the edge cases. You can get a core in there, but now it's more accessible.
APIs are maturing. They used to be there, but everyone customized the snot out of their systems, so the API didn't keep up. That's becoming much more prevalent now.
The API did more of that work than the code generation did. A tool that writes working code in an afternoon does nothing for you if there's no supported place to attach it. What moved is that the API stopped being an afterthought sitting behind a wall of per-customer customization.
It also makes this something to check during selection rather than after, and it belongs in the comparison you run before signing.
Ask a vendor what their API covers, what it doesn't, and how often a platform release breaks it. Those three answers tell you how much of your operation you can own.
The Acronyms Were a Budget Decision
Historically we've had all these acronyms. WMS, OMS, TMS, WES, WCS. Alphabet soup. A lot of it was a consequence of software development being very expensive. You have to pick a lane, pick something you can do, because you're going to be investing a lot of engineering in it.
Those lines got drawn around what a company could afford to build, and then they hardened into categories that everybody shops by. As the cost of building comes down, the lines stop holding:
You start to see those compressing and bleeding into something else, and you have systems out here struggling to market themselves, because they're not just that one thing anymore. The other part is they're questioning, why are we built this way? Maybe we go vertical.
A few minutes later I made a prediction on the show:
Two years from now I think we're going to see some vendors that were on the periphery, or not here at all, showing up in a bigger way. They had that window of time to go in and restructure a product in a way that takes advantage of what's coming out now.
The acronyms are a map of what used to be affordable to build. Buyers still assemble shortlists out of them.
A shortlist assembled by category inherits a constraint that is on its way out. It's one more reason we don't publish vendor rankings.
The Core Is Still Something You Buy
It's still don't build. Build on top of something. Play to your strengths. Software is not going to be a competitive advantage for most companies. It's a different beast all around, and there's investment required to get you there.
Kevin raised the version of this that turns up in feeds now, where somebody decides to build their own warehouse system with Claude Code or Replit. The demo will work. What a demo never has to survive is the shift where somebody scans the wrong thing, and software written for the demo rather than for misuse comes apart there. That gap is why the answer at the core hasn't moved.
Software will not be your competitive advantage. Build anyway and you carry a roadmap, a support burden and a security posture that a vendor spreads across its entire customer base.
The Sliver Worth Owning
Look for the things that make you unique. Little slices, little slivers. That's where I think people will be able to stand out, and it's something they can bring into their sales pitch or their marketing.
When I talk to vendors, when I talk to 3PLs, they all sound the same. There's a propensity to sound the same. So focusing on what you really do well and highlighting that is pretty meaningful.
Kevin mentioned a vendor whose position is that they would rather guide customers through building certain customizations themselves, because not enough customers ask for the feature to justify putting it in the product. That's the same boundary drawn from the vendor's side of the table:
The vendor fares better too, because they're not on the hook for maintaining it. Those conversations of, we have to revisit this because we're evolving our platform. Now you have the API in between, and someone else owns that piece.
The sliver worth building is the one your vendor will never have enough customers to prioritize.
That is a separate question from whether to customize the system or change the process. One is about building something new alongside the product. The other is about bending what the vendor already ships.
You Still Have to Know Which Sliver
In the 3PL world, every three to five years they're popping their heads up looking at, does what I have make sense still, or should I be looking somewhere else?
None of this touches the part that was always hard. Telling the difference between a workflow that is genuinely yours and one that is only how you happen to do it takes the same work it always did, and getting it wrong now costs more rather than less. The requirement that shouldn't exist used to die in a backlog. Now it gets built over a weekend and maintained for a decade.
Cheap code makes the requirements question more consequential, because the wrong customization is now fast enough to build before anybody has argued about it.
The work of separating the two is what writing real requirements is for, and it's the same exercise whether the answer turns out to be buy, configure, or build.
