When an operational workflow needs custom software—and how to scope it

A request arrives by email, someone copies it into a spreadsheet, and an approval disappears into another inbox. It is tempting to conclude that the organization needs a new application. The more useful question is which part of the workflow actually needs to change.

Custom software becomes a reasonable option when the work requires rules, information relationships or controls that available tools cannot accommodate economically. Establishing that fit takes more than collecting a list of requested screens.

Start with the decision the workflow supports

Follow a real work item from its arrival to its completion. Identify the person responsible at each step, the information they require and the evidence that shows the work is finished. Include rejected, incomplete, duplicate and reopened items.

Record where time is spent waiting, correcting information or moving between systems. A short observation period can establish a baseline without turning discovery into a large research programme.

Separate process ambiguity from software limitations. If departments disagree about who approves an exception, the application cannot resolve that policy decision. Someone must own the rule before it can become an acceptance criterion.

Compare three practical options

Configure an existing product when its underlying model fits the work. Check permissions, reporting, accessibility, export options and licensing constraints using representative scenarios. A product demonstration should include an awkward exception, not just the straightforward path.

Integrate existing systems when the main problem is repeated entry or disconnected status. Keep established systems responsible for the records they already manage well. The deliverable may be a dependable connection and a small review interface.

Build a focused application when the workflow has distinctive states, relationships or authorization rules that would require fragile workarounds elsewhere. Account for maintenance, upgrades, hosting, operational monitoring and future changes alongside the initial build.

These options can coexist. A custom interface might use an existing identity provider and connect to a commercial asset system. Document why each boundary exists. An architecture decision record (opens in a new tab) is a useful format for capturing a consequential choice, its context and its consequences.

An illustrative first release

Consider an organization coordinating equipment maintenance across several locations. Requests arrive with inconsistent asset identifiers. Supervisors approve work by email, and the finance system receives completed job information later. This is a hypothetical example, not a Xinexis client engagement.

A focused release could support request intake, asset lookup, supervisor approval and a controlled handoff to the existing maintenance system. It would not need to replace purchasing, inventory and financial reporting.

The initial scope might define:

• One request type and a named group of users.
• Required asset, location and issue information.
• Explicit request states and permitted transitions.
• A supervisor queue for incomplete or exceptional requests.
• A stable identifier linking the request to the maintenance record.
• A visible handoff status and a procedure for failed transfers.

This gives stakeholders something concrete to evaluate. If a request changes after approval, should the approval become invalid? If the receiving system is unavailable, can the request wait safely? Those answers influence the design more than the choice of frontend framework.

Write acceptance criteria around behaviour

A criterion such as “the integration works” leaves important questions unanswered. Describe observable behaviour instead.

For the example above, resending the same approved request should not create a second maintenance job. An unauthorized user should be unable to approve it. A rejected transfer should remain visible to an assigned operator. The user should receive an accurate status rather than an unsupported success message.

Also define the expected workload, response-time target, supported devices and accessible interaction requirements. Agree on how these will be checked. Targets should reflect the actual operating context, rather than being copied from an unrelated system.

Use representative test records that cover normal work, permissions, incomplete information and recovery. Record which conditions remain outside the first release.

Make the transition and handover part of the scope

A useful delivery brief should identify the data owner, migration approach, release decision and conditions for returning to the previous process. If both workflows operate temporarily, specify how records will be reconciled.

Incremental replacement can reduce the size of a change, but introduces temporary coordination work. Microsoft's Strangler Fig guidance (opens in a new tab) describes this tradeoff, including the need to manage dependencies between old and new functionality.

The handover should include the source repository, deployment instructions, configuration inventory, data model, operational checks and procedures for common failures. Access and ongoing maintenance responsibilities should be agreed explicitly.

A useful starting brief

Bring a workflow map, representative records, known constraints and the decision you need to make. A scoped assessment should leave you with a recommended option, a bounded first release, unresolved questions and an estimate whose assumptions are visible.

Explore Custom Software Engineering, or Discuss a Project to examine the workflow and its delivery requirements.