AudioFind: from a lost quote to a tool in two hours

Someone described an apparently small problem to me: they knew that a phrase existed inside an audio or video file, but could not remember when it had been said. Finding it meant listening again, jumping forwards and backwards, and relying on memory.

It was not the kind of need that would traditionally start a software project. The cost of analysing, estimating, developing and deploying it would probably have exceeded the time it could save.

Around two hours later, a first version of AudioFind existed.

Reduce the problem until it can be built

The first version did not need to manage a media library, users, advanced permissions or every imaginable format. It needed to complete one journey:

1. Receive an audio or video file.
2. Obtain a time-linked transcript.
3. Allow someone to search for an idea or phrase.
4. Show matches with the exact time.
5. Jump to the fragment to verify it.

That sequence turns a vague complaint into a concrete test. We can provide a real file, search for something we know it contains and observe whether the result avoids manual work.

Two hours does not mean a finished product

The time matters because it changes the decision to explore, not because it proves that all software can be built in an afternoon. A production tool might need privacy controls, size limits, additional formats, storage, managed costs, accessibility and a more robust experience.

The prototype did something else: it made the solution visible at a low enough cost to ask whether it deserved to continue.

This distinction protects us from both slowness and enthusiasm. We do not need to design the entire business before testing a need. Nor should we confuse initial evidence with a capability ready for every user.

The new space for small software

AudioFind belongs to a category that interests me greatly: specific tools that remove real friction but previously could not cross the economic threshold for a project.

AI participates in two ways. It can be part of the product—for example, interpreting audio and text—and it can take part in its creation by helping us explore, implement and verify quickly. Together, these roles open a space between the manual task and the general-purpose platform.

That space does not always have to become a commercial product. It can be an internal capability, a research instrument or a small piece that removes a recurring annoyance for a small group. Its value lies in the problem it removes, not the size of the market we imagine.

Building is now part of understanding

Previously, we might have debated whether the idea was technically possible or whether anyone would use it. Once we could create a first answer in hours, building became a form of research.

The next step was no longer speculation. It was observation: what kinds of searches the person made, whether the transcript was enough, whether literal or semantic matching was needed and what result they considered reliable.

That is the important change. Not simply faster software, but conversations that reach a shared reality sooner.

Sources and references

• Primary source: Victor’s account of creating AudioFind.
• Related: the article about the Jevons paradox of custom software.