In this guide
All resourcesChoose the option that solves the workflow with a level of cost, complexity, ownership, and maintenance the business can support. Custom software is one option, not the default answer.
Describe the gap before proposing a system
Begin with an example of the work that is difficult today. Explain what starts it, which information is needed, who makes the decisions, and where the process gets stuck.
Separate the outcome from the proposed feature. ‘A new enquiry reaches the right owner with enough information to respond’ is a clearer target than ‘we need a CRM.’ The existing tool may already support the outcome through settings, a better form, or a different process.
Ask the people who will use the result. A technically complete system can still create extra work if it does not fit the team's responsibilities or habits.
Compare the whole responsibility
The table describes questions to investigate, not fixed cost or delivery promises. Actual effort depends on the tools, contracts, data, and workflow.
| Option | A good question to ask | Responsibility to plan |
|---|---|---|
| Improve or configure | Does a supported feature solve the task well? | Settings, training, permissions, and vendor limits |
| Connect existing tools | Can supported interfaces move the right information? | Data mapping, credentials, exceptions, and provider changes |
| Build custom software | Is the remaining need specific and valuable enough? | Design, implementation, verification, deployment, and maintenance |
Configure when the product already fits
Inspect the existing product's supported features, access model, and administrative settings. A clearer form, shared view, notification rule, or agreed checklist may solve the immediate problem.
Check the limits before committing. Understand who can change the configuration, what information can be exported, and which parts depend on a particular subscription or vendor feature.
Include training and adoption in the work. A feature that exists but is not understood can leave the original bottleneck in place.
Connect when the handoff is the problem
An integration can help when the right tools exist but someone repeatedly moves information between them. Establish the system of record and the mapping between each field or status.
Review API access, account permissions, rate limits, and the vendor's support for the workflow. Plan duplicates, retries, missing information, and a way for a person to recover a failed step.
Illustrative handoff: an enquiry form creates a request in the team's supported system, applies an agreed routing rule, and makes exceptions visible. The owner checks the enquiry before responding. This can be an integration project without a new client-facing application.
Build when the remaining need justifies it
Custom software becomes worth exploring when the workflow has valuable requirements an existing supported product cannot serve well. Examples might include a specific approval model, a focused internal interface, or a process spanning several systems.
Define the first release and a way to evaluate it. Plan permissions and validation alongside the interface, then check the complete flow with representative work and failure cases.
Agree code and account ownership, documentation, deployment, data portability, and maintenance before launch. A custom interface still depends on infrastructure and, often, third-party services.
Use a short decision sequence
Bring a real example, the tools in use, the responsible people, and the intended outcome. Then work through the options in order.
- Can a process improvement or supported feature solve the task?
- If not, can a supported integration connect the existing tools?
- What valuable requirement remains that calls for a custom build?
- How will the team test the first step and handle exceptions?
- Who will own the accounts, data, changes, and operation?
The next step can be a configuration change, a small integration, or a focused build. The decision should follow evidence from the workflow rather than a preference for a particular technology.
