Skip to content
§
§ · build vs buy

Warehouse Execution System Development: Custom Build or Vendor Software

Buy the vendor's execution software if your building is single vendor. Momentum in an Intelligrated building or Dematic iQ in a Dematic building gives deeper machine control and one support relationship.

Warehouse management software overview illustration for Warehouse Execution System Development Build vs Buy Guide.
The short answer

Buy the vendor's execution software if your building is single vendor. Momentum in an Intelligrated building or Dematic iQ in a Dematic building gives deeper machine control and one support relationship. Build only when the building genuinely mixes goods-to-person, sortation and manual picking from different suppliers, which is where no vendor product can be neutral.

What Momentum, Dematic iQ and Manhattan already do well

The clearest advice in this whole category: if your automation came from one supplier, buy that supplier's execution software and stop reading. Honeywell Intelligrated Momentum orchestrates an Intelligrated building beautifully. Dematic iQ does the same for Dematic. The machine-level control is deeper, the diagnostics are richer, and when something faults at eleven at night you have one phone number rather than an argument.

Manhattan Active Warehouse Management approaches from the warehouse management side and is strong on order and inventory logic, which matters if your constraint is order flow rather than machine timing. Korber sits between the two through a portfolio assembled from several products, and for a building with a mixed but conventional estate that breadth is genuinely useful. Blue Yonder and Fortna both bring real execution capability alongside design work.

What all of them do well is drive their own equipment. A vendor controller is excellent at its own machine, and reproducing that depth is not a sensible use of your capital. Nothing below suggests rebuilding a sorter controller or a robot fleet manager.

Buy also if your automation is one sorter and some conveyor. The balancing problem does not exist yet, and buying an execution layer for it is spending six figures to solve a scheduling question a supervisor already answers correctly.

Where they stop: no vendor product is neutral in a mixed building

Walk the floor at two in the afternoon during a peak wave. Four pick stations at the goods-to-person system stand idle because the wave that was released is heavy on items stored in the manual module. The sorter is starved for twenty minutes, then floods and backs up onto the merge. Two operators wait at a station whose robot queue emptied. Nobody made a bad decision. The building simply has no component whose job is to decide what work goes where and when, second by second, across subsystems from different suppliers.

Your warehouse management system (WMS) knows orders, inventory and shipping, and releases work in waves expecting the floor to absorb it. Each piece of automation arrives with its own controller, excellent at its own machine and indifferent to everything else. Between those two layers sits the sequencing and balancing decision, and in most buildings it is made by a supervisor with a radio.

The reason a vendor product cannot fill that gap in a mixed building is commercial rather than technical. Your integration to a competitor's robot is a project scoped by the company selling the competing robot. Both will integrate other equipment, and both do, but the depth and the diagnostics are asymmetric, and the release logic that decides which vendor's subsystem gets fed first is exactly the logic neither will write against their own interest.

The second thing they leave is degraded mode. Automation vendors design for the nominal case. Real buildings run with something down almost every day: a sorter arm out, an aisle blocked, a lift in fault, half a robot fleet charging. In most buildings a supervisor declares a workaround over the radio and the systems keep releasing work as though nothing happened, so recovery is worse than the outage because the buffers are full of work that has to be untangled by hand.

The arithmetic: throughput recovered versus the cost to build

This category does not price per seat, so the arithmetic has to run on throughput and hours. Use your own numbers and be conservative.

Take your design rate and your actual peak rate, and take the gap seriously. Then convert it into labour: count idle station time across a shift, meaning operators standing at a station whose queue emptied or waiting on a starved merge. If that is nine labour hours per shift at a loaded rate of $24, across two shifts and 300 operating days, it is about $130,000 a year.

Against that, a focused first release covering the resource model, the continuous release engine, orchestration across one automation island plus the manual modules, and a building-level operations view runs $120,000 to $250,000. Take the middle at $185,000, add migration, add year two support, and the two-year figure is roughly $254,000.

So the crossover sits near nine idle labour hours per shift, which in a building of 120 associates is about four percent of direct hours, and in most mixed buildings shipping upward of twenty-five thousand units a day it is already being lost. Below that, the case is weak. Above it, the release engine pays for itself before the sorter integration is finished.

What we will not do is put a number on the throughput uplift. It depends on your order profile and your building, and any firm quoting a percentage before walking your floor is selling you a brochure figure.

What a custom build actually costs

  • First release: $120,000 to $250,000 in 14 to 20 weeks. A live model of every resource with capability, buffer occupancy and health, a continuous release engine scoring work against current resource state, orchestration across one automation island plus the manual modules, and a building-level view naming the current constraint.
  • Full execution layer: $350,000 to $800,000 across 9 to 18 months. Adds every subsystem, labour balancing, designed degraded modes with automatic re-routing of committed work, and event history complete enough to replay a shift.

Migration runs 10 to 25 percent of the build. Here it is less data movement than configuration archaeology: capturing the real capability and buffer sizes of equipment whose documentation is a printed manual from the integrator. Year two runs 15 to 20 percent of the build annually.

What drives the number up: the count of distinct equipment vendors, since each is a separate integration. The age of the equipment, because older controllers speak older protocols. Whether you run a plant network segregated from corporate systems, which is correct practice and adds coordination. The number of buildings, since a second site is never a copy. And the availability of test windows, because integration testing against live automation is scheduled around production, and that scheduling is the real critical path rather than any engineering task.

The four situations where building wins

  • Regulatory fit. Less about regulators here and more about the safety and network boundaries that behave like them. Equipment safety functions stay in the machine controller and must not be reachable from your layer, and a plant network segregated under the segmentation practice described by ISA-95 and IEC 62443 changes how software is deployed and who signs off. A vendor product assumes its own deployment model. A build has to accept yours.
  • Scale economics. Throughput past the point where idle station time exceeds roughly nine labour hours per shift, typically a mixed building shipping upward of twenty-five thousand units a day.
  • A workflow that is your competitive advantage. The balancing logic itself. Continuous release scored against live resource state, with cutoffs and carrier trailer schedules as constraints rather than as waves, is the operating knowledge of your network, and it is the thing you would want to copy to a second site.
  • Integration sprawl across three or more systems. A goods-to-person system, a sorter, a print and apply, a robot fleet manager and a warehouse management system. Once three vendors are in the building, the neutral layer is the one you own or the one nobody writes.

How to decide in a week

Do not start with a vendor demonstration. Start with a stopwatch and one afternoon.

Pick your busiest two hours. Station one person to record, every five minutes, how many pick stations are idle, whether the sorter is starved or backed up, and where the queue is longest. Do it for four consecutive days. At the end, ask three managers independently where the constraint is. If all three agree and the log agrees with them, you have a visibility problem you could solve with reporting, and you should. If the three disagree and the log shows the constraint moving between an induction step, a merge and a pick station, you have the problem a neutral execution layer exists to solve.

Then run the second test in ten minutes. Ask what happens to work already committed to a subsystem when that subsystem faults. If the answer is that a supervisor sorts it out afterwards, that is your degraded mode, and it is costing you more than the outage does.

Move to a paid discovery phase. Ours runs three to four weeks for this category and includes time on your floor, ending with a signed product requirements document covering the resource model, the release scoring rules, each machine interface named with its protocol and its late-message behaviour, the degraded modes per subsystem, and acceptance criteria measured in units per hour in your building with your people.

Digital Heroes is wrong for you if you want a supplier to own the orchestration logic, or a single-vendor building looking for a cheaper alternative to the vendor's own product. We build systems you own. Our India LLP, US LLC and UK LTD entities mean the intellectual property assigns under your own law. More than fifty specialists, in-house products including ShopScore and HeroCheckout, a named team you meet before signing, and a record checkable on Clutch, Trustpilot, Fiverr Vetted Pro and D-U-N-S.

Book a 30-minute call with Digital Heroes and get a written plan and a fixed quote within 48 hours.

Research & sources

The evidence behind this guide

Independent findings on why this investment pays off. Every link goes to the primary source.

  1. Digital Champions expect to achieve about 16% in cost savings and around 15% in revenue gains from digital operations over five years; the study surveyed 1,155 manufacturing executives across 26 countries. Source: PwC / Strategy& (2018) →
  2. Global retail loses an estimated $1.73 trillion annually to inventory distortion (out-of-stocks and overstocks), equal to about 6.5% of global retail sales, despite $172 billion spent on improvements in the past year. Source: IHL Group (2025) →
  3. Only 22% of firms are 'future ready' having significantly transformed digitally; these companies show average revenue growth 17.3 percentage points and net margins 14.0 percentage points above their industry average. Source: MIT Center for Information Systems Research (MIT Sloan) (2022) →
  4. Bersin by Deloitte research found organizations that use HR technology and employee-centric design to build a flexible, empowering workplace are more than 5 times more effective at improving employee engagement and retention than their peers, and 2.5 times more likely to reach 'high-impact' status by leveraging HR for digital transformation. Source: Bersin by Deloitte (2017) →
FAQ

Frequently asked questions

How much does a custom warehouse execution system cost?

A focused first release covering the resource model, the continuous release engine, orchestration across one automation island plus the manual modules and a building-level operations view runs $120,000 to $250,000 over 14 to 20 weeks. A full execution layer with every subsystem, labour balancing, designed degraded modes and shift replay runs $350,000 to $800,000 across 9 to 18 months.

What is the difference between a WES and a WMS?

A warehouse management system owns orders, inventory and shipping, and releases work in waves. A warehouse execution system decides, second by second, which work goes to which resource based on live buffer occupancy and health across every subsystem. One is a system of record, the other is a control loop with feedback. Buying a second system of record will not fix a starved sorter.

Should we build if all our automation came from one supplier?

No. Buy that supplier's execution software. The machine-level control is deeper than anything commissioned separately, the diagnostics are richer, and when a lift faults at eleven at night you have one support relationship rather than two vendors pointing at each other. The case for a neutral layer only appears once the building genuinely mixes equipment from different suppliers.

What does the schedule actually depend on?

Test windows against live automation, not engineering. Integration testing has to be scheduled around production, and in a building running two shifts that means nights and weekends allocated weeks ahead. Firms that discover this halfway through slip by months. Ask for the test window plan in the proposal, and treat any proposal without one as incomplete regardless of how good the technical section reads.

Who owns the code and the orchestration logic?

You do, from the first commit, covering the repository, the infrastructure accounts and the right to hire another firm. This matters more here than almost anywhere, because the entire reason to build a neutral execution layer is to avoid being locked to an equipment vendor. Escaping that lock by accepting a software one would be absurd, and Digital Heroes assigns under your own jurisdiction.

Can a build handle older controllers with no modern interface?

Yes, and it is normal work rather than an exception. Older equipment speaks telegram-based socket interfaces or industrial protocols documented in a printed manual from the integrator, and the integration is written against that document plus observation on the floor. Ask any developer which protocols they have actually written against and expect specifics, because consuming web services is a different job entirely.

What happens when a message from a machine arrives late rather than lost?

This is the question that separates real floor experience from enterprise development. A divert decision cannot be retried after the carton has passed the divert point, so the layer needs explicit handling for late messages, replays and duplicate events rather than a retry policy. A developer who reaches for retries has not stood on a mezzanine watching a carton recirculate because a label came a second late.

Is it worth building for a second automated site?

Often that is exactly when it becomes worth it, because the orchestration logic becomes yours rather than a vendor's and travels between buildings. The caution is that a second site is never a copy: layouts differ, equipment ages differ and order profiles differ, so budget real configuration work per building rather than assuming a deployment. Prove throughput at one site first.

How do we prove the system actually improved throughput?

Measure before you build, in the same building with the same people, and write the acceptance criteria in units per hour rather than in features. Baseline idle station time, buffer starvation minutes and units per hour across four peak days, then repeat the identical measurement after go-live. Anything else turns into an argument about order profiles, and the argument always favours whoever is being paid.

What is degraded mode and why does it cost extra?

It means each resource has a declared reduced capability the release engine respects automatically, work already committed to a failed resource is re-routed with an audit of what moved, and there is a documented manual procedure for each subsystem. It is unglamorous, it has to be specified and paid for deliberately, and it converts a bad afternoon into a slow one.

How much should a small business budget for its first custom app or website?

For a focused first build, most small businesses land between $8,000 and $60,000: roughly $8,000 to $45,000 for a custom website and $25,000 to $60,000 for an internal tool or simple web app, based on Digital Heroes delivery across 2,000+ projects. Customer-facing products with payments, logins, or a mobile app start around $40,000. Quotes far below these bands usually mean a template with your logo on it, not software shaped around your workflow.

How long does it take to build and roll out a custom WMS?

A working first version takes 12 to 16 weeks in Digital Heroes projects, and full rollout with data migration, scanner setup, and floor training lands at 5 to 7 months. Enterprise packages run much longer; clients who come to Digital Heroes after evaluating Manhattan report partner-led implementations of a year or more. The slowest part is rarely the code; it is documenting how receiving and picking actually work today, so start mapping those flows before you sign anything.

How many people does it take to build a custom WMS?

Five is the typical Digital Heroes WMS team: a project lead, two backend developers, one developer on the scanner app and dashboard, and a QA engineer, with DevOps involved part-time. EDI-heavy or multi-warehouse scopes add a dedicated integrations developer. On your side, assign one operations person who can answer process questions within a day, because their availability moves the timeline more than adding developers does.

Will an app built for 10 users survive growing to 500?

Yes, if it is built on standard cloud infrastructure with a sound data model, because moving from 10 to 500 users is a hosting configuration change, not a rebuild. The scaling decisions that actually hurt are made early and invisibly: how the database is structured, how accounts and permissions are modeled, and whether background work is queued properly. Ask your agency how the system would handle ten times the load; the right answer is boring and specific, and a promise to cross that bridge later means you will pay for the bridge twice.

What should I prepare before contacting a software development agency?

A one-page brief beats a 40-page requirements document: the business problem in plain words, who will use the system, the 5 to 10 workflows it must handle, the tools it must connect to, and your budget range and deadline driver. You do not need wireframes, a specification, or technical vocabulary; producing those is the agency's job during discovery. Stating a budget range up front is the single best move, because it gets you honest scoping instead of a quote engineered to win the meeting.

How do I calculate whether custom software will pay for itself?

Divide the build cost by the monthly benefit, where benefit is hours saved times loaded hourly cost, plus subscription fees replaced, plus any revenue the software unlocks. Three staff saving 10 hours a week each at a $40 loaded rate is about $62,000 a year, which pays back a $60,000 build in roughly 12 months. Across Digital Heroes internal-tool projects, 12 to 24 months is the normal payback range, and anything projecting under 6 months usually means the spreadsheet is hiding costs.

What questions should I ask a development agency on the first call?

Ask who exactly will build it, what happens when scope changes mid-project, what their maintenance terms are after launch, and what they will need from you every week. Then ask them to describe a project that went wrong and what they changed afterward; teams that have shipped at real volume have war stories, and teams claiming a perfect record are hiding something. The scope-change answer matters most: a disciplined shop describes a written change-order process, not a vague promise to be flexible.

How do I vet a software development agency before signing a contract?

Ask to speak with two past clients whose projects resemble yours in size and industry, and ask exactly who will write your code, since some agencies sell senior faces and deliver junior or subcontracted hands. Demand a written specification with acceptance criteria before any fixed price, and check that their portfolio links to products that are actually live. An instant quote given without questions about your workflows is the clearest warning sign there is.

How many SaaS seats do we need before building custom becomes cheaper?

The crossover usually shows up between 20 and 50 seats on premium tiers. Salesforce Enterprise lists at $165 per user per month, so 40 users cost about $79,000 a year in subscriptions, which is real money against a custom system you would own outright. Run the comparison over three years: if subscription spend beats the build cost plus 15-20% annual maintenance, custom wins on price before you even count workflow fit.

Can custom software connect to the tools we already use, like QuickBooks, Stripe, and Google Workspace?

Yes, and connecting your existing tools is one of the main reasons to build custom: mainstream platforms like QuickBooks, Stripe, Shopify, and Google Workspace all publish documented APIs. Budget 1 to 3 weeks of work per integration depending on API quality and how much data flows in both directions. Ask any vendor whether they have integrated with your specific tools before, because quirks like QuickBooks' OAuth token handling and API rate limits get learned on someone's project, and it should not be yours.

Who can build a custom warehouse management software system?

Digital Heroes builds custom warehouse management software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.

Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.

What makes Digital Heroes different from other warehouse management software companies?

Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.

Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.

How can I check Digital Heroes is legitimate before getting in touch?

Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.

Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.

Keep reading

Published · Last updated .

Online now

Hi there. How can we help you today?

Reply