Do you need custom software or an existing tool?
Compare improving a process, configuring a tool, connecting systems and building software. Includes a concrete decision worksheet and a worked example.
Start with the gap between what your tools do and what the work needs. Compare a process change, an existing feature, a connection and a custom build before choosing one.
Describe the missing ability
“We need a dashboard” is a proposed solution. “Our assistant needs to see which appointment requests still need confirmation” describes something you can test. Write who needs to do what, with which information, and what happens if the information is wrong or late.
List what must remain: a calendar, accounting package, client record, file store or approval process. Then separate essential needs from preferences. A familiar colour scheme is different from being able to export your records when you leave a service.
Give every option the same job to demonstrate. “Show how a corrected date reaches the person handling this request” produces more useful evidence than a tour of features. Record what happened, including the parts someone had to fix by hand.
Compare four routes with the same task
| Route | Worth testing when | Evidence to ask for |
|---|---|---|
| Change the process | The problem comes from a duplicated step or an unclear owner. | A person can complete the task using a simpler agreed procedure. |
| Configure an existing tool | The needed feature is already available, or a standard product covers the work. | A realistic example works, including permissions, exports and recurring charges. |
| Connect existing systems | Both tools are useful, but the same information is entered twice. | The supported connection handles updates, duplicates, failure and recovery. |
| Build a focused tool | A well-defined need remains after testing the other routes. | A working prototype, a manageable first scope and an identified maintenance owner. |
Compare the whole commitment: setup, recurring services, migration, staff time, support and the ability to leave. A custom tool gives you another piece of software to look after. A subscription can still require training and maintenance of the process around it.
A view of work waiting for approval
Illustrative example: an independent adviser uses a calendar, a spreadsheet and email. They want one view of pending requests. A colleague suggests a new client portal.
- Describe the decision. The adviser needs to know which requests are waiting for a client reply and which need their own attention.
- Check the existing tool. The spreadsheet can hold an owner, status and next-action date. Try those fields first with fictional requests.
- Test the remaining gap. If people still retype the same information from an approved intake system, inspect whether that system supports a suitable export or connection.
- Limit any build. If a custom view remains useful, start with status and links back to the existing records. Do not copy private documents into it merely to fill a screen.
The answer might be a better spreadsheet, a supported connection or a small application. It is not decided by the appearance of the first mockup. BDC's process-improvement guidance supports examining the work before treating technology as the remedy.
Ask for a demonstration with an exception
Try the same small set of fictional records in each serious option. Include an ordinary request, missing information, a correction and a duplicate. Ask the person who will use the result to complete the task without the builder explaining every click.
For a connection, agree where the authoritative record lives, which direction updates travel and who investigates a failed transfer. A supported API or export is something to verify, not assume from a product logo. Identify what happens when access changes or a supplier stops supporting a feature.
For a custom build, ask for a testable first version, ownership arrangements, an export, recovery instructions and support boundaries. Keep payments, commitments and sensitive decisions with an appropriate human review until the agreed process says otherwise.
Keep a short decision record
Need: who must complete which task?
Options tried: what did each demonstration establish?
Choice: what are we doing first, and why?
Limits: what will still be manual or outside scope?
Owner: who maintains it and checks failures?
Review: what result or change would make us reconsider?
Use the workflow planner to prepare a first outline. Keep unanswered questions visible. They belong in the discussion before a build, not in a footnote after it.