Build, configure, or buy: deciding how to close an operating gap

Start with the operating description, not the category

The first artifact is not a shortlist. It is a written description of the work: what triggers it, who owns the next action, which decisions require a person, where the record lives, what an exception looks like, and what evidence has to exist afterward. Teams that skip this step end up comparing products against each other instead of against the requirement, and the product with the best demo wins.

Write the current path first, including the parts that embarrass you—the spreadsheet someone maintains by hand, the approval that happens by text message, the report rebuilt every Monday. Those are the constraints the future state has to absorb.

Configure first when the model already fits

Configuration is the right answer when an existing system already models your records, permissions, and workflow states correctly, and the gap is in how it has been set up rather than what it can represent. This is more common than teams expect, particularly where a platform was deployed quickly and never revisited.

The tell is that you can describe your requirement using the system's own vocabulary without straining. If you find yourself saying "we use the opportunity object to track something that is not an opportunity," you are already outside configuration.

Integrate when the systems are right but disconnected

Integration is the answer when each system is individually correct and the failure is at the boundaries: the same record maintained in two places, status that differs depending on where you look, or a report that exists only because someone reconciles exports by hand.

Before committing, confirm the boring things: available APIs, credentials, rate limits, data rights, vendor terms, and which system is authoritative for each field. An integration without a named source of truth does not remove reconciliation work—it hides it.

Build when the requirement cannot be modeled cleanly

Custom software earns its place under three conditions. First, the operating requirement cannot be represented in existing tools without brittle workarounds, duplicated data, or permissions that do not match who is actually allowed to act. Second, the workflow is central enough that the workaround cost is recurring rather than one-off. Third, someone will own the result after handoff.

Missing the third condition is the most common reason a custom build fails. Software that no one is accountable for degrades regardless of how well it was written.

The costs each option hides

Configuration hides the cost of the compromise you accept in the data model, which surfaces later as reporting that cannot answer the question you actually have. Integration hides the cost of maintenance at the boundary, which surfaces when a vendor changes an API. Building hides the cost of ownership—support, change requests, and the fact that requirements move.

None of these is a reason to avoid an option. They are the questions to price before choosing, and the reason a bounded first phase is worth more than a complete plan.