Buy? Build? Or wait? The 3 AI questions every distributor is asking
By Nelson Valderrama
NAW and MDM surveyed more than 400 distribution leaders this year. They found a gap worth your attention. 73% of distributors expect AI to improve pricing margins by at least 2%. Only 16% have achieved it.
Technology isn't causing that gap.
Separate research from DSG found the same story from a different angle. 93% of distributors call AI a strategic priority. Only 16% have moved past pilot into anything running in production.
Two studies. Two different samples. The same number, on the wrong side of two different gaps.
I've observed this pattern for fifteen years, across three separate decisions distributors have to make about every AI project: build it, buy it, or wait. Here's how to tell which one you're facing.
Build: When nobody's solved your problem yet.
In 2012, I was VP at a master distributor of aerospace products. Customers were calling in constantly for price and availability. Quotes were too slow. We were losing orders to competitors who answered faster, and the process couldn't scale as it was.
I checked the market first. Only two companies quoted automation at the time. Neither integrated with our ERP. Both were expensive enough that the math wouldn't have worked even if they had.
So we built. I pushed our ERP vendor to expose a REST API — not a small ask in 2012 — and worked with a developer I knew personally to build a price-and-availability interface on top of it. We piloted with a handful of customers for a year before rolling it out further—total cost: $15,000 to $25,000, including API work.
It worked. It ran across the entire catalog for roughly a decade because the pricing data underlying it was already structured correctly in the ERP. Building was the right call in 2012 for one specific reason: buying wasn't a real option yet.
That reason expired. Today, more than 17 companies offer quote automation, covering far more ERP platforms than in 2012. The system I built stayed in service until a couple of years ago, when the company modernized its ERP stack. Whatever they run now almost certainly includes this out of the box.
That's not a failure story. That's a build that was correct for its moment, and correctly retired once the moment passed.
Buy: When 17 vendors already have [solve your problem].
Two clients came to me recently, on different ERP systems, asking the same question I'd faced in 2012: build or buy quote and order automation?
My answer was different this time. Buy.
Here's why. There are now more than 17 vendors in this space. That's not a market gap. That's a market. My advice to both is to run a real evaluation. Test multiple vendors. Calculate total cost of ownership, not just the sticker price. Pick the one that actually fits your specific ERP and your specific workflow, not the one with the best demo. And prioritize time to value — a vendor who gets you live in weeks beats one who promises more but takes a year.
Throughout this process, the executive team and owners will need to make several important decisions. They will need to define the current and future role of the existing ERP system and decide how willing they are to adopt a new solution. This solution could be a CRM or a quote automation tool and would become the primary platform that the sales team uses every day.
McKinsey's build-vs-buy framework organizes this into three questions worth running before you commit to either path:
1. Strategic importance. Is this actually where your company differentiates itself, or did you just assume it was because it's expensive or annoying? Quote automation isn't a competitive moat anymore. It's infrastructure. Seventeen vendors selling it proves that.
2. Capability availability. Has anyone in your organization owned this kind of judgment before? Not written code — owned the judgment. Someone who's sat with pricing exceptions and knows what "working" actually needs to mean.
3. Procurement and economic efficiency. What does this cost over three years, not what does it cost to get a first version running? BCG's research on ops tech buy-and-build decisions found that 65% of digital transformations fail to hit their stated objectives — usually not because the technology failed, but because nobody ran this math honestly upfront.
None of this tells you to build or buy on its own. It tells you what you need to know before you can answer that question for your own situation. In 2012, the answer was build. Today, for the same problem, the answer is buy. The problem didn't change. The market did.
Wait: The discipline nobody wants to practice.
Here's the option distributors skip. Waiting isn't doing nothing. Done right, it's the hardest of the three — and both of the examples below show what happens when nobody does it.
I had two conversations recently. Different distributors, different scale, same mistake.
The first: A fastener distributor moving data out of their ERP into proper storage for an LLM to analyze. On paper, that looks like the responsible move — infrastructure before application. But no one had first defined the question they were trying to answer.
They were building the foundation before anyone had named the pain it was supposed to solve, quantified what that pain was costing, or decided who'd own the answer once the analysis came back. Storage isn't a business case. It's a head start on a project nobody's scoped yet.
The second: A different distributor had a genuine, measurable win automating one workflow with an LLM. Real result, real value. And that one win convinced them they should build their own MRP system from scratch — no defined pain beyond "AI clearly works for us," no quantified cost of the problem they'd be solving, no owner named for a decision that size.
Same failure, two different scales. One company skipped the gate quietly, on the infrastructure side. The other skipped it loudly, on a project big enough to sink real money before anyone notices the gate was never there. Neither had stopped to ask the three questions that actually define waiting: what, specifically, is the pain? What is it costing, in real numbers? And who owns the decision once we have an answer?
This is the same mechanism behind most AI tool failures: nobody in the room is accountable for whether the outcome is right, only for whether the technology works. Software can't know your business. One early win can't tell you whether you understand a much bigger problem.
Waiting means three things:
- Define the pain precisely.
- Quantify what it's actually costing you.
- Align the people who'll own the decision before you make it.
Neither distributor above did any of the three before moving into build or deployment. That's not waiting. That's motion mistaken for progress.
The Question Beneath All Three
DSG's research found that every distributor in the top tier of their AI benchmark — companies with genuinely mature, production-grade deployments — assigned a single named executive owner. Not a committee. One person, with budget authority, accountable for the outcome.
That's the precondition. It's not the finish line.
A named owner who hasn't defined the pain, quantified the impact, or built alignment underneath their decision is exposed to the same mistake as the distributor with no owner at all. They just have someone specific to blame when it goes wrong. DSG also found that about half the distributors they surveyed either lack formal AI governance or aren't sure whether they have any, and one in five has no process at all for measuring whether an AI initiative returned anything. A name on the project doesn't fix that by itself.
This is the same failure I watched play out with a mid-size distributor that built its own ERP, led by a brilliant CTO and two sharp developers. It worked for years. Then the developer who understood the core logic left, and the system started dying that week — because nobody else had ever owned the judgment behind it—only the code.
Where This Leaves You
Three questions, in order. Has the market caught up to your problem yet? If not, and you can own the judgment, build. If it has, buy — and run the real evaluation, not the fastest one. If you can't yet define the pain, quantify it, and name who owns the decision, wait — and do the unglamorous work of getting ready, instead of mistaking one win for permission to make a much bigger bet.
Whichever answer you land on, the path afterward looks the same.
- Understand the pain and quantify it before you spend anything.
- Experiment small — the way I piloted my 2012 build with a handful of customers before betting the whole catalog on it.
- Invest once the experiment earns it, whether that means building, buying, or funding the next stage.
- Operationalize across the full customer base, not just the pilot group. Then ...
- Institutionalize it — name the owner, build the review cadence, make sure the judgment survives the day the one person who understands it walks out the door.
Skip a stage, and you're not moving faster. You're the mid-size distributor whose ERP died with its one developer, or the fastener distributor who mistook one automation win for a green light on an entire MRP. Same five stages, same order, whether you build it, buy it, or wait to do either.
The technology changes every few years. This question hasn't changed in the 15 years I've been answering it.
Nelson Valderrama (nelson@intuilize.com) is the founder and CEO of Intuilize. With 30+ years in distribution and nearly a decade of developing and deploying Machine Learning models tailored specifically for distributors, he helps mid-market industrial distributors identify and eliminate margin leakage across pricing, costs, and inventory — and keep it fixed. He built Intuilize on the premise that software alone doesn't earn trust and expertise alone doesn't scale: distributors need both a model built for their business and someone who knows distribution well enough to drive adoption and deliver real ROI.













