When is bespoke software worth considering?

What problem should we document first?

Record one repeated task, who performs it, the systems involved and what happens when it fails. Count volume and time over a normal working period. Separate observed figures from estimates. A difficult process may need clearer ownership before it needs software.

For example, a charity might receive programme referrals by email and copy accepted referrals into a register. This is an illustrative workflow, not a customer result. The first requirement could be a reviewed referral queue with an accountable owner, rather than a replacement for every system.

Use the Manual Process Audit to collect that baseline before asking for proposals.

When should we keep our existing tools?

Test configuration first where an existing product supports the essential tasks. Investigate an integration when tools fit individually but information must be copied between them. Compare a bespoke build when the remaining gap justifies implementation and ongoing operation.

The custom software service describes the work FSS can scope. It is a service outline, not evidence that your organisation needs a build.

What belongs in the first release?

Write acceptance criteria as tasks users can demonstrate: a coordinator can review a referral, assign its next step and find its history. Define which records each role can see, what happens when a request is rejected and how mistakes are corrected. Agree what can wait.

Include training, data cleanup, account administration, maintenance and an exit plan. The software cost guide explains these scope drivers without offering an unsupported price benchmark.

What should we do next?

Complete the Software Project Readiness Kit with the process owner and budget holder. Ask suppliers to compare the same first release, state assumptions and explain which uncertainty discovery must resolve. A useful proposal makes both the work and ongoing responsibility visible.