Keeping up with developments in AI is a substantial part of my work. I help clients identify the tools and approaches that make sense for their situation: what is ready to try, what could save them work, and where it is wiser to wait.
I offer two fixed-price packages and ongoing work as a fractional AI lead. I work remotely, usually across several projects. Helping develop different AI systems gives me a broader perspective and helps me recognise patterns that are harder to see from within one company. It also lets me assess earlier decisions without having to defend them. Alongside reviews, I can take ongoing responsibility for a system's architecture, rather than adding another developer's capacity to the team.
Before we start, we agree the scope, the information and access I will need, and the delivery date. I write my findings for the people who need to use them, including those without an AI background. I use examples and analogies, explain the options and trade-offs, and make clear why I recommend a particular approach.
Review of a system before launch or before purchase
Companies usually ask for a review when a proof of concept (PoC) or pilot is ready to move into production. That brings different demands: the system needs to handle real workloads, quality needs to be measured, and running costs need to remain acceptable as usage grows. Regulatory requirements also need to be addressed. Often the immediate trigger is a larger budget decision, the first outages or an unexpectedly high running cost.
I review the architecture and how answer quality is measured. Without reliable evaluation, it is difficult to tell whether a change is an improvement. I also look at what happens when a component fails, what drove last month's running costs and where scaling could cause costs to jump. That includes telemetry, failure records and the feedback process used to prevent recurring problems. I need access to both the people who built the system and those who will maintain it. Documentation alone rarely captures why decisions were made, and improving that record is part of the work.
You receive a document with recommendations ranked by priority, an estimate of running costs, a proposal for measuring quality on a regular basis, and an overview of the gaps in documentation, oversight and logging under the European rules on AI and on the protection of personal data. I assess regulation from an architectural and operational point of view, meaning what needs to be added so that compliance can be evidenced; I leave its legal interpretation to lawyers. You also receive a presentation for management, because the next step is usually decided by people who will not read the full document. This typically takes one week.
I also offer this assessment to investors, family offices and smaller funds considering an investment in an AI business, and to companies assessing an AI supplier before signing a contract. A presentation rarely tells you which parts of the technology are hard to replace, how much rebuilding them would cost and how long it would take, or what switching providers would involve. So I ask where the data came from and how the stated accuracy was arrived at, for instance whether it comes from sample data rather than from production, and how far the whole thing depends on particular people: whether a specification exists to build on, whether decisions and meetings are recorded anywhere, and whether someone new could take the project over without having to ask the person who has left.
You receive a report with risks ranked by impact, an assessment of key-person dependencies and what the departure of one of those people would mean, and questions worth putting to management or the supplier before signing, whether to get them answered or to learn something from the way they are answered. The decision remains yours; my role is to give you a clear technical basis for it. This review usually takes five to ten working days.
A PoC on your data
This option makes sense when a product team has one specific idea in mind and the company is divided over whether it is feasible at all. That kind of disagreement is rarely settled by discussion, because the answer depends on your own data and what it actually looks like, not on the demonstrations shown during a tender.
I build a prototype using your data and design an evaluation to test what it can realistically achieve. The useful answer is often more detailed than yes or no: some parts of the task work well, while others remain infeasible within the tested scope. That distinction can be more useful than a single overall score. We look at what would be required for production, what level of accuracy is acceptable and how to measure it reliably. If the approach is not viable, I say so early, because a no after three weeks costs you far less than the same answer after a year of development.
The guaranteed deliverable is the experiment itself, measured results rather than a demo, and a recommendation on whether and to what extent to continue with the plan. For the part of the task where feasibility is confirmed, you also receive a working prototype, a proposed architecture and a cost estimate for a version that could go into production. The decision on whether to build further then rests on numbers from your own environment rather than on the impression a demonstration leaves. From the outset, I document the specification and the decisions behind the prototype so that someone else can continue the work. This usually takes three to four weeks.
Long term: fractional AI lead
Ongoing work suits companies that have no senior AI person on a full-time basis, or that have a team with nobody accountable for its direction. In that situation decisions are either postponed, because nobody is willing to take them, or they are taken by whoever happens to be loudest, at a time when the options change faster than an annual plan can mature.
I take responsibility for the AI roadmap, help decide what to build, buy or adapt, and review the architecture and technical deliverables. I work with the team to build its ability to make these decisions without relying on me. I place particular weight on how a project is run: agreeing the specification before implementation, recording meetings and decisions, keeping documentation that AI helps to maintain, and arranging an independent second opinion that checks the result before it is treated as finished. In my experience a project run this way does not rest on one person's memory and can be picked up without a lengthy handover, and that holds for more than software. I also follow what is happening in AI on your behalf and tell you which of it actually concerns you, because a large share of the news will not touch your product at all, and telling the difference takes time your team usually does not have.
You retain a record of the decisions we make and the reasons behind them, so that six months later it is still clear why you chose as you did, along with architecture documentation that remains useful after our work together ends. The engagement usually covers one or two days a week, with a flat fee for the role and agreed availability.
How I bill work done with AI
I charge for the agreed outcome, not the hours it takes. AI is part of how I work, and I remain responsible for the result. We agree the scope and price before starting, so you know what to budget. The price stays the same whether the work takes me more or less time than expected. If the scope changes, we agree any changes to the price before the additional work begins.
The same question reaches everyone who sells their own work sooner or later, so I also help clients explain this approach to their own customers: what outcome they are paying for, what is included and how changes to the scope will be agreed.