When a custom application should wait
A frustrating process can justify investigation without justifying a new system. Before commissioning software, establish whether the problem is a missing capability, an unclear decision, poor source information, or an operating responsibility nobody owns.
A deliberate pause should produce evidence for the next decision, not leave the task indefinitely unresolved.
When the rule keeps changing because it is not agreed
If teams disagree about who approves a request or when a booking becomes confirmed, an application will encode one interpretation and disappoint someone else. Work through examples with the authorized owner before designing the control.
The next step may be a written policy decision and a manual rehearsal. Once the rule is stable enough to test, development can implement it more coherently.
When an existing product already handles the task
Compare the required journey with available configuration or a supported extension. A modest change to the process may be worthwhile if it avoids maintaining a bespoke application.
Evaluate the awkward case as well as the ordinary one. An existing product that covers the main screen but cannot represent an essential approval rule may still leave a meaningful gap.
When the source data cannot support the promise
A new interface cannot reliably identify customers from inconsistent names alone or reconcile stock units that the business has not defined. Clean a representative sample and establish ownership of ambiguous records.
That work can reveal whether the planned application is still needed and which migration responsibilities belong in its scope.
When the exception is too rare to automate sensibly
Estimate how often the case occurs, how much effort it creates, and the consequence of delay. A clear staff procedure may be the appropriate first solution. Automation creates a continuing component to test and maintain.
Manual handling still needs a visible queue, owner, and record. Deferring code does not mean ignoring the operational problem.
When nobody can operate the result
Source, hosting, account administration, backups, content, and support all need owners. If the organization cannot sustain those responsibilities, a smaller scope or managed existing product may be a better fit.
Define what would change the decision
Assign the missing evidence: a provider capability check, cleaned sample, approved rule, observed exception volume, or ownership plan. Set a review point and record what would justify proceeding.
Custom software is most useful when the business understands the task it is acquiring the responsibility to support.