When does integration become more expensive than developing from scratch?
Integration costs are incurred both once and on an ongoing basis: mapping, custom logic, and operation add up. A full cost comparison reveals the right balance.
For management and product owners, when weighing integration versus new development, the key factors are "translation effort per change" and "burden of errors and clarification." The "integration illusion" serves as a counter-test.
Published: 3 min read · Author: Sebastian Geier
At what point does integration become less economically viable than new development?
Integration becomes less cost-effective if mapping, synchronization, and exception handling consistently consume more resources than a standalone target component. The comparison must encompass operation, further development, disruptions, and eventual replacement over the same timeframe. A completely new solution is only superior if its scope is deliberately limited.
Limitable scope of a new solution
Control signal
Signal 1
Average processing time for a business change across all affected systems and interfaces.
Control signal
Signal 2
Number of manual corrections due to conflicting data or unaddressed integration states.
Translation effort per change
Translation effort per change – This tracks how many models, rules, and tests need to be synchronously adjusted for a business change.
Burden of Errors and Clarification – Recurring deviations, manual corrections, and unclear system leadership contribute to operating costs.
Limitable scope of a new solution – The new component assumes a clearly defined capability and avoids the complete replication of both legacy systems.
Practical Scenario: “Integration Illusion”
Two systems maintain the same customer status with different rules and synchronize at night. Each new status type requires changes on both sides as well as in the data transmission. A small, central status component can be more cost-effective if it truly replaces the duplicate logic instead of simply creating a third copy.
Integration Illusion
Integration Illusion – The connection appears complete, while underlying technical conflicts are permanently masked by manual rework.
New System Without Shutdown – The new system is added, but old rules and interfaces remain, increasing the overall load.
One-Time Cost Comparison – Decisions ignore the change and disruption costs that arise after the initial successful data exchange.
Burden of Errors and Clarification
Capture all ongoing mapping, coordination, and troubleshooting tasks of the existing integration.
Model a limited target scope with clear system leadership and deactivatable legacy paths.
Compare both options over the same lifecycle, including migration, parallel operation, and decommissioning.
What questions remain after "weighing integration versus new development"?
When does a customer portal solve a real business problem? Answers the next practical question: What business problem must a customer portal solve to justify the effort?
Calculate maintenance effort as part of the architectural decision Continues this line of thought with another question: How does future maintenance effort become part of an architectural decision?
If you want to put "weighing integration versus new development" into practice, you can refer to Robust Website Systems This focuses on "architectural boundaries and scaling" and "translation effort per change."
Conclusion: Weighing integration versus new development
It's not the interface itself, but the persistent duplication that makes integrations expensive. A new development is only worthwhile if it demonstrably eliminates this duplication.
Sources and Further Information
The primary sources define the technical framework for "weighing integration versus new development."
OpenAPI SpecificationPrimary specification for machine-readable HTTP API contracts, including operations, data models, and error responses.
Choosing Technology: An Introduction – GOV.UK Service ManualOfficial guidance on prototyping integrations, carefully cutting components, and evolving via open standards.
14. Operate a reliable service – GOV.UK Service ManualOfficial standard for the operation, availability, recovery, and continuous improvement of reliable services.
Key Thesis
Integration loses its advantage if ongoing adaptation, error handling, and dependencies cost more than a clearly defined new development. Life cycle costs and risk are decisive.
What This Is Not About
The decision cannot be derived from the initial development days or the number of existing interfaces. Integration is not advantageous simply because both systems have already been paid for.
What it's about
The ongoing costs of a translation layer are compared with a clearly defined replacement for the required capability. Change rate, error handling, and overlapping responsibilities are often more important than the initial build.
Platform strategy & build vs. buy
In-house development or off-the-shelf software: Comparing costs correctly
As a separate step in the "Weighing Integration vs. New Development" process, the question should be: How can the total costs of in-house development and standard software be fairly compared?
Platform strategy & build vs. buy
Making Build vs. Buy Decisions Without Vendor Marketing
Supplementing "Weighing Integration vs. New Development" with a separate decision: How can a build-vs.-buy decision be made independently of vendor marketing?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Translation Effort per Change: Implementation Path
Before replacing an existing system, the current integration burden should be visualized using real operational data. An architecture and cost analysis can show whether decoupling, simplification, or a completely new system is the lesser intervention.