Because generating code and taking responsibility for a working system are different things. AI can be excellent at explaining concepts, drafting code, finding patterns and accelerating debugging. We use it for exactly those reasons.

Experience provides the context AI does not automatically have: how this particular site is built, what else depends on the change, whether the suggested library is appropriate, what security or data implications exist, how the browser behaves and what needs testing afterwards.

It is a bit like using AI to guide you through servicing a car. The instructions can be useful, but if you misidentify the part or do not recognise a warning sign, the cheap DIY fix can become expensive quickly. AI gives us better tools; years of experience still shape the decisions.

Yes, when it is used where it creates leverage. It can accelerate research, content exploration, prototyping, repetitive coding, debugging and analysis. That can let more of the budget go toward the parts that actually need human judgement.

We do not price a project around pretending every AI-generated output took hours by hand, and we do not ship generated work simply because it appeared quickly. Efficiency is useful only if the result remains accurate, maintainable and fit for purpose.

AI assisted. Experience led. The technology changes quickly; responsibility for the outcome does not.

Yes, where it helps — especially when a client has strong business knowledge but very little written material. AI can help organise interviews and notes, explore structures, identify gaps and produce useful starting points much faster than staring at a blank page.

But generic generated copy is easy to spot and easy to forget. We bring the content back to the client’s real customers, terminology, proof, objections, experience and point of view. The useful material usually comes from what the business actually knows that competitors cannot simply generate.

The aim is not ‘AI content’. It is better content produced efficiently and then reviewed by people who understand what it needs to achieve.

We start with the business case, not the platform. What problem are we solving? Who has the problem? How do they currently solve it? How will they discover the new thing? What behaviour are we expecting to change, and what would make the investment worthwhile?

A large audience, for example, does not automatically make a scalable digital product. The audience has to match the offer, the content has to be credible and sustainable, and the legal and commercial foundations have to make sense. Likewise, a technically clever product is not automatically useful if nobody knows to look for it.

Once the proposition makes sense, we can work out the recipe: platform, content, UX, integrations, launch and growth. ‘Can it be built?’ is usually the easy question. ‘Should it be built this way?’ is where experience matters.

We define the return around the reason for the project. For an online store that may be sales, conversion rate or average order value. For a lead-generation site it may be qualified enquiries. For an LMS it could be less administration, easier delivery or the ability to serve more learners. For an integration, saving staff hours every week may be the return.

That is why we ask what a win looks like before discussing a long feature list. There is little value in delivering every requested feature if none of them moves the underlying business problem.

Where measurement is possible, we want the foundations in place so the result can be reviewed after launch. Real client growth, efficiencies, failures and lessons are more useful than invented marketing numbers — and they help us improve the next recipe.