The short answer
Reuse when an existing tool already does the job, integrate when the handoff between tools causes friction, and build when a distinctive requirement cannot be met safely another way. Compare the whole operating cost, including ownership, before treating a custom build as the default answer.
What decision are you actually making?
Start with the task rather than a preferred platform. Write down who performs it, how often, what information they need and what happens when it fails. A request for a new dashboard may actually be a request to reconcile two reports. A request for an app may be a need for customers to check one status. Describe the outcome in language the person doing the work recognises. That makes alternatives comparable before technical preferences take over.
When is reuse the strongest option?
Reuse is sensible when the core workflow is ordinary and the existing product fits it without repeated workarounds. Test the real task in a trial account, including permissions, exports and the awkward exception. Ask whether the team can administer the tool after the supplier leaves. A feature list is weaker evidence than watching someone complete the job. Record subscription costs, limits and the cost of moving data out. Reuse should reduce work, not simply move it into another account.
When does integration make more sense?
Integration fits when useful systems already exist but information is copied between them. Map the source of truth for each field, the event that starts a transfer and the person who handles failures. Check whether the available interfaces support the required operation, not just whether both vendors advertise an API. A connection needs retries, logging and a way to reconcile missed records. Decide what users will see during an outage. Those operational details often determine whether integration actually saves time.
When is a custom build justified?
Build when a specific requirement creates real differentiation or when existing options cannot satisfy essential constraints. Examples might include a specialised approval workflow or a customer journey tied to proprietary operating logic. These are illustrative situations, not reasons to build everything. Separate the distinctive part from ordinary functions such as authentication or email delivery. Estimate ongoing maintenance, security review and support alongside the initial release. A build without an owner and maintenance budget is an unfinished decision.
How do you compare the options fairly?
Use the same scenario for every option: the same users, volumes, exceptions and intended outcome. Compare setup, licences, migration, training, support and exit costs. Identify assumptions that could change the recommendation, then test the most consequential one first. A small prototype can establish whether an interface exposes the right data; a workshop can establish whether people will adopt the proposed workflow. Record why the chosen option fits today and what change would trigger reconsideration. Avoid false precision where information is missing.
What should the first commitment contain?
Agree a bounded scope, acceptance criteria and an operating owner. Include an example of a normal task and a failed task, with the expected response to each. Keep custom features outside the initial scope unless they are needed to test the central assumption. At the review, examine task completion, support effort and total cost rather than celebrating a successful demo alone. The useful output is a decision you can explain and maintain, supported by evidence from the people who will use it.
FAQ
Can we start with a tool and build later?
Yes. Keep data exports, identifiers and ownership clear from the start. A later build is easier when the first system does not trap essential information or undocumented workflows.
Is integration always cheaper than building?
No. Brittle interfaces, complex exceptions and support requirements can make integration expensive. Compare the complete operating cost and reliability requirements before deciding.
Who should own the decision?
The person accountable for the outcome, usually the business owner of the workflow, with technical and operational input. Record the decision, the reasons and what would trigger a review.