The wrong first question is often, “What should we build?” A better first question is, “What is genuinely distinct about the requirement?”
Configure when the work is standard
If a supported platform already models the records, roles, statuses, and controls you need, configuration usually deserves the first look. The burden is to confirm that the process can fit the product without hiding important exceptions or inventing brittle workarounds.
Integrate when ownership is split across systems
An integration can be the right answer when each system already owns a valid part of the operating record. Start with authoritative sources, identifiers, error handling, timing, retention, reconciliation, and recovery—not the connector itself.
Buy when the operating need is common and support matters
Procurement can reduce implementation work, but it introduces vendor fit, portability, data handling, accessibility, security, exit, and operating dependencies. A feature checklist is not enough; test representative journeys and exceptions.
Build when the requirement is truly distinct
Custom software is justified when the users, decisions, evidence, constraints, or operating model cannot be responsibly met through supported configuration or procurement. Define the smallest bounded behavior that proves the case.
Make the decision inspectable
Record the requirement, options, dependencies, exclusions, total operating burden, acceptance evidence, and exit path. The goal is not to choose the most impressive intervention. It is to choose the smallest one that can be governed and operated.