Build, Buy, and the Integration Tax

Build-versus-buy debates are often reduced to software license cost versus engineering cost. Both numbers can be accurate and still produce the wrong decision.

The missing factor is the integration tax.

Every platform must receive data, validate it, map it, handle errors, fit security and governance, support reporting, survive upgrades, and eventually be replaced. These costs continue long after implementation.

What the integration tax includes

A complete evaluation should include:

• Data mapping and transformation
• API, event, file, or EDI integration
• Identity and access
• Monitoring and support
• Exception handling
• Data quality and reconciliation
• Testing and release management
• Vendor changes and upgrades
• Audit and evidence
• Training and operating ownership
• Migration and exit cost

A low-cost product with weak interfaces may create a larger total cost than a more expensive product with mature integration and support.

Buy commodity capability

Buying is strongest when the workflow is standardized, regulated, infrastructure-heavy, or already solved well by the market. Tax calculation, payment processing, parcel labels, email delivery, and core accounting are common examples.

Customizing these areas beyond business need creates maintenance without differentiation.

Build differentiated decisions

Building is strongest where the company has unique operating logic, data, customer experience, or orchestration that creates durable advantage.

A business may buy warehouse execution but own the routing policy across warehouses. It may buy a PIM but own the product-governance model. It may buy observability tools but own the business event model and exception economics.

Keep commodity systems replaceable

The architecture should isolate provider-specific details behind normalized contracts. This does not mean creating an abstract layer for every feature. It means protecting the business objects and decision logic that must survive a vendor change.

Include the cost of operating the decision

A custom system requires product ownership, support, security, documentation, testing, and roadmap discipline. If no team will own it after launch, the organization has not chosen to build. It has chosen to create technical debt.

Make the decision reversible

A good decision records assumptions, expected value, constraints, and exit conditions. If volume, pricing, regulation, or vendor performance changes, the company should know when to revisit the choice.

The right question is not simply whether software should be built or bought. It is which capabilities should remain proprietary, which should remain replaceable, and what the organization is willing to operate for years.