When should an SME stop after discovery instead of funding software?

Make the decision before requesting a build

Stop the proposed build when the problem is too small to justify its future cost, a simpler change solves it, or a hard constraint prevents a useful result. Investigate when one answer could change that conclusion. Proceed towards a build only when the remaining problem, feasibility and business case are supported by evidence. Money already spent on discovery does not make the next invoice worthwhile.

The GOV.UK Service Manual treats discovery as learning about the problem, users, constraints and alternatives before deciding whether to move to alpha. It explicitly allows stopping when continuing is not worthwhile. This article adapts that decision discipline for a Hong Kong business; it is not a Hong Kong regulatory requirement. In the UK method, moving to alpha means further testing, not automatic approval for a production build.

Trace a real case before naming the solution

Consider a fictional eight-person Hong Kong consultancy whose owner asks for a client portal because engagement files take too long to open. Follow a recent case from first enquiry to an approved brief. Record when the client supplied information, when staff checked it, when someone asked a second time, and when a partner approved it. Separate minutes of active handling from days spent waiting. A portal might reduce rekeying but cannot create a missing approval decision.

Sample ordinary and awkward cases, including a client who prefers Chinese correspondence and one who sends information through several channels. Ask the people doing the work to explain exceptions. In this example, test a single bilingual intake checklist, a named case owner and a daily approval slot before buying anything. Keep the existing approved document store. Track missing-item follow-ups and time to an approved brief during the trial, and note differences in case complexity so a quiet week is not mistaken for an improvement.

Complete one decision sheet

Bring the following sheet to the owner, an administrator and the person who would operate the eventual system. Fill it with case references and named responsibilities, not a feature wishlist. Treat an unverified restriction as a question to resolve, not a fact. For example, check an actual client agreement before declaring a storage location mandatory; distinguish that requirement from a partner simply preferring the current filing habit.

Cost the problem that remains

Use figures supplied by your own owner, with their basis recorded. For illustration only, suppose the fictional owner enters 12 avoidable handling hours per month at HK$250 per hour. That is HK$3,000 of monthly capacity value, not guaranteed cash savings. If the process trial removes eight hours, the maximum remaining capacity value is four hours × HK$250 = HK$1,000 per month, or HK$12,000 over 12 months. These are invented worksheet inputs, not market rates or measured trial results.

Now suppose the same fictional owner uses HK$36,000 as a build budget assumption and HK$6,000 for the first 12 months of support. The HK$42,000 subtotal already exceeds HK$12,000 even if software removes all remaining handling immediately. It also excludes migration, training, internal review and disruption. On a capacity-only case with the owner requiring a 12-month return, stop the build. If fewer mistakes or faster billing are the real benefit, quantify them separately with evidence and avoid counting the same time twice. Do not invent extra revenue to rescue the proposal.

Record a decision with a next action

A stop decision should preserve the useful findings: keep the improved process, assign its owner and state what would warrant reopening the question, such as sustained growth in the remaining workload. An investigate decision must buy an answer. For this consultancy, that might mean checking whether the approved document store can support a required permission pattern using dummy records. If the answer cannot change the funding decision, more discovery is merely delay.

A build decision requires more than enthusiasm for a demo. Confirm that the residual need survives the process trial, alternatives have been tried against the same constraints, and someone can fund and operate the result. Then authorise a bounded next stage with an explicit stopping condition; technical uncertainty may still require a prototype before a production commitment. At the next management meeting, bring three anonymised case timelines and the completed sheet. Name the decision maker and leave with one recorded choice, its evidence, and a dated action.

If the evidence points to a software need, the existing custom software versus SaaS guide can help compare routes. The custom software service page is a useful reference for framing a later delivery discussion once this funding decision has been made. Neither comparison replaces the stop decision above.