Two proposals land on the same desk. One is $180,000 and promises a working system in five months. The other is $310,000, takes seven months, and spends the first five weeks asking questions about your warehouse before quoting anything.
The instinct is to pick the first one. The second proposal is usually the cheaper project.
That inversion is the most consistent finding in the guidance agencies publish about their own selection process. A firm that gives a firm price from a brief alone is pricing to win, not to deliver — because nobody can scope integration they have not investigated.
Where these projects actually break
Look at the failure mode rather than the failure rate. Agency guidance reviewed for this analysis describes the same pattern repeatedly: the proposal is thorough, references check out, the price is competitive, and then three months in the senior architect from the pitch is nowhere to be found and the timeline has quietly doubled.
One firm puts the mechanism plainly: custom enterprise software fails most often not on engineering execution but on under-scoped system integration, a gap that surfaces in week one of discovery and compounds through every sprint afterward. A mid-market firm replacing a CRM, in its example, discovers the real project is the fourteen internal systems feeding it — each with different authentication, rate limits and undocumented field semantics.
A caution about the numbers usually attached to this argument. The same page cites both “66% of technology projects end in partial or total failure” and “only 31% of software projects succeed,” each attributed to the Standish Group CHAOS Report. Those figures are not reconcilable as stated, they circulate through secondary citation chains, and this analysis did not verify them against the primary report. Treat project-failure statistics from vendor pages as rhetorical context, not evidence. The qualitative pattern is what holds up.
Discovery is the deliverable, not the delay
Every credible evaluation framework reviewed for this article puts structured discovery first, and describes the same contents: stakeholder interviews, technical assessment, integration surface mapping, and assumption testing — before anyone commits to a build plan.
Ask a prospective partner for a sample discovery output. Not a case study, not a slide deck about their methodology. The artifact: a scope map, a risk register, a proposed architecture, and a list of the decisions that cannot be undone cheaply later. One agency frames it bluntly — a firm that cannot show you one is estimating blind.
For an ERP or warehouse project, discovery has a specific job. It should answer which system owns each field, because that question is where these programs quietly die. If the warehouse management system holds the authoritative on-hand quantity and the ERP displays it with a five-minute lag, an integration that reads ERP inventory will produce confident, wrong decisions at the pick face. That is a design decision. It belongs in week three, not month five.
Illustrative arithmetic: if a custom application makes forty inventory reads a day across three shifts and each staleness error costs an hour of warehouse labor to reconcile, the annual exposure is roughly 120 hours — on one field. Nobody writes that line into a statement of work, which is exactly why it should be written into discovery.
Five things to demand before signing
1. Names, not role descriptions. Who specifically will work on this, at what seniority, and can you meet them before the contract? The bait-and-switch problem — senior people in the pitch, junior people in the build — is described across every evaluation guide reviewed here as the single most common complaint in agency work, and it cuts across price tiers. “We will assign the right team based on project needs” is not an answer.
2. Relevant complexity, tested by hard questions. Ask what the most difficult technical decision was on a comparable project, what broke, and what they would do differently. A team that can discuss trade-offs and failures in detail has been through it. A team that stays at screenshots has not.
3. Compliance inside the pipeline. Security scanning, least-privilege service accounts, secrets management and audit logging should appear during development, not in a pre-launch review. One agency's framework puts it directly: a partner treating compliance as a launch checkpoint has a fundamentally different risk profile from one scanning continuously.
4. Unambiguous ownership. Code, architecture documentation, data models and infrastructure definitions, transferred on final payment, with no proprietary runtime dependency that converts a completed project into a permanent license. Some firms retain rights over reusable frameworks. Ask before, not after.
5. A handover plan with dates. Runbooks, an architecture decision log, monitoring dashboards with defined thresholds, and a support window after launch. Launch as the finish line produces software your own team cannot safely change.
Why warehouse fluency beats framework familiarity
Most selection processes over-weight the stack list. One agency argues the opposite, and it is right: eliminating a partner because a specific framework is absent can screen out the firm best suited to the problem.
The reason is specific to operations software. An engineer who has never worked near a distribution center will not think to ask what happens when a picker substitutes an item, whether the inventory adjustment that follows is also a financial event, or who is allowed to approve a partial shipment. Those are not coding questions. They are the requirements, and they are invisible to anyone who has only built web applications.
The practical test is a scenario. Describe a real exception — a short pick, a substitution, a carrier cutoff, a returned pallet — and ask the partner to walk it through the systems it touches and the records it should leave behind. A firm with domain depth will start asking about approval authority. A firm without it will start sketching screens.
Adding AI without replacing the investment
The current temptation is to treat AI as a reason to re-platform. It is usually not. The useful applications sit beside the ERP and WMS, reading their data and writing back through interfaces the vendor already exposes.
Three patterns are worth pursuing, and they share a property: each is bounded and each can be declined.
- Exception triage. Cluster and route warehouse exceptions by type, age and owner, so a supervisor works a queue rather than a phone tree. The system recommends; a person decides.
- Document extraction. Pull structured fields from supplier acknowledgements, bills of lading and packing lists, and flag low-confidence extractions for human review instead of silently accepting them.
- Forecast explanation. Not a better forecasting model — most ERPs already forecast — but a plain-language account of why the number moved, drawn from the inputs the system used.
Three architectural rules make these safe inside an existing investment. Output should be constrained to a schema the application validates, so a different model cannot silently change downstream behavior. Consequential writes should be staged for approval rather than applied, with the source evidence visible on the approval screen. And the system should be permitted to abstain, because an agent that must always answer will answer when it should not.
What to measure in the first ninety days
The measurement problem in custom software is that honest numbers are hard and impressive numbers are free. These distinguish the two.
| Signal | What it tells you | Weak proxy to retire |
|---|---|---|
| Sprint demo since week four | Whether the build cadence is real or verbal | Status reports |
| Integration tests passing on real data | Whether the boundary works, not whether the API responds | Postman screenshots |
| Defects found in discovery versus QA | Where the risk actually sat | Test case count |
| Onboarding time for a new developer | Documentation quality, measured | Documentation page count |
| Time to answer “why did the system do that” | Whether the audit trail is usable | Log volume |
One honest cost input for budgeting, from agency guidance rather than independent study: annual operating costs — hosting, monitoring, on-call, patching, compliance maintenance — typically run 15 to 25 percent of initial development spend. A partner who will not model that three-year figure in discovery is selling a build, not a system.
What separates the two proposals after all
The $310,000 proposal was not charging more for the same work. It was charging for weeks the other firm had skipped, and for the probability that the other firm would find them later, at a worse time, with your budget already committed.
The distinguishing question is not price or portfolio. It is whether the partner can describe your operation back to you in your own terms before writing code — which pick path is fragile, which report the plant manager actually trusts, which field the warehouse owns and the ERP merely displays.
Ask for the discovery artifact. Ask who signs the handover. Ask what happens when the senior engineer leaves. Those three answers do not guarantee a good outcome. They do guarantee you are evaluating judgment instead of a slide deck.
Hashtags
#CustomSoftware #SystemsIntegration #EnterpriseAI #BusinessAutomation #ERPIntegration #WMS #SupplyChain #DataArchitecture #AIGovernance #DataGovernance #ITLeadership #VendorManagement #RiskManagement #OperationalExcellence #DigitalTransformation #BusinessStrategy #Manufacturing #Distribution