A custom software discovery investigates whether a recurring workflow gap deserves an implementation project. Start when the gap is important, measurable and persistent, and a business owner can help test the cause and possible remedies. One irritating feature or an expensive renewal is not enough evidence. The strongest trigger is a persistent mismatch between how the business must operate and what available software can reliably support.

This checklist ends with a discovery brief or a decision not to proceed. It does not select a vendor or calculate the relative ownership cost of custom software and SaaS; those belong to a later procurement comparison. Starting with the operational trigger prevents an early technical preference from dictating the answer.

Look for repeated workarounds around a core workflow

Workarounds are useful signals because staff create them to get work done. Look for the same information being entered in several places, approvals taking place in private messages, or spreadsheets that control decisions despite an official system holding the records.

Distinguish inconvenience from structural mismatch. A hard-to-find report may be a configuration problem. A rental business that must coordinate asset availability, maintenance holds, deposits and late returns may have a genuine workflow requirement that a generic calendar does not represent.

Write each workaround as an observable event: “The coordinator checks two calendars before confirming every booking” is actionable. “Our technology is outdated” is not. Record frequency, effort, failed cases and the consequence for customers or staff.

Test whether the business rule is clear

A custom application will need an explicit answer to questions people currently negotiate informally. Who can override a price? When does a provisional booking expire? What happens if a supplier confirms only half an order? Which team resolves conflicting stock figures?

If leaders disagree on those decisions, software development should not hide the disagreement. Resolve or deliberately model the variation first. A configurable rule can support legitimate differences; contradictory rules applied unpredictably usually need an operating decision.

GOV.UK's discovery guidance recommends understanding the problem before committing to a service. Here, the discovery output should include the workflow and its unresolved decisions, not merely a screen list.

Use five operational triggers

Several triggers together justify investigation, but they do not guarantee a custom build will be best. A specialist product may already solve the same problem with a mature support model. Insist on a demonstration using your difficult scenarios rather than a vendor's smoothest example.

Calculate the cost of the gap

Suppose an illustrative service business handles 240 jobs monthly. Coordinators spend twelve minutes reconciling each job across a CRM and scheduling sheet. That is 48 hours. If an improved connection removes eight minutes per job, the potential release is 32 hours a month.

Now account for the remaining work. If monitoring and exception review require six hours, the net release is 26 hours. At a fictional £28 internal hourly cost, that represents £728 of monthly capacity. It might support more jobs or reduce overtime; it does not automatically reduce salary expenditure.

GOV.UK's benefits guidance supports establishing a baseline and comparing possible improvements. Use your own records and distinguish capacity, cash savings and revenue opportunities. Lost revenue needs stronger evidence than multiplying every slow enquiry by an average sale.

Turn each signal into a discovery question

Write what you need to learn before spending on implementation. For duplicated orders, the question might be whether a supported connection can keep two existing systems consistent. For unclear approvals, test whether an agreed rule and a simpler form resolve the delay. A discovery should be able to recommend a process change or no build.

Give the hardest assumption a practical test: demonstrate an available API with representative records, walk an exception through the proposed rules, or observe staff using a small prototype. Record the result and the uncertainty left. This is evidence for the next decision, not a full supplier comparison.

GOV.UK technology selection guidance includes prototyping and preserving flexibility. Use those principles to make the investigation bounded and reviewable.

Check whether the organisation can own it

A build needs a product owner who can resolve trade-offs, staff who can test representative tasks and an operating budget after release. Someone must own access changes, support priorities, dependency updates, backups and recovery exercises. Those responsibilities exist whether the developers are employees or an external partner.

Request source-code and documentation arrangements, access to hosting accounts where appropriate, an agreed handover and a way to change suppliers. Ownership is partly contractual and partly practical: possessing source code is less useful if nobody can build, deploy or support it.

Make the next investment a bounded discovery

Before commissioning the full system, ask for a mapped workflow, a comparison of feasible options, a prototype of the hardest part, an initial data model and an estimate with assumptions. Include reasons to stop. If an existing product handles the critical scenario at acceptable cost, discovery has still produced value.

HINTX's MiaFour platform documents connected rental, fleet and service operations. Taplite documents a Windows POS client with a local queue and printing. These illustrate distinct workflow and operating-environment needs; they do not prove that custom development is always cheaper or suitable for another jurisdiction.

Our business strategy work helps establish the case, and custom software development turns an agreed scope into staged delivery.

Frequently asked questions

How big should a business be before building software?

Headcount alone is a poor trigger. Workflow importance, transaction volume, differentiation and ongoing ownership matter more.

Should we replace every spreadsheet?

No. A controlled spreadsheet may be appropriate for low-volume analysis. Prioritise cases where simultaneous work, permissions or record integrity creates material problems.

Does AI make a full custom build a small commitment?

AI can assist implementation, but the business still needs requirements, review, testing and operational support. Assess the delivered system rather than how quickly a prototype appeared.

What should we bring to a first discussion?

Bring a workflow example, current tools, transaction volumes, recurring exceptions and who will own decisions. Avoid preparing a large feature wish list before the problem is understood.

Discuss whether a focused build is justified with HINTX. We can connect the operational assessment to a practical implementation scope.