The thought usually arrives the same way. You find the one thing your operation does that no packaged system handles cleanly, you watch two or three vendors fail to handle it, and building starts to look less like ambition and more like the only door left.
Dave Crysler had me back for episode 53 of Everyday Business Problems in January 2025 to argue buy versus build. I'll declare the bias up front, the same way I did on the show: I am not a fan of building.
Every quote block below is me, on the episode, condensed for reading.
The Requirement That Starts the Conversation
This came down to what I would call wire cutting. In the WMS arena, you're typically picking things that are discrete units. You can pull a few units from one box and grab a few from another one and marry them up and you've satisfied the order. With wires, you're pulling from a spool and cutting. You don't take two different lengths and give them to the customer, because obviously that defeats the purpose.
That's a real constraint, it rules out a lot of systems immediately, and the feeling it produces is the dangerous part:
You might come in with a preconceived notion, you want to work with vendor XYZ, and it turns out they can't do it. And then it's like, well, why am I here? Or you bump into another one and it's the same situation, and those are the ones that you've heard about. So you get defeated and you start looking like, well, do we build?
Three vendors failing the same requirement tells you the market is thin for your shape of problem. That's a different finding from the market having nothing for you.
What Happens to the Company That Builds
I worked for a small remanufacturer and they were, to an extent, maybe allergic to buying software. Price tags, perceived complexity. But they weren't opposed to hiring some developers and throwing their hat in the ring.
It made sense at first, and then it didn't:
Where do you stop? In fact, where do you start? It was just this hodgepodge of features to get to a certain level of parity. There was no roadmap. People knew that they built their own software, which meant you had people coming from every direction with their pet projects. It was quite the monstrosity after several years.
Instead of really innovating, there was a lot of work to just maintain the system. You get this concept of technical debt. After years of doing it, you're trying to do something new in the business, but you're fighting something old.
The bill arrives in a form that never appears in the forecast. A friend of mine was there for years, and by the time the company was acquired he was the only person who understood the whole system in detail. It worked out well for him personally and it was a serious liability for the business, which then had to unwind that system without losing what was inside it.
Homegrown software converts a staffing decision into a structural one. The company doesn't own the system, it owns whoever still understands it, and that person's next career move is a business risk.
Packaged software has one advantage here that rarely makes the comparison. Somebody out there has already used the system you bought, in another job, and can be hired. Nobody has ever used yours.
Design for Misuse, Not for the Demo
Don't just pay attention to the happy path. That's great, that's easy to test, you can do that pretty quickly. It's all the places you can go off the rails, and putting the guardrails in there to keep that to a minimum. Best effort, you're never going to get them all. But that's a huge part of engineering.
After you've designed something, focus on how people are going to misuse it. Because people are creative. If you give them an inch, they're going to take a mile, and they're going to find some way to get their jobs done quicker. Especially on the warehouse floor. If you're incentivizing them on some type of behavior, they're going to find ways to game the system. The bigger you are, the more games they play.
The happy path is a fraction of the work in any system worth having, and it's the only fraction that gets demonstrated, estimated, or tested before you commit.
That applies whether you're writing the software or configuring somebody else's, which is why it belongs in what you agree to before signing rather than in a discovery conversation afterward.
The Expensive Version: Buying, Then Rebuilding What You Had
I worked with a really big company, multi billions. They were coming off a system they had built in-house, 25 years. They had a couple of people getting ready to retire who knew all the information, so they were looking for package software. And they made a huge critical error. They wanted to take what they had built in-house and make the package software do the same thing.
They spent a ton of money adapting and tweaking to make the vendor software work the way that old homebrew system worked. It couldn't be supported by the vendor. They had to hire a bunch more people. It took way longer than it was supposed to take.
The bill came due at the version upgrade, with a price tag for pulling the customized monstrosity forward that nobody had envisioned. A colleague on that project got a call years later. The first thing out of the client's mouth was that they should have listened to us.
Replacing homegrown software with packaged software and then configuring the packaged software back into the homegrown one is the worst outcome available, because you've paid the purchase price for a system and kept every liability of the thing you were escaping.
When Build Actually Wins
I've recommended it a handful of times in twenty years. The most recent one was a remanufacturer in a commodity market, where prices move daily and the operation has to stay flexible about whether to reprocess a unit or sell it as it came in. The systems available in their space were opinionated in ways that fought that. But the deciding factor wasn't the features:
They're growing through mergers and acquisitions right now, and they need a faster way to pull these smaller companies into the fold. There's a rationale for investing in their systems that gives them some kind of competitive advantage, and they're going to get the scale long-term out of that.
The rest of the picture mattered as much. A VP of IT with an operations background, an actual team, the discipline to work in priorities rather than pet projects, and a stated plan to replace their ERP and then use it for finance and accounting instead of shoehorning operations into it.
Build wins when the software is the competitive advantage rather than the cost of having one, and when the company has already demonstrated it can run software as a discipline rather than as a series of favors.
That's the same readiness question underneath everything else. The company I said yes to had done the process clarity work. Had they gone shopping instead, they'd have chosen well, because the work that qualifies you to build is the work that qualifies you to buy.
What's Changed Since January 2025
Not much on the argument, which is roughly how I'd want it. Clarity First is the System Fit Sprint now, with published pricing and a fixed set of deliverables, and the assessment I describe running for that remanufacturer is the same engagement under a name you can look up.
An assessment that can end in "build your own" is only credible from somebody who sells neither the software nor the development. That's why the boundary has stayed where it is.
