When is custom software worth considering?

Describe the problem before choosing a solution

Map one real workflow from beginning to end: who starts it, the information they use, the decisions they make and what happens when something goes wrong. Identify repeated copying, delays, unclear ownership or missing information. Record how often the problem occurs and what it costs in time or errors where reliable evidence exists.

An illustrative example is a team copying approved job details from a spreadsheet into a scheduling system. That could indicate a need for a supported integration, clearer responsibilities or a custom workflow. The repetition alone does not prove that a new application is justified.

Compare four options

First consider a process change: removing an unnecessary approval or establishing one agreed source of information may solve the problem. Next check whether configuring an existing tool would meet the essential requirements. Assess how people would actually use it, including exceptions.

A focused integration may connect systems without replacing them. Custom software becomes a stronger candidate when important rules, permissions or journeys remain unsupported and the benefits justify building and operating a system. Compare all four options against the same requirements, rather than giving the custom option a more favourable test.

• Process change: can the unnecessary work be removed?
• Existing tool: can essential requirements be met through supported configuration?
• Integration: can a limited connection resolve the gap?
• Custom system: which essential needs remain unmet, and why?

Separate essential requirements from preferences

Describe requirements as outcomes. “Only authorised supervisors can approve this change, and the approval is recorded” is more useful than “we need a dashboard”. Mark what is essential for the workflow and what is simply preferred.

Include exceptions: duplicate records, interrupted connections, rejected approvals, incorrect inputs and staff leaving the organisation. A short demonstration may look convincing while these everyday situations remain unresolved. Test shortlisted options with representative, authorised sample data.

Check data and integrations early

List each data source, its owner, quality and access restrictions. Identify which system should be authoritative for each record. Poor or conflicting data will not become reliable merely because it appears in a new interface.

Check supported interfaces, permissions, rate limits, export options and vendor dependencies. A connection can fail or change. Agree what users should see, what can be retried and what requires a person to resolve it. Do not promise an integration before these constraints have been examined.

Compare the full operating effort

Look beyond the initial build or subscription. Compare configuration, migration, training, hosting, ongoing support, updates, backups, integrations and the effort required to change or leave a system. Ask what happens if the supplier or internal system owner is unavailable.

Use ranges and explicit assumptions when estimating value. Compare them with a measured baseline where possible. If the justification depends on a large time saving, identify which tasks would actually disappear and who would verify the result. Avoid treating every minute of theoretical automation as a realised saving.

Define a small, testable first scope

Choose a bounded workflow with a clear owner and acceptance checks. Establish the existing process as a baseline and decide how a pilot will be assessed. A limited first release can reveal whether people can complete the intended task before expanding the system.

Specify permissions, audit needs, error handling, release responsibilities and rollback or fallback arrangements. Human review may remain necessary for consequential decisions. Agree how the system will be maintained and how future changes will be requested.

Questions to bring to a supplier

A productive first conversation makes the uncertainty visible. Bring the following notes; do not send confidential records or credentials in a public enquiry.

• The workflow and the people who use it
• The main problem, frequency and available baseline evidence
• Essential outcomes and important exceptions
• Existing tools and options already considered
• Data owners, integration constraints and permissions
• Who will own operation, support and future changes
• Budget constraints, dependencies and timeline
• A proposed first scope and how success will be checked