From a Commodore 64 to AI agents.

I started with computers as a child in the 1990s, and the honest description of why is curiosity rather than ambition. I wanted to know how the thing worked. My first machine was a Commodore 64, a computer that made you understand it, because it did very little unless you told it what to do.

I copied code out of magazines, ran it, broke it, and changed it until it did something else. That loop (try, fail, work out why, try again) turned out to be the whole of programming, and it is the reason I still think the machine taught me more about problem-solving than any textbook did.

The other thing that arrived around then was an interest in intelligent machines as an idea. I was fascinated by the possibility long before it was a realistic prospect, which is worth saying plainly, because it means my interest in AI is not something that appeared when it became commercially interesting.

The hobby became a career through the ordinary route: studying, then working. I took a degree in Computing for Business at Northumbria University, learning to see technology as a tool for running a business rather than an end in itself.

Over those years I worked in PHP, JavaScript and MySQL, and moved outward into systems administration, hosting, networks and infrastructure. I built e-commerce and business software. That range is the useful part of my background: I have spent a long time at the layer where technology meets a business that has to keep running on Monday morning.

I founded Manchester PC (opens in a new tab), a computer repair and IT support business in Manchester, and I still own and run it. It repairs laptops (opens in a new tab), desktops and Macs, recovers data (opens in a new tab), supports the technology small organisations rely on, and builds custom machines.

It is also, and this matters more than the service list, where I learned how a company actually works. Not from a course or a framework, but from being the person the phone rings through to.

Running a small business is mostly administration, and almost nobody tells you that in advance. You open a company imagining you will spend your time on the work you are good at. You spend it making sure that work happens in the right order, at the right time, for the right person.

The hardest part is not any individual task. It is the coordination: holding the whole thing in your head. Which part is arriving Thursday. Which invoice has not been paid. Who was promised a callback. That mental model is the most valuable asset in a small company, and it is the thing that breaks first when things get busy.

I bought a lot of software trying to fix that. Some of it was very good. Almost none of it removed the work; it moved the work and added a login. Eventually I worked out why, and it became the idea the rest of my working life now runs on: small businesses do not usually lack software. They lack coherence between the software they already have.

The other thing the business taught me was less comfortable. Much of what comes through the door is working equipment that somebody has been persuaded to replace. I decided early that we would tell people when a repair was not needed, which is a slower way to run a business and a more durable one.

The change came in 2023, and the honest version is that it was a rediscovery rather than a discovery. I had been interested in intelligent machines since childhood. What happened was that the technology finally caught up with the interest.

Using modern conversational AI connected directly to that old curiosity. But the thing that mattered for my work was narrower and more practical: it had become good at the messy part. Not the structured part, because software had always handled booking a slot or storing a record. The messy part is what arrives before any of that: a person describing what they want, in their own words, in the wrong order, with half the information missing.

That step used to require a human because it required understanding. It is not solved, and anyone who tells you it is has not had to depend on it. But it crossed the line from impossible to workable, and workable is the only bar that matters when you are running a business rather than writing a paper.

From experimenting with existing tools, I moved into building software with AI assistance. That has meant working with coding agents, running several at once on independent pieces of work, using version-controlled branches, written specifications and structured documentation so that an agent can be useful rather than merely fast.

The lesson I keep relearning is that the bottleneck moves rather than disappears. An agent can produce a plausible implementation of almost anything. It can also produce a plausible implementation that is subtly wrong in a way that will not surface for three weeks, and that second kind is more expensive than writing it yourself would have been.

So the work reorganised itself into something closer to editing and architecture: less time producing, far more time reviewing, specifying and checking. That is not a complaint. It is a genuinely different job from the one I had five years ago, and it suits me better than the old one did.

I also work with local models as well as cloud ones, partly out of technical interest and partly because a business that depends entirely on something it cannot host has taken on a dependency it should at least have thought about.

Step Into AI (opens in a new tab) is the direct answer to the problem I had already spent years living with. It is an AI platform for UK service businesses, built around one customer journey: the call or message that comes in, the reply, the record of who the customer is, and the follow-up that turns an enquiry into booked work.

The premise is that a business does not lose work because it is bad at the work. It loses work because an enquiry arrives while everyone is on a job, the call goes unanswered, the quote never gets chased, and the customer quietly books somebody else. Those are the leaks, and they are invisible from inside the business.

The design decision I care most about is that nothing goes out without a setting attached to it. Every automated action is configured as hold for my approval, send automatically under rules I define, or escalate to a person. That is not a technical nicety. It is the thing that makes any of it adoptable. A system that cannot be dialled back will not be switched on, however good it is.

It is live and working with a small group of pilot customers. I am not going to claim it transformed anybody’s revenue, because I do not have those numbers yet and I am not going to invent them.

The direction I am working towards is fewer systems, not more. Something closer to an operating system for a small company than a collection of applications: one place where the business lives, where the phone call, the customer, the job and the follow-up are the same object seen from different angles, and where the interface can increasingly be a conversation rather than a dashboard.

That is a direction, not a delivered product. Parts of it exist. Parts are being tested. Parts are a sketch I believe in and cannot yet demonstrate.

Alongside it, there are two threads I expect to keep pulling. The first is the environmental question: the argument that the most sustainable device is the one already in use, and that this applies to business systems as much as to hardware. The second is what actually happens to work inside a small business when software starts answering the phone: not the headline version, but the specific changes to what people pay attention to.

I am writing about all of it as it happens, including the parts that do not work. The honest version of building something is more useful to read than the polished one, and there is quite enough polished writing about AI already.