What I can help you
do with AI.

Yes. A rough description of what you want to do, or of what’s frustrating today, is enough for a first conversation.

Both. I can help work out what’s worth doing, build a working tool or workflow, and help the team use it. The right starting point depends on what you need.

No. That experience is part of how I approach a business, but the work also includes commercial systems, operational workflows, internal tools, and team enablement. Entec, a 15-person services business, is one example.

No. I use normal software for calculations, exact matching, and repeatable rules. AI is useful where interpretation, extraction, or language helps. We choose the approach that fits the job.

I hand over the code, documentation, and access you need to run the build. I aim to build in accounts you control. We agree third-party tools and any licensing dependencies in the scope.

We spend about 30 minutes on what you’re trying to do and how it works today, and we usually end with a sensible next step. There’s no charge and nothing formal to prepare.

Yes. Maybe the team uses ChatGPT, you have bought a few subscriptions, or an automation never quite stuck. We can look at what’s getting in the way and work out what’s worth changing. Often that’s a narrower first use, or a better fit with how the work actually happens.

Yes. I can help you review current use, establish spending and tool guidelines, clarify ownership and responsibilities, and agree what needs checking before an experiment becomes part of everyday work. The aim is to support useful experimentation while making expectations clear. More on putting structure around AI.

We agree what success looks like before the build starts: a number that should move, time that should come back, or a decision that should get easier. After handover we check against that measure, rather than a general sense that it helps.

It stays in your systems and accounts. A build reads what it needs through connections you control. If an AI or automation provider processes any of it, I document what is sent, where it is processed, and how long it is kept before the system goes live. I never use one client’s data to build another client’s system.

Before launch I estimate the running costs: AI usage, hosting, and any subscriptions, all in accounts you own. Handover includes documentation and a note of what to keep an eye on. If you’d rather I keep watching it, or want to keep adding to it, that’s a separate, optional arrangement.

The aim is for your system to benefit from better models rather than be replaced by them. Your business rules, connected data, and workflows form the foundation. We use conventional code for calculations and fixed rules, and AI where interpretation is useful. Where practical, we keep that AI component separate so we can assess different models as their capabilities and costs change. Switching still needs testing, and some changes need development, but the knowledge and structure built around your business don’t have to be recreated because a new model arrives.

Yes, that’s the aim. The rules and connections are ordinary code, the documentation and accounts are yours, and handover includes a session with whoever will look after it. Typical upkeep is small: checking a connection, adjusting a rule, keeping an eye on AI usage. Ongoing support exists for businesses that would rather I do that, or that want to keep adding to the system.