Software proposals often use configuration and customisation loosely. The distinction matters because changing settings, extending a product and creating a separate application can produce different ongoing responsibilities. Before selecting an approach, ask the supplier to explain what will be changed, where the change lives and how your business will maintain the resulting workflow.
Start with the required behaviour
A hypothetical Mount Gambier trade supplier needs staff to collect different details for different request types. That might be achievable with existing product settings, an extension or a custom application. Describe the behaviour with examples before choosing the method. Ask the supplier to demonstrate the simplest plausible approach. Product capability should be verified for the actual version and arrangement under consideration, rather than inferred from a broad feature name or a demonstration built for a different use case.
Locate the boundary of the change
For settings-based configuration, identify who can change the rules and how they are documented. For an extension, ask which product behaviour it depends on and what happens when that behaviour changes. For a custom build, ask which capabilities must be created and maintained independently. These questions do not require the owner to become a developer. They establish where responsibility sits and what information a future delivery partner would need to understand the arrangement.
Compare fit with future flexibility
A configured product may encourage a more standard process. An extension may preserve an existing tool while adding a distinctive workflow. A custom application may offer more control over the experience while requiring more explicit product decisions. The tradeoff is not simply convenience versus freedom; it is whether the chosen arrangement fits your work and your capacity to manage it. Avoid customising a product merely to preserve a habit that staff are comfortable changing.
Test the awkward scenario
A simple example may work under every approach, while an amendment or unusual job exposes the real limitation. Use the same scenario to compare alternatives and record any manual steps. Your next scoping step is an options note showing the required behaviour, the proposed change boundary, the demonstrated limits and the ongoing owner. Choose the smallest approach that supports a coherent workflow, with a clear account of what would need to change if the business later expands.
Planning checklist
- Describe behaviour before choosing the method.
- Ask where each change lives.
- Compare awkward cases and ongoing responsibility.