My wife has a reasonable question: do I really need another project?

Work is busy. There is family life, music, motorcycles, and usually some combination of wires, code and 3D-printed parts waiting for a free evening. Now I am adding a website.

I think I do want to make room for this one.

I enjoy building things. A problem gives me something to investigate, and I like working out how a solution could take shape. Seeing someone use what I have made is particularly satisfying. Even when an experiment does not work out, I often enjoy the process and learn something worth keeping.

Why this site exists

I work as a Sales Director in industrial automation. Alongside that work, I build tools to take some of the repetitive preparation off people’s hands. Prospect Investigator, for example, gathers and organises public information about a company to help a sales engineer prepare for contact. My aim is to leave more room for understanding the customer’s situation, developing technical judgment, and learning the work. I enjoy figuring out how business experience, ordinary automation and AI can come together to support that.

AI has opened up more possibilities for that work. It has also given me more ideas than I can reasonably pursue.

This site is a place to examine some of them properly. I want to explain what prompted a project, why I made particular decisions, and what I found when I tried it. Sometimes there will be a useful result. Sometimes there will be a limitation or a question I still cannot answer.

Writing is part of the learning. Explaining a project means looking again at decisions that may have seemed obvious while I was building it. Recording the problem, its constraints and what I learned also gives me something to build on when the technology changes.

I hope these articles will be useful to people dealing with similar problems.

How I got here

At American Express, I worked in transaction authorizations and built automations to help colleagues work with terminal-based legacy banking systems. They made routine tasks substantially faster. Years after I left, a former colleague told me the tools were still in use.

I have kept building alongside my work in industrial automation ever since: scripts, configurators and tools shaped by everyday problems.

What AI made possible

AI has made it more practical to turn a business idea into a working tool, including projects that would previously have been difficult to fit around a regular job.

There are two changes here. AI can help build the software, and it can become part of what the software does. Prospect Investigator brings those together: a tool developed with AI assistance that also uses AI to research and organise information.

The work still involves choosing an architecture and technology stack that fit the problem. Where should the tool run? What information can it process? How will its output be checked, and what will maintaining it involve? Those choices shape whether a promising prototype becomes something useful.

In my experience, the person who understands the work remains central to the process. That experience helps turn a business need into clear requirements, assess the results, recognise what needs correcting, and choose between proposed approaches. AI can offer useful suggestions, but judging them requires context that may never have been written into the prompt.

Describing that context is part of the work: the situations a tool must handle, the exceptions that matter, and what a useful result should look like. Those descriptions need testing and revision too. They can help evaluate today’s tool and provide a starting point for a better one later.

Working on Prospect Investigator has also made me pay closer attention to the cost and time involved in processing information: what needs to be examined, what can be reused, and what can be left out without losing something important.

Working with sensitive information

In technical sales, useful context often includes client information, project specifications, pricing and internal correspondence. Deciding how that information can be handled is part of designing the tool.

This is one reason I experiment with local models on a Mac mini on my desk. I want to understand where a smaller model, combined with ordinary scripts, can do a useful job: organising information, classifying an inquiry or preparing material for review.

Running locally does not settle every privacy question. The whole workflow matters: what it reads, what it stores, and whether anything leaves the machine. Using a cloud service also requires understanding how it handles the information and whether that use is appropriate.

These are questions I want to investigate through practical projects. Which tasks can be handled locally? When is a script enough? Where would a cloud model justify the additional complexity? The answers will depend on the work and the information involved.

Expect practical projects involving business tools, automation, AI and occasional hardware experiments, with attention to the decisions behind them and how they work in practice.

The pace of change sometimes makes me wonder whether an idea will be easier to build if I wait a little. But building now helps me understand the problem more clearly and test what a useful solution requires. A particular tool may be replaced; that understanding can carry into the next one. For me, that makes the work worth doing.