Building a Custom WMS With Wave and Batch Picking: Feasibility, Cost and the Parts Nobody Quotes

What wave and batch picking actually is once forty people are on the floor

Wave picking is not "group the orders and print a list." A wave is a scheduling and allocation decision made against inventory that is simultaneously being consumed by other waves, by replenishment moves, by cycle counts, and by a returns clerk putting stock back on the shelf. Batch picking then multiplies one pick per SKU across many orders, which means a single short pick can poison ten customer orders at once instead of one.

Watch the naive build die. Two waves are released four seconds apart on a Monday morning. Both allocate the last 6 units of SKU A1207 in location 04-B-12 because the allocation logic did a SELECT of available quantity, decided in application memory, and then wrote. Picker one takes all 6. Picker two arrives at an empty face and taps "short pick." Your system, having no concept of what to do next, silently cancels the line on eight orders. Nobody notices until the 3pm cutoff shows eight unshipped orders and customer service is emailing apologies. The fix is not a bug fix. It is a rewrite of the allocation layer to reserve stock atomically inside the transaction with SELECT FOR UPDATE or an equivalent row lock, plus a short-pick workflow that triggers re-allocation from an alternate location and re-plans the wave rather than dropping the line.

Once you accept that, everything downstream changes: your pick task becomes a state machine, not a row; your inventory table needs an on-hand versus allocated versus available split; and your wave release becomes a job that can fail and roll back cleanly. That is the real capability.

Allocation, reservations and the concurrency problem you cannot test on a laptop

The core of a WMS (Warehouse Management System) is a reservation ledger. On-hand quantity is not availability. Availability is on-hand minus allocated minus quarantined minus in-transit-for-replen. Every competent build we have shipped models three things separately: a location-level inventory record, an allocation record that points at a specific order line and a specific location and lot, and a movement record that is append-only.

Concurrency is where teams get hurt. Optimistic locking with a version column works fine for a picker updating their own task. It does not work for wave release, where you are allocating thousands of lines against contended locations in one shot. Use pessimistic row locks scoped tightly, order your lock acquisition consistently by location id to avoid deadlocks, and keep the transaction short by pre-computing candidate locations outside it. On PostgreSQL, watch for lock waits at wave release turning into a pile-up: a wave of 4,000 lines that holds locks for 90 seconds will block your RF handhelds mid-shift, and pickers will start reporting "the gun froze."

The other trap is allocation strategy itself. FIFO by receipt date is easy. FEFO by expiry date, which food, pharma and cosmetics all require, means your allocator must respect lot expiry and your short-pick fallback must not silently swap to a different lot. If you handle lot or serial traceability, allocation and picking are legally coupled: you must be able to answer, months later, which lot went into which shipment. Design the movement ledger as immutable from day one. Retrofitting traceability into a system that overwrites quantities is a full-quarter project.

The RF and handheld layer, where reality is worse than the demo

Your demo runs on office WiFi. The warehouse has dead zones behind the racking, aisles of metal that reflect 2.4GHz, and freezer areas where devices condense and reboot. A picker at aisle 22 will lose connection mid-task. What happens to the task?

The pragmatic answer for most builds is not full offline sync. It is task-level idempotency plus optimistic UI. Every confirm posts with a client-generated task confirmation id, the server treats a repeat of the same id as a no-op returning the original result, and the device retries with backoff until acknowledged. That gets you through a 30-second dropout without duplicating a pick. If you genuinely need offline picking, you are accepting conflict resolution: last-write-wins on a quantity field is exactly wrong for inventory, because two devices picking the same location will both report 6 remaining and you will lose a decrement. Offline WMS means per-device allocation leases handed out before the device goes dark, and reconciliation on reconnect. That is a large scope increase and we price it as such.

Device choice drives cost more than people expect. Zebra TC series and Honeywell CK65 running Android with an integrated imager are the common floor devices. A browser-based UI on those devices works, but the scanner comes through as a keyboard wedge or via a vendor intent API, and Chrome on a locked-down enterprise Android build behaves differently from Chrome on your desk. Budget real time for scan-to-field handling, keyboard suppression, and the fact that pickers wear gloves and will not use a soft keyboard. Voice picking, if it comes up, is a separate product decision. Honeywell Voice and Vocollect style workflows change the whole task model to a spoken confirm-and-check-digit loop, and they are not a skin over your RF screens.

Wave planning is an optimization problem, and you must decide how honest to be about it

Simple waves are filters: everything shipping via a given carrier before the 4pm cutoff. Real wave planning weighs cart capacity, tote count, congestion in the same aisle, carrier trailer departure times, and pick path length. The moment you do batch picking with carts, you are solving an assignment problem: which orders go in which of the 12 tote slots on a cart, so that the walk is short and the sortation at putwall is sane.

You do not need a mixed integer programming solver on day one. A greedy heuristic that clusters orders by zone overlap and sorts pick tasks by a serpentine path over aisle and bay coordinates gets you most of the benefit and it is explainable to the warehouse manager, which matters more than optimality. In practice, the single biggest win we have measured on client floors is not the algorithm, it is getting the location coordinate model right so the pick sequence actually matches the physical walking route including one-way aisles and cross-aisle gaps. If you later want real optimization, OR-Tools is the sane path, but scope it as a separate phase with a measurable baseline first. Do not let a vendor quote you "AI-optimized wave planning" on a floor where the location codes do not encode walking order.

Decide up front on wave cancellation. A wave that has been released and half picked, then cancelled because the carrier truck moved, needs every allocation returned to available and every partially picked tote reconciled. Teams that skip this end up with phantom inventory: stock the system thinks is allocated to a wave that no longer exists. It surfaces three weeks later as an availability number that is wrong and nobody knows why.

The integrations, because a WMS is never alone

Your WMS has to agree with at least three other systems about what is true. Orders come from an ERP (Enterprise Resource Planning) or an ecommerce platform. Shipments go to carriers. Stock levels have to feed back or you oversell.

If there is EDI, know the document types you actually need: 940 warehouse shipping order in, 945 warehouse shipping advice out, 943 and 944 for transfer shipments in and out, 947 inventory adjustment advice, and 846 inventory inquiry. Trading partners each have their own implementation guide and their own idea of what is required, so budget per partner, not per document. A single retail partner onboarding with test cycles is rarely under two weeks of calendar time regardless of engineering speed, because the partner's testing queue sets the pace.

On the ecommerce side, Shopify, NetSuite and similar send you order webhooks. Webhooks retry. Treat every inbound order create as idempotent on the external order id, store the raw payload, and process asynchronously. The failure we see most often is a duplicate order created because a webhook retried after a timeout while the first call was still committing, and now two waves are allocating stock for one customer order. Carrier integration through EasyPost, Shippo, or direct FedEx and UPS APIs adds rate limits and label voiding rules: a label bought and not used costs money, so wave cancellation has to reach into the carrier layer too.

What this costs and what drives the number

These bands come from Digital Heroes delivery across more than 2,000 projects, including warehouse and fulfillment builds of exactly this shape.

Adding wave and batch picking to a warehouse system you already run, where the inventory model, locations and user auth already exist, typically runs $15,000 to $60,000. The spread is almost entirely about whether your existing inventory model separates allocated from on-hand. If it does not, we are refactoring your core table under live data, and that is the top of the band.

Wave and batch picking as part of a first release, with receiving, putaway, cycle counting and shipping around it, runs $50,000 to $130,000 in 10 to 16 weeks. That includes RF screens on real devices and one host integration.

A full platform with multi-site, slotting, labor standards, putwall sortation, EDI and multiple carriers runs $150,000 to $350,000 over 6 to 12 months.

What specifically pushes this capability up: lot and serial traceability with FEFO, which touches allocation, picking, packing and reporting all at once. Multi-site with stock transfer, which turns your reservation ledger into a distributed problem. Putwall or sortation hardware, because you are now integrating a PLC or a light system and its own protocol. Genuine offline picking. And more than two host systems that each believe they own inventory truth. What keeps it down: single site, no lots, one order source, cart-based batch picking with a greedy path heuristic, and a warehouse manager who will sit with the team during design.

When you should not build this

If you ship under roughly 500 orders a day from one site with standard SKUs and no unusual compliance, do not build a WMS. Buy one. ShipHero, Shipedge, Da Vinci Unified, or the warehouse modules inside NetSuite or Dynamics 365 Business Central all do wave and batch picking out of the box, and you get RF apps, carrier integration and support for a monthly fee that is a fraction of a build. If you already run NetSuite, NetSuite WMS is usually the right answer even when it is annoying, because the integration you avoid is worth more than the flexibility you gain.

Custom is the right call in three situations. First, your process is genuinely non-standard in a way that is your competitive edge: kitting rules, made-to-order assembly on the pick path, regulated handling that no package models. Second, you are a 3PL and your client mix demands per-client workflows and billing rules that packaged software forces you to distort. Third, you have an existing product and the WMS is a feature inside it, not a system you are buying. Outside those, the honest advice is that a $200,000 custom build competing with a working subscription needs a real reason, and "we want it to fit exactly" is not one until you have run the packaged option and hit a wall you can name.

How to brief and vet a developer for this

Bring three things to the first conversation: your order volume and line count per day at peak, a photo or map of your rack layout with the location naming convention, and the list of systems that currently hold inventory numbers. Those three determine most of the design.

Then ask these. How do you prevent two waves from allocating the same units, and what isolation level or lock are you using? If the answer is "we check availability first," they have not shipped this. What happens on a short pick, mid-wave? Listen for re-allocation and wave re-plan, not for line cancellation. How does a picker's confirm survive a WiFi dropout without double-decrementing? You want to hear idempotency key, not "we retry." Show me your inventory schema: is on-hand separate from allocated, and are movements append-only? Ask what happens when a released wave is cancelled after half the picks and a label has already been bought. Ask how the pick sequence maps to the physical walk, and whether they have ever walked a floor to check it. Ask which handheld model they last shipped on and how the scanner input reached the field.

Someone who has done this will get animated about the boring parts: lock ordering, the movement ledger, the short-pick path. Someone who has not will talk about the dashboard.