Questions and answers.

I work with businesses in different industries. I am most useful when a process is repeated, spread across several tools, or important enough that silent failure is not acceptable. The problem and the fit matter more than the industry.

Yes. Architecture and advisory is one of the three ways I work: review the system you already have, find the real constraint rather than the loudest symptom, and design the approach. Sometimes the useful outcome of that is me saying the build is not worth doing.

Yes, and it is a normal shape rather than an exception. I have led hands-on engineering teams and handed systems over to teams on three continents, so working alongside one is the same job from a different seat. What matters is that ownership is explicit from the start: who runs it, who is alerted, and what they have been given to run it with.

Both, and the software half is a practice of its own. Features added to systems that are already in production, taking over something whose author has moved on, integrations between what you run and what you bought, and custom applications where no product fits the shape of the problem. On that work the first week is usually reading rather than writing, because the expensive mistake in inherited software is the assumption nobody checked. Software Development & Feature Engineering, in full.

Yes, as a supporting practice rather than the headline one. Websites, internal tools and portals, built as part of the business behind them: information architecture, multilingual structure, performance, accessibility and an owner-controlled handover.

Start with the process that creates the most repeated data entry, chasing, missed handoffs or avoidable delay. Map the process before choosing the tool.

Usually not. A good first system often connects the useful tools you already have and replaces only the part that is causing the problem.

Yes, and the first piece of work is usually finding out what it does rather than changing it. That means reading it, working out where it fails silently today, and getting alerting and a way back in place before anything is rewritten. If the honest answer is that rebuilding is cheaper than inheriting, I will say so with the reasoning.

I use AI coding tools every day, with the same review discipline I put on any production work. It makes the first version faster. It does not change what gets reviewed before anything touches a real account.

The system should retry safe failures, alert the right person, preserve the work and provide a fallback or review path. Those behaviours are designed into the workflow rather than added after the first incident.

Yes, and it is one of the five practices rather than something adjacent to them. Cloud and hybrid architecture, infrastructure as code, container orchestration, CI/CD, observability, incident response, root cause analysis, disaster recovery and security hardening. It is also where the reliability habits in the automation work came from: I was VP of DevOps for a platform whose outages were public.

Accounts stay in the client’s ownership. I use scoped credentials or service accounts where possible and keep secrets out of code and workflow nodes.

For messy text, documents and images: reading them, extracting fields, classifying and routing, drafting for review, and checking one input against another. I keep deterministic code where certainty and repeatability matter more, and a model is never the last step before something is filed under somebody’s name.

Yes. The questions are the same ones I would ask about my own: what is the model actually deciding, what would catch it being confidently wrong, what is logged, who is alerted when a run fails, where do the secrets live, and what happens to the work in flight when it stops. An audit produces a list with severities and what I would change first, not a score.

Most first projects fall between a two-week scoped build and a two-month one. What moves it inside that range is how much scope the system covers, how many workflows it needs, how many systems it has to talk to, how messy the source data is, and whether there is a human review path and ongoing support.

I quote a fixed price against a written scope after a discovery call, so you approve the number before anything is built. If the scope turns out to be wrong mid-build, I say so and we re-scope rather than quietly absorbing it.

If you already know roughly what you need, tell me what exists today and I will tell you quickly whether it is worth building and roughly what shape the work takes.

There is no booking calendar. Message me on WhatsApp or send an email, and tell me what exists today. Normally a reply the same business day. If a call makes sense after that, we arrange one directly.

You do, and they are in your name from the beginning rather than transferred at the end. Scoped credentials or service accounts, no shared logins, and nothing in the system that depends on me being reachable.

That depends on the project. I provide documentation and handover so the system is not a black box. Ongoing support can be scoped separately. I have handed systems over to teams on three continents, so this is a normal part of the work rather than an afterthought.