Customize, integrate or build custom software?

Choose the change that fits the problem

If the missing step belongs inside an existing application, investigate customization. If the same information needs to reach another system, investigate integration. If the workflow needs its own interface, permissions and records, investigate a custom tool. Check native configuration before commissioning any of them.

These options can be combined. A custom approval module might also need an integration. Name each part in the scope so the same work is not estimated twice.

Record the bottleneck before proposing a solution

Choose one repeated task and observe several ordinary runs, including an awkward case. Record the event that starts it, who handles it, the systems touched, the time spent and the exceptions. Count waiting time separately from active work: a two-day approval delay is different from two days of staff effort.

Use the workflow cost calculator to record frequency, handling time and staff cost. Its figures describe the current workload. They do not assume an automation will remove it all.

For example, a team might copy a new account from its CRM into an operations system, then ask a manager to approve a limit. First establish whether copying, missing information or waiting for approval causes the delay. Adding a new portal before answering that question could leave the same bottleneck in place.

Customize when the missing feature belongs in the application

A supported extension can keep the task beside the record people already use. Examples include an approval action, a validated input, a document generator or a role-specific view. The important question is what the platform supports in the installed version and subscription.

• Confirm the API, plugin or module mechanism and the right to use it.
• Identify the fields and actions the extension can actually access.
• Check permissions with an ordinary staff account as well as an administrator.
• Provide a test environment, installation steps and a rollback route.
• Document which platform versions are supported and who checks upgrades.

Direct edits to a vendor’s internal database or an unsupported screen can create a fragile dependency. Review a supported module, integration or separate tool before choosing that route. See software customization and extensions for the build scope.

Integrate when information needs to move between systems

An integration needs a data contract, even when a connector makes setup look simple. Decide which system owns each field, what identifies a record, when a change should move and which conflicts need a person.

The actual rules depend on the applications and business. Confirm rate limits, required plans and API terms against current documentation. See API integration and workflow automation.

Build a focused application when the work needs its own place

A custom tool becomes a reasonable option when existing software cannot represent the workflow well, or when several teams need a shared view with controlled actions. Examples include an exception queue, an internal approval workspace or a customer portal.

Define the first release through real tasks rather than a long list of features. “An operator can find an unassigned request, assign an owner and see its next action” is testable. “A complete operations platform” leaves too many decisions hidden.

List the screens, roles, data sources and actions. Include how someone corrects a mistake, what happens when a source is unavailable and which records need a history. Budget for deployment, access recovery, backups and updates alongside the build. Our custom software service and starting software scope show how a first release can be bounded.

Write a brief someone can estimate

A useful brief can fit on one page. Include the current process, the part that fails and a small set of representative examples with sensitive information removed.

1. The task: what starts the work, who handles it and what completes it.
2. The systems: product names, versions, subscription plans and available access.
3. The records: fields, identifiers, expected volume and source of truth.
4. The users: who can read, change, approve or export information.
5. The exceptions: missing data, duplicates, a rejected approval and an unavailable connection.
6. The acceptance check: the tasks the team must be able to complete before sign-off.
7. The handover: account ownership, source, documentation and maintenance responsibility.

If the requirements are still uncertain, a separately scoped discovery engagement can produce a prototype and build estimate. Check the discovery scope and fee before commissioning it.

Test the whole task before expanding

Try an ordinary record, a repeated event, a missing field, an unauthorized user and a disconnected source. Ask an intended user to finish the task without the developer guiding every action. Record what they had to correct or do outside the system.

Compare the same measures used before the change: active handling time, corrections, unassigned work and missed handovers. Include review and maintenance effort. A faster happy path can still create more work when exceptions occur.

Use the workflow planner to map a request, assign its owner and test a failed connection. Download the brief and add your own acceptance checks before commissioning the build.