Custom software or off-the-shelf?

Start with the smallest adequate solution.

An existing product is worth considering when your requirements are common, the workflow fits its model and someone in your team can manage the configuration. Custom software is worth exploring when important requirements cannot be met without repeated workarounds, or when you need a workflow that is genuinely specific to your organisation.

There is also a middle route: retain a product that works and build a limited integration or internal tool around it. Before commissioning a replacement, identify whether the problem is the whole system or one awkward handover.

Separate requirements from preferences.

Write down what the system must allow someone to accomplish. A requirement such as 'a supervisor can review a request before it is issued' is easier to assess than 'we need a modern portal'. Include the cases where a task is rejected, corrected or reassigned.

Then distinguish essential needs from preferences. A minor layout preference rarely justifies replacing an otherwise suitable product. A missing permission boundary or an important workflow that cannot be represented may be a more substantive issue.

• What must the user be able to do?
• What information must be available, and to whom?
• Which exceptions occur in real work?
• Which changes are likely as the organisation develops?

Compare the ongoing work, not only the purchase.

An off-the-shelf product can reduce the amount of software you maintain directly, but configuration, subscriptions, user access and data administration still need an owner. Understand which features are available on the relevant plan and whether data can be exported in a usable format.

With custom software, discuss hosting, maintenance, documentation, source access and future changes. Buying a development project does not automatically include indefinite support. The agreement should explain what happens after delivery and what is charged separately.

Neither route is automatically cheaper over time. Compare the costs and responsibilities that apply to your actual situation rather than using a universal rule.

• Implementation and migration effort
• Subscriptions, hosting and provider dependencies
• Training and routine administration
• Maintenance and future changes
• Export, handover and exit arrangements

An example: a team tracking service requests.

Consider a fictional team that records incoming requests in a spreadsheet. It needs an owner, a status and a reminder for each request. An existing work-management tool may handle that without any custom development.

Now suppose some requests need different approval paths, access is restricted by client and information must move into another system after approval. That does not automatically mean 'build everything'. First test whether configuration and a focused integration can meet the requirements. Explore custom development where important gaps remain.

This example is a decision aid, not a description of a Cosilan client or a claim about savings.

Make the decision reviewable.

Compare a small number of options against the same requirements. Record where each option fits, which assumptions need testing and who will maintain it. If a short demonstration cannot represent an important workflow, ask for that gap to be investigated before committing.

A useful first enquiry includes the current tools, the people involved and the task that is proving difficult. You do not need to choose the architecture or write a complete specification to start the conversation.