The right starting point depends on the work, the constraints, and the responsibility you are prepared to take on.
Write the requirements in plain language
Describe the outcome, users, information, and systems involved. Separate essential requirements from preferences. Include the less visible work: managing access, handling changes, supporting users, and recovering from an outage. This gives you a common basis for comparing an existing product, a custom application, or a connection between systems.
Test the fit
Use representative tasks to assess the options. A demonstration can help you understand an interface, but it should not replace testing against your own requirements. Check how each option handles exceptions, permissions, and handover. Where a product already meets the need, ask whether custom work would add enough value to justify maintaining it.
Count the ongoing work
Consider integration, evaluation, training, support, and future changes alongside the initial purchase or build. Decide who will perform that work. A component that is easy to start using may still need careful operational ownership. Conversely, a custom solution may be reasonable when the workflow is distinctive and the organisation can support it.
Keep a route to change
Understand how your information can be exported and how dependent workflows would operate if a supplier or component changed. Record the trade-offs behind the decision. You do not need to remove every dependency; you need to know which ones matter and how you would respond if they stopped meeting the need.
