Retailers still need stability. They no longer have to buy it in a one-size-fits-all package to get it. A VARGO® point of view on the economics of AI-assisted, operation-specific WMS builds.
By William Korkki, Chief Product Officer, VARGO®, and Brooks Hamilton, CEO and Founder, AI Strategy Advisors · Updated October 2026 · 14 min read
AI-assisted development has cut the cost of building and maintaining warehouse software that fits a specific operation, while the real cost of a packaged WMS (implementation, upgrades and services engagements) hasn’t moved.
In the paper’s single-site example, one distribution center could spend roughly $400,000 once and about $100,000 a year in maintenance, rather than $1.5 million to implement plus $500,000 a year in subscription. The lowest-risk way to test it is a single-site pilot funded from an existing DC budget.
DC Velocity Supply Chain Short Takes, Sept. 28, 2026: William Korkki, VARGO®, interviewed by David Maloney.
David Maloney: Welcome to Supply Chain Short Takes, a brief discussion with an industry expert on important issues affecting supply chain management. I’m David Maloney, Group Editorial Director at DC Velocity. Joining me today is William Korkki, Chief Product Officer at VARGO. Welcome, William. It’s good to have you with us today.
William Korkki: Thanks, David. It’s great to be here.
David Maloney: It’s our pleasure. William, VARGO has been in the warehouse automation business for decades, but the industry looks very different today. If someone only knew VARGO from, say, five or ten years ago, what would surprise them about what the company does now?
William Korkki: What would probably surprise them the most is that VARGO is no longer exclusively focused on moving products through automation. We’re increasingly helping customers make better operational decisions through software, data and AI. We’ve spent decades learning how warehouses actually run, deploying our best-of-breed COFE WES to optimize operations, and doing brownfield and greenfield mechanical designs and systems integration. Today, we’re combining that operational expertise with modern software approaches and AI capabilities. The conversation isn’t just about conveyors, sorters and execution systems anymore. It’s about how quickly a customer can adapt processes, integrate technologies and continuously improve operations using software and AI as strategic tools.
David Maloney: In talking about warehouse automation, everyone has certain assumptions. What are some assumptions about warehouse automation and software that you think are starting to break down?
William Korkki: I think one of the biggest assumptions that’s starting to break down is that packaged software is always safer and custom software is always risky. Historically, that made sense, because custom code was expensive to build, difficult to maintain, and dependent on the developers who wrote it to support it. But AI is changing the equation. Documentation, testing, configuration and even code generation are becoming dramatically easier because they’re AI-based. That development knowledge never walks out the door. Another assumption that’s fading is the idea that operations should adapt to the software. Increasingly, we’re seeing operational requirements treated as non-negotiable, and software adapting to the operations instead of the other way around.
David Maloney: William, you mentioned coding, and of course artificial intelligence is everywhere these days. AI code is making software easier to build, customize and adapt. How do you think that changes the way companies should evaluate WMS solutions?
William Korkki: David, I think companies need to spend less time asking how fancy the features are, or how well they map to their operations, and more time asking how easily the solution can evolve as the business changes. Historically, buyers evaluated a WMS based on a feature checklist and how proven the install base was. In an AI-enabled world, the ability to modify workflows, integrate systems, support unique operations and continuously improve makes buying a set of pre-built, standardized features feel like catching up to yesterday instead of building for tomorrow. The real question shifts from buying software to buying adaptability.
David Maloney: So when companies compare the cost of traditional WMS projects against potential AI software build approaches, where do the financial advantages start to show up?
William Korkki: AI is changing the economics of warehouse software. It starts with the first contract you sign, and it doesn’t stop. The first implementation and licensing or SaaS costs will be a fraction of a traditional WMS. Most traditional WMS projects spend a significant amount of time and money documenting requirements, configuring workflows, building integrations, developing custom extensions, and testing changes and upgrades. AI will reduce the effort of all of those. The ongoing savings aren’t just in recurring software cost, but in the long-term total cost of ownership. Changes can be made faster and more predictably, so organizations can spend less time fighting the software and more money improving the operation.
David Maloney: I think everybody would like that sort of thing. Beyond implementation and software cost, where could companies see efficiency or financial gains?
William Korkki: Right now, I think you can achieve WMS parity with an open-core AI platform at a major cost saving. But in the long run, the bigger benefits are more operational than technical. AI can help managers make better decisions on labor deployment, yard management, transportation management, equipment utilization and maintenance, and pretty much every other part of the warehouse. Those improvements show up every day in productivity, throughput, service levels and labor costs. The current ROI might be cheaper software, but the goal is a warehouse that learns and improves faster.
David Maloney: Where do you think tier 3 WMS solutions fit in the market, and what kind of operation are they best suited for?
William Korkki: Tier 3 WMSs are an emerging technology, and being an early adopter is going to come with some risk. The facilities that minimize that risk will have well-defined, standardized processes, limited complexity and variability within those processes, and some level of control over both supplier and customer packaging and shipping requirements. Where things get interesting is when AI-native platforms allow organizations to start with a lighter footprint and then evolve over time. The discussion becomes less about tiers and more about fit, adaptability and total value.
David Maloney: Let’s look at some predictions. Over the next three to five years, what do you think will separate warehouse operations that keep up from those that fall behind?
William Korkki: The winners are going to be organizations that adapt faster than their competitors. Companies with large, monolithic, aging WMS platforms will fall behind. Early AI WMS adopters will have systems that evolve quickly, data that supports agentic AI decision-making, teams that embrace continuous improvement without software limitations, and leadership that views AI as an operational capability and not just a technology project. In a world where change is accelerating, adaptability becomes the competitive advantage.
David Maloney: I agree with you. That ability to adapt is really key to being successful in the future. How can someone find out more about the solutions we discussed today?
William Korkki: You can see more on our website at vargosolutions.com, or reach out to me directly. I’d love to have a conversation.
David Maloney: That’s vargosolutions.com. Thank you, William, for being with us today.
William Korkki: Thank you, David.
David Maloney: We’ve been talking today with William Korkki, Chief Product Officer at VARGO. This has been Supply Chain Short Takes.
Warehouse management software has gone through three eras. It started on paper, moved to basic digital record-keeping, and then settled into packaged, configured platforms. For a long stretch, that was the right approach. Standardized software worked. It was proven across hundreds of customers before it ever reached your facility and buying it off the shelf meant the development cost could be spread across many buyers, and you weren’t the one finding its bugs.
Somewhere in the last decade, customization became the factor organizations avoided due to the additional cost rather than the thing they weighed. Most operations still required some customization. The average template never quite fit, but they took on as little as they could get away with, because a custom line of code was a liability the moment the developer who wrote it left the building: expensive to maintain, harder to explain, and a landmine buried in every future upgrade. Packaged software’s entire pitch was that someone else had already solved the generalized version of your problem, so you didn’t have to own that risk. Customers didn’t buy that pitch because they preferred less fit. They bought off-the-shelf because the alternative was worse.
That calculus is reversing — not because packaged platforms got worse, but because AI-assisted development has collapsed the cost of building and maintaining software that truly fits an operation, while the real cost of the packaged model never moved.
The license, or the SaaS fee, is the number on the invoice. It is not the number that determines total cost of ownership. Implementation commonly runs close to the first year’s license or subscription fee, and on many engagements meaningfully more, before the software does a single unit of work. After go-live, the treadmill starts: a new feature ships, and using it requires a services engagement to deploy it across every site, every time, indefinitely.
SaaS was supposed to fix this. It didn’t; it repackaged it. A license cycle that once ran into the eight figures over five years became a smaller annual subscription with a lighter step-up implementation cost. That gave customers real relief, since the SaaS model no longer required one large number on a single purchase order. But the multi-year total cost of ownership didn’t fall nearly as much as the pricing model implied. The customer was still paying for someone else’s entire software organization — its product managers, its QA function, its company-wide support desk spread across thousands of accounts — not just for their own use of the system.
For decades, retailers rented stability from a vendor’s product roadmap because the only alternative was building and owning a system themselves — an organizational cost and risk most retailers were never staffed to carry. AI-assisted development hasn’t erased that alternative’s risk; it has created a third option in between.
A retailer doesn’t have to choose between a tier-1 SaaS platform and solving it alone. It can get a system built to fit its operation by a partner who already knows how its operation runs, without taking on the software organization that build would otherwise require.
Retailers still need stability. They no longer have to buy it in a one-size-fits-all package to get it.
Packaged software is sold on a simple promise: the vendor has already solved the general version of your problem, so you don’t have to build anything. That promise holds up on the sales call. It rarely holds up once the system meets an operation that isn’t the standard case.
Spar Group’s SAP rollout is a current example of what happens when it doesn’t. In February 2023, the South African retailer began implementing a new SAP platform, including a new warehouse management system (WMS), across its distribution operations. The project ran into trouble when pricing visibility broke down, and warehouse inefficiencies drove up labor and transport costs. By the company’s own account, those issues contributed to roughly $107 million in lost sales in fiscal 2023, a figure that outside estimates put above what the entire implementation was budgeted to cost. As of its 2024 annual report, Spar described the effort as “significant progress,” not resolution.
The core conflict was fit. A standardized WMS assumes a standard approach to receiving, picking, and distribution. Spar’s operation, built around its own regional distribution model, didn’t match that assumption cleanly, and the gap showed up as manual workarounds and margin pressure rather than a clean go-live.
Source: The Register, “Stumbling ERP project racks up sales losses greater than budget” (Jan. 2025), citing Spar Group’s 2024 Integrated Annual Report and Bloomberg.
The same dynamic shows up in a quieter way even when a rollout succeeds: organizations that do not fit the software provider’s out-of-the-box standard are required to pay twice, once in process compromises, and again in the connectors and reporting tools required just to get their own data back out of a system they already own.
The promise underneath every packaged platform is the same: “We’ve already generalized this, so you don’t have to build it.” That promise becomes a liability the moment an operation isn’t the standard case; and very few operations are.
The traditional model has two cost lines: the license or subscription fee, and an implementation cost on top of it before the system is live. After that, an upgrade tax accrues indefinitely — the cost of adopting features the subscription was supposed to already include.
The emerging model has two cost lines as well, but they behave differently: an AI-assisted build cost, incurred once, followed by a materially lighter maintenance cost. For example, a single distribution center facing roughly $1.5 million in implementation costs plus $500,000 a year for a packaged WMS subscription could instead expect an AI-assisted custom build for that same site to cost roughly $400,000 once, with ongoing maintenance closer to $100,000 a year going forward, assuming that maintenance is outsourced. A retailer with its own team supervising the system in-house would see that number shift accordingly.
Illustrative single-site comparison. Traditional Year One reflects $1.5M implementation plus a $500K SaaS subscription; a new deployment may carry additional customization fees on top.
It is tempting to read that gap as proof that AI makes software free to build. It doesn’t. It changes what the customer is paying for. Under the packaged model, the fee funds a vendor’s entire software organization — product management, release engineering, quality assurance, and a support desk — amortized across a broad set of accounts over time. Under the AI-assisted model, the customer funds a smaller team supervising AI-generated code for the judgment calls that still require a person: which business rule matters, which exception is real, which shortcut isn’t safe to take.
That is labor arbitrage, not a trick only one side of the market can use. Every WMS vendor has access to the same AI-assisted development tools. The advantage goes to whoever pairs those tools with the deepest, most specific knowledge of the fulfillment operational best practices, the technology tools used (e.g. WMS, WES, control systems, etc.), and how a given customer’s operation runs.
A useful way to see this shift is across the project lifecycle, rather than the top-line total. In a traditional build, the build phase itself — writing and testing custom code — dominates the budget. AI-assisted development compresses that phase specifically. It doesn’t eliminate design, testing, deployment, or ongoing maintenance — those hours don’t go to zero — but they stop being dwarfed by the build line, and the overall cost curve levels out across every stage of the lifecycle.
Where the cost moves across a WMS project: AI compresses the build phase most
The number that matters isn’t “AI is cheaper.” It’s that the single most expensive line item in a WMS build — custom development labor — is the one AI compresses the most.
Custom code carried real risk, and organizations avoided it for good reason: it was logic that only one developer fully understood, expensive to maintain, and challenging to fully transition from vendor to customer. Packaged, standardized software existed to remove that risk.
That risk profile changes when an AI system can write, document, and re-derive that same logic on demand. A unique fit stops being the expensive, fragile choice and becomes the default, because the marginal cost of building for your operations has collapsed.
The tools that write code will commoditize quickly; every serious competitor will have access to comparable AI-assisted development capability within a short window. The differentiator will be the data and domain knowledge directing those tools. An AI model with no institutional memory of how eCommerce and retail fulfillment runs will produce generic, functional code. An AI model directed by decades of pattern recognition — how different fulfillment operations behave under peak volume, under SKU churn, under labor constraints — will produce code that fits the operation the first time, not after several expensive rounds of rework.
Most of the complexity a WMS has to accommodate isn’t an efficiency problem. Efficiency is exactly the kind of problem algorithms already solve well. It’s usually a business-criticality problem: a facility might need to support multiple inbound receiving methods because its supplier network requires it, not because that configuration is the most efficient one to run. That requirement doesn’t go away under AI-assisted development. What changes is the cost of accommodating it: under the traditional model, a customization’s cost scaled with how far it sat from the vendor’s generalized template — the further from average, the more expensive. AI-assisted development collapses that scaling, so a one-off workflow that once meant a costly, fragile customization now costs close to what the standard workflow costs to build in the first place.
There’s a second difference that compounds the first. A traditional WMS is designed and optimized once, at deployment, against the set of assumptions true at that moment: this supplier network, this SKU mix, this labor model. When those assumptions shift, and they always do, the system doesn’t shift with them. It takes a services engagement to catch up, and until that engagement happens, the operation is running against yesterday’s version of itself. An AI-assisted system isn’t optimized once and left; it optimizes continuously, against whatever the current set of assumptions is. The fit doesn’t decay the way a packaged deployment’s fit decays the day after go-live.
System integrators and domain experts who sit closest to a customer’s actual operational pain are positioned to win this transition. Large packaged-software product organizations are not. Their product managers are, by the structural nature of large organizations, incentivized to manage internal roadmap politics as much as to solve a specific customer problem.
Legacy platforms carry cost structures that limit how aggressively they can compete on price: large product organizations, large support and QA staffs, and license revenue engineered into the business model. An organization with thousands of employees supporting a packaged platform cannot simply cut its price to match a lean, AI-assisted build without restructuring the business itself. That anchor is not a technology problem. It is a balance-sheet problem, and it moves slowly.
Readiness for this shift isn’t evenly distributed. Some retailers are eager, resourced, and one decision away from starting. Others are years out because the organization isn’t built to own software yet. That gap is what will separate the first movers from the fast followers.
A retailer that already runs significant software of its own (order management, routing, store applications) is functionally a software organization first and a retailer second. Directing an AI-assisted WMS build, whether done internally or through a partner, is a natural extension of capability that team already has. That retailer moves early, because the decision is operational, not existential.
A retailer that has outsourced most of its technology to SaaS and carries minimal internal IT capability faces a materially higher bar. The decision in front of that board isn’t “build or buy.” It’s “become a software organization or stay an organization that buys software.” That’s an identity question, not a procurement decision, and it takes longer to resolve, which is exactly why the retailers asking it now, rather than waiting for the market to force the question, are the ones who’ll still have a choice in how it gets answered.
The winners in this transition, integrators and retailers alike, aren’t just organizations comfortable owning software. They’re the nimble ones that also carry deep knowledge of how to build and run it.
The current board conversation requires new capital: several million dollars in fresh implementation spend to escape a SaaS commitment the organization is already paying to maintain. That is a hard ask, because it requires new money to fix a problem the business is already funding.
The new-world ask is an order of magnitude smaller, and it often fits inside a budget that already exists. Consider a board scenario with five distribution centers, each paying roughly $500,000 a year for a packaged WMS subscription. A five-year obligation would add up to $12.5 million. Spending roughly $7.5 million once, about $1.5 million per site, to eliminate that obligation outright is a straightforward capital decision for almost any board. Piloting the approach first, at $400,000 from an existing DC budget with no new capital request at all, isn’t even a board conversation — it’s a line-item approval.
Five-DC scenario: five-year SaaS obligation vs. one-time build vs. pilot
This shift is arriving now because retail margin is under real pressure at the same moment as the technology landscape is changing. Costs have been rising while pricing power has been eroding, and that combination — not curiosity about AI — is what turns a promising idea into an approved project. The risk of waiting is not neutral: the first mover in a category captures the cost advantage and the operational maturity while the approach is still rare. The fast follower inherits a market where every competitor already has the same advantage, and the differentiation is gone.
The question in front of a COO right now isn’t “should we adopt AI.” It’s “how do we lower cost” — and this transition is one of the few paths available with a payback measured in months, not years.
The obvious rebuttal to everything so far is that if packaged systems carry integration risk, doesn’t a custom, AI-assisted build carry its own version of that risk? A system with no other customer base to have already proven it, no years of edge cases someone else already found. That’s a fair question, and the honest answer is ‘Yes’. A custom system does not inherit the track record of a platform that has run at hundreds of sites for a decade. What it does not inherit is the packaged model’s blind spot: rules and assumptions built for a standard customer, with differences so profound, the template was never going to match. The risk profile is different, not absent. The right response to a different risk profile isn’t to ignore it. It’s to prove it in stages before it carries real order volume.
None of this requires an all-or-nothing decision. Adoption does not mean replacing a packaged WMS across a dozen sites at once. It means piloting one site of one functional type: e-commerce-only, retail-only, or omnichannel. From there, the AI-assisted custom system gets built and proven at that one site, both on economics and on operational fit, before scaling further.
Lessons learned at an e-commerce-only site don’t fully transfer to an omnichannel site. Running more than one pilot in parallel, across structurally different site types, is not reckless. It’s efficient, because each track can move on its own development and testing cycle without depending on the others.
As AI-assisted development shortens the design, build, and test cycle, running parallel builds across similar site types becomes a genuine option. Not because risk disappears, but because the cost of being wrong at any single site drops enough that an organization can afford to run more experiments at once, rather than betting the whole modernization on one outcome.
The AI that writes code is becoming a commodity. What isn’t commoditizing is decades of pattern recognition about how retail fulfillment runs. That includes a long record of live, brownfield transformations, and direct experience with what makes a WMS implementation succeed or fail at the floor level, not just in the design document.
That knowledge is what turns AI-assisted development from a generic build into a build that fits an operation the first time. It is the same discipline VARGO® has always brought to a live facility, applied now to a new category of decision: knowing that a system only holds up if the floor team trusts it enough to rely on it, and that trust gets built before go-live, not after.
For retailers evaluating this shift, the conversation worth having isn’t “AI or not.” It’s what a de-risked, single-site pilot looks like for your specific operation, and what it would cost to find out. VARGO® is available for that conversation.
In the paper’s single-site example, a packaged WMS costs about $1.5 million to implement plus $500,000 a year in subscription. An AI-assisted custom build for the same site costs roughly $400,000 once, with maintenance closer to $100,000 a year if outsourced.
The license or subscription is only the number on the invoice. Implementation often runs close to the first year’s fee or more, and after go-live each new feature needs a services engagement to deploy across every site.
There is now a third option: a system built to fit the operation by a partner who knows how it runs, without the retailer taking on a full software organization. How fast a retailer can move depends on how much software it already runs itself.
The risk is different, not absent. A custom system has no track record at hundreds of sites, so it should be proven in stages, starting with one site, before it carries real order volume.
Pick one site of one functional type (e-commerce-only, retail-only or omnichannel) and fund it from an existing DC budget. Prove it on cost and operational fit, and let the floor team decide when it’s ready to scale.
William Korkki, Chief Product Officer at VARGO®, is a supply chain leader with over 25 years of experience driving organizational transformation and bottom-line results. His background includes senior roles at Manhattan Associates, Kimberly-Clark, Capgemini, and BearingPoint, partnering with global retailers, consumer products companies, and manufacturers to design and deliver IT roadmaps that solve complex business challenges. William specializes in omni-channel fulfillment, planning, and operations, with a track record of building high-performing teams and world-class supply chain solutions.
Brooks Hamilton is the CEO and Founder of AI Strategy Advisors, an Austin-based consultancy that builds AI strategies for wholesale distributors, trade associations and buying groups. He has more than 20 years of experience deploying AI decision support applications, including 17 years at Zilliant, where he led Professional Services as Vice President and worked on AI-driven price optimization for B2B companies. He has spoken at more than 25 industry events on AI adoption in distribution.
