Why Your WMS Costs More Than the Contract Says
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 Real Cost Was Never the License
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 a 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.
The Integration Risk Nobody Puts in the Business Case
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 Problem, Smaller Scale
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 Economic Shift
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.
This Is Not Software Becoming Free
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.
Where the Cost Moves
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.
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.
Configuration vs. Customization, Reframed
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 Differentiator Won’t Be the AI
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.
What You’re Paying For When You Customize
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.
Who Wins This Transition
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.
Not Every Retailer Starts From the Same Place
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.
Why Now
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.
Margin Pressure Is the Forcing Function
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.
A Pragmatic Path
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.
What De-Risked Adoption Looks Like in Practice
- Fund the pilot from an existing DC budget, not a new capital request.
- Prove the model at one site before renegotiating the SaaS contract across the rest of the network.
- Let the operating team closest to the floor decide when a functional type is ready to scale — not the vendor relationship, and not a fixed calendar date.
- Treat operator trust as a milestone, not an assumption. A pilot isn’t proven when the numbers clear. It’s proven when the team running the site stops keeping the old workaround on standby.
VARGO®’s Point of View
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 here.
About the Authors
William Korkki
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
Brooks Hamilton is the CEO and Founder of AI Strategy Advisors, an Austin-based consultancy specializing in crafting AI strategies for wholesale distributors, trade associations, and buying groups. With over 20 years of experience deploying AI decision support applications, Brooks brings a unique blend of technical expertise and distribution industry knowledge to help organizations navigate the rapidly evolving AI landscape.
A seasoned veteran in the tech industry, Brooks spent 17 years at Zilliant, where he held pivotal roles in Professional Services and Product Management, including Vice President of the Professional Services team. His tenure was marked by ground-breaking work in AI-driven price optimization and sales effectiveness in B2B companies. Brooks also spearheaded Product Management at several Austin-based startups.
Passionate about the transformative impact of AI, Brooks is a sought-after speaker having spoken at over 25 industry events. He is a thought leader on the adoption of AI and Pricing best practices among wholesale distributors, manufacturers, and logistics organizations. He is deeply committed to leveraging AI for positive outcomes in business, society, and scientific discovery.