When Price Dominates the Conversation
In many integration discussions, the first comparison is numerical:
- Which proposal is cheapest?
- How many development hours are included?
- What is the upfront implementation cost?
While cost discipline is rational, focusing exclusively on price often signals that a more important conversation is missing.
Integration decisions are fundamentally risk decisions, not just purchasing decisions.
The Real Costs Rarely Appear on the Quote
Development effort is only one component of integration cost.
The more significant expenses often emerge after implementation:
- Operational disruption during rollout
- Rework when systems evolve
- Manual processes introduced to compensate for gaps
- Increased support overhead
- Loss of confidence in system data
These costs are difficult to quantify upfront but can exceed the original project budget over time.
Disruption Is the Most Expensive Outcome
For ERP-centric wholesale and retail businesses, system disruption affects far more than IT.
It can impact:
- Order fulfilment
- Customer service performance
- Stock accuracy
- Financial reporting
- Supplier coordination
Even short periods of instability can have cascading effects across departments.
This is why experienced operators treat stability as a primary objective, not an optional enhancement.
Rework Compounds Over Time
Integrations built with minimal architectural planning often function initially but struggle to accommodate change.
As the business evolves — new channels, pricing structures, product lines — previously hidden limitations surface.
Rework may involve:
- Redesigning data flows
- Rebuilding integrations
- Migrating logic between systems
- Correcting accumulated inconsistencies
Each cycle consumes time, budget, and organisational attention.
Rework at this scale is normal rather than exceptional, and the software industry has measured it. Capers Jones' benchmarking data put the average defect removal efficiency of US software projects at about 85% as of 2011 — meaning roughly one defect in seven was still present when the work was handed over, waiting to be found by the people using it (Capers Jones, Software Defect Removal Efficiency, 2011). What the industry does not have is a trustworthy figure for what those late discoveries cost. The widely quoted "1-10-100" rule — a defect costing $1 to fix at design, $10 in testing and $100 in production — is credited to an "IBM Systems Sciences Institute" that turned out to be an internal staff training programme rather than a research body, and investigators who traced the claim found no underlying data set and nothing more recent than 1981 (The Register).
That absence is the practical point rather than a footnote. Two integration quotes cannot be compared on the downstream cost of getting it wrong, because nobody can price that credibly. What can be compared is how much of the work each supplier is deferring — and that is a question about architecture and accountability, not about the number at the bottom of the proposal.
Operational Strain Is the Silent Cost
Not all consequences appear in financial reports.
Poorly structured integrations often create ongoing administrative burden:
- Teams manually reconciling data
- Exception handling becoming routine
- Workarounds becoming permanent processes
- Increased reliance on specialist knowledge
This strain reduces organisational capacity for strategic work and can lead to burnout in operational teams.
The pattern shows up most clearly around older or heavily customised systems — Legacy Systems in Wholesale Businesses covers how operational strain accumulates specifically in legacy ERP environments.
How Experienced Operators Evaluate Integration Projects
Organisations with prior integration experience typically look beyond line-item pricing.
Key evaluation factors include:
Risk Exposure
- What happens if the integration fails or behaves unpredictably?
- Which parts of the business are affected?
Ownership and Accountability
- Who is responsible for outcomes, not just delivery?
- Is there clear accountability for system behaviour over time?
Future Flexibility
- Can the architecture accommodate new channels or requirements without major redesign?
- Will changes introduce disproportionate cost or risk?
These considerations reflect long-term operational thinking rather than short-term budget optimisation.
Part of judging risk exposure is knowing what your ERP data can and cannot be trusted for in the first place — ERP Systems Aren't Perfect — But They Are Authoritative covers that distinction in more depth.
When Cheaper Projects Can Be Appropriate
Lower-cost integrations are not inherently wrong.
They can be suitable when:
- Operational complexity is low
- Systems are loosely coupled
- Data integrity is not mission-critical
- Failures can be corrected easily
- Business impact of disruption is minimal
In these contexts, rapid implementation may provide sufficient value.
The key is alignment between project approach and business risk profile.
Matching Integration Strategy to Consequence
The appropriate level of investment depends on the cost of getting it wrong.
For experimental initiatives or non-critical systems, lightweight solutions may be entirely reasonable.
For ERP-connected commerce, inventory management, or financial data flows, consequences are typically far higher.
Choosing a low-cost approach in a high-risk context often shifts expense from upfront investment to downstream recovery.
Conclusion
Price is an important factor in integration decisions, but it should not be the only one.
The true cost of integration includes disruption, rework, and long-term operational strain — factors that rarely appear in initial proposals.
Experienced wholesale and retail businesses evaluate risk exposure, ownership, and flexibility before focusing on line items.
Cheaper projects can be appropriate when consequences are small.
When the cost of failure is high, a risk-aware approach provides greater long-term value.
Price-Based Integration Decisions: Common Questions
How much of an integration budget typically goes to rework rather than new development?
There is no trustworthy published figure for integration projects specifically, and the ranges that circulate online tend to trace back to consultancies and tool vendors rather than to measured data. What is measured is defect removal efficiency: Capers Jones' benchmarking put the US average at about 85% as of 2011, so roughly one defect in seven was still present at handover. The practical answer is to measure your own — track how much of your development spend over a year went to changing things that were already built.
Is it true that a defect costs 100 times more to fix in production?
The direction is right but the number is folklore. The 1-10-100 rule is usually credited to an "IBM Systems Sciences Institute", which turned out to be an internal staff training programme rather than a research body; investigators who traced the claim found no underlying data set and nothing more recent than 1981. Late discoveries genuinely do cost more, because they arrive with live data and running operations attached — but nobody can put a credible multiplier on it, which is exactly why price comparison is a poor way to judge an integration proposal.
What should I ask a vendor instead of "what's your price"?
Ask what happens if the integration behaves unpredictably, who is accountable for the outcome rather than just the delivery, and whether the architecture can absorb a new sales channel or pricing structure without a rebuild. These questions surface the costs a price comparison hides, and the answers differ far more between suppliers than the quotes do.
Is it ever reasonable to choose the cheapest integration option?
Yes — when the systems involved are loosely coupled, data integrity is not mission-critical, and the operational impact of a failure would be minor. The risk rises sharply once ERP data, pricing or order flows are involved, because those failures are felt by customers and finance rather than only by IT.
Running SAP Business One? See how SAP Business One ecommerce integration works when the ERP stays in control.