WMS Customization vs. Configuration: Which Requests Are Actually Worth Writing Code For

We had a client who signed a WMS contract in Ontario, California in 2024. Three months after go-live, a $47,000 change order landed on the CFO's desk: "custom wave-rule development." The owner nearly flipped — not because of the price, but because someone later discovered the feature was a dropdown menu in the admin console. The implementation consultant had clicked it open in twenty minutes.

I wasn't surprised. After years selling 3PL contracts, I've watched clients burn enough money on the words "custom development" to buy the system twice over. So here's the inside baseball from the vendor side of the table: how implementation firms price custom dev, which "custom requests" are really just configuration, and how to write the contract so the meter stops running.

Where the margin actually hides in a quote

You can't negotiate until you understand the other side's math.

Based on the contracts I've signed over the years, WMS implementation consultants in the US bill roughly $1,200 to $2,500 per man-day — that's an industry-experience range, and it swings a lot by vendor tier and consultant seniority, so get it confirmed in writing before you sign anything. Here's the structural catch: pure configuration work — setting up locations, rules, workflows — usually comes bundled in the implementation package or at a lower rate. The moment a requirement gets labeled "custom development," pricing switches to estimated man-days times that daily rate.

And who estimates the man-days? The implementer. Whether a request takes 20 days or 80 is their call, and buyers rarely have the technical standing to challenge it. The deeper truth: custom development carries far fatter margins than configuration. Configuration is standardized and competitive, so pricing stays honest. Custom dev is a black box — 60 days or 100 days is whatever "experience" says it is. So you'll notice a pattern: any requirement described even slightly vaguely gets an instant verdict of "this needs custom development." It's not malice; it's the business model. Selling man-days pays better than selling checkboxes.

We had a home-goods e-commerce client in California, 2023. Their requirements doc had one line: "FIFO by lot, with lots under 90 days of shelf life shipping first." The implementer came back with a quote: custom development, 180 man-days. At $1,500 a day, that's $270,000. They almost signed. Luckily their ops director asked one question: can your lot-strategy module just do this? Answer: yes. Standard functionality — turn on lot management, set two rules, three days of work, included in the implementation package. The difference between 180 man-days and 3 days was a single question nobody thought to ask.

So here's my first contrarian take: a good three-quarters of what buyers call "customization" is configuration nobody bothered to look for. Your business isn't that special. You just started paying for code before you learned what the system already does.

Sort every request into one of three buckets

My field-tested method for the code-or-configure question starts with sorting:

Bucket one: pure configuration. The system already has the toggle, the rules engine, the module — you just haven't found it. Wave strategies, putaway rules, cycle-count policies, user permissions, label formats. Writing code for these is a tax on laziness. The right move is making the implementer state "delivered via standard configuration" in the proposal, with acceptance criteria to match.

Bucket two: light customization. The core process stays untouched; only the edges get code. Custom reports, integrations with your ERP or e-commerce platform, tweaked label layouts. Code is fine here if the scope stays fenced — reports and interfaces are relatively isolated, so upgrades barely touch them. The negotiation is about per-interface pricing versus a flat fee, and who owns the interface documentation.

Bucket three: heavy customization. This rewrites core workflows — the system's skeleton. Special order-consolidation logic, multi-warehouse allocation rules, nonstandard billing models. This is the only bucket where "should we write code" deserves a real debate. My advice to clients: ask three questions first. Is this process our competitive advantage? Will it change often over the next three years? Does the business stop without it? Three yeses, then talk custom dev. A single no means adapt your process to the system first.

We had a beauty brand in Texas, 2024, with a genuine bucket-three need: cross-dock consolidation rules across three warehouses, combining one customer's orders from all three sites into full containers by destination to save on the international leg. Real customization — no configuration could do it. We signed 45 man-days of development. But look at how we signed it: the scope was broken into 12 acceptance criteria in a contract appendix, each specifying inputs and outputs; free bug fixes for 90 days post-delivery; and — most importantly — an upgrade-compatibility clause stating that if a major vendor upgrade broke the custom functionality, the implementer would fix it free of charge, twice. That single clause paid for itself during a major upgrade in 2025, saving at least $30,000 in re-testing.

The most expensive part is never the development

Most buyers do the math only up to go-live day. That's the trap. Custom development carries three hidden costs, each nastier than the original build:

Upgrade re-testing. WMS vendors ship at least one major release a year, and your custom code has to be re-tested — and often rewritten — every time. Industry experience puts the adaptation cost per major upgrade at roughly 30% to 50% of the original development fee, depending on how deep the customization goes. Over three years, that line item quietly overtakes the build cost.

Version lock-in. The deeper the customization, the scarier the upgrade. Skip upgrades and you miss new features and security patches. The most extreme case I've seen: a client frozen on a 2019 release for six years because 40-plus customizations made every upgrade a minefield. When they finally replaced the system, the data migration was twice as painful as it needed to be.

People lock-in. Custom code documentation is usually garbage. After a while, only the one or two developers who wrote it can touch it. When they leave, the implementer owns you — a minor bug fix quoted at 10 man-days, and you can't push back because nobody else dares touch that code.

So my second contrarian take: custom development isn't buying a feature, it's buying debt. Go-live day feels great; upgrade day hurts. The right question isn't "how much does this customization cost" — it's "how much will this customization cost over five years."

Three lines your contract must have

Enough insider talk — here's the actionable part. When customization is unavoidable, these three clauses go in the contract or you don't sign:

One: lock the scope in an appendix. Requirements listed line by line, acceptance criteria down to input-output granularity. Anything that says "to be confirmed by both parties later" is a future change order. Implementers love leaving the scope ajar; your job is to shut every gap.

Two: cap the change-order rate upfront. Maximum man-day rate in writing, and anything exceeding the estimate by more than 20% needs your written approval. This is the clause that stops 60 man-days from becoming 120. Of the contracts I've signed without it, nine out of ten blew the budget.

Three: an upgrade-compatibility clause. If a major vendor upgrade breaks the custom functionality, the implementer fixes it free — stipulate the number of times, say twice — and anything beyond that gets negotiated. Most buyers never think of this clause, but it's the one that saves the most money over three years.

Next time you negotiate a contract, ask these three questions: can configuration do this? What's the capped daily rate? Who fixes it free when an upgrade breaks it? Ask all three, and the other side will know they're not dealing with an easy mark.

By Susan, 3PL Sales Director