Decision guide3 min read
Should You Integrate Your Software or Replace It?
Choose between connecting existing tools, adding a custom coordination layer, replacing one system, or rebuilding a larger workflow in phases.
Written byNeil BusqueProduct builder · Updated
Field notes, minus the motivational fog.
A disconnected stack does not automatically require a total rebuild. Sometimes the correct fix is one dependable integration. Sometimes the underlying data or workflow is so mismatched that connecting more tools only makes the failure harder to see. The decision starts with the system boundaries. The goal is to connect the work, not build a more elaborate machine for moving the same typo around.
Integrate when each tool is still good at its job
- One system clearly owns each important record.
- The APIs expose the data and events the workflow needs.
- The pain is duplicate entry, delayed handoff, or missing visibility.
- Users can tolerate the existing interfaces for specialist tasks.
- Failures can be logged, retried, and resolved without corrupting state.
Replace when the core model creates the problem
- The source system cannot represent essential records or relationships.
- Important data is inaccessible, unreliable, or trapped in manual exports.
- The product is unsupported or creates unacceptable continuity risk.
- Permissions cannot protect the way customers or teams are organized.
- Integration would preserve a user experience people already avoid.
- The combined subscription, admin, and workaround cost remains material.
A coordination layer can be the middle path
A focused custom application can present one queue, next action, or customer experience while accounting, calendars, payments, email, and other specialist systems remain behind it. The custom layer owns the business-specific state and records whether connected actions succeeded.
Map data ownership before connecting anything
- 01
Source
Which system is allowed to create or authoritatively change the record?
- 02
Trigger
Which verified event starts the integration?
- 03
Mapping
How do records and statuses correspond across systems?
- 04
Idempotency
How will retries avoid creating duplicates or repeating consequential actions?
- 05
Recovery
Who sees a failure, what information do they receive, and how is the action safely retried?
Frequently asked questions
Is integration always cheaper than replacement?
Not when the source product is a poor fit, its API is inadequate, or ongoing workarounds remain. Compare lifecycle cost and operational risk, not only initial effort.
Should the new app become the source of truth?
Only for the records and workflow it is designed to own. Keep specialist systems authoritative for their domains when that remains clear.
Can replacement happen in phases?
Yes. Move one complete workflow or record family at a time, with explicit cutover and reconciliation.