Engineering + Intelligence + Impact

We work across software architecture, applied AI, embedded systems and the technology that makes circular business models possible. Those four look like separate disciplines until you have to make a physical product report its own condition to a service that decides whether to repair or replace it — at which point they are one problem.

What we can be judged on today is method, not scale: how we diagnose, what we write down, how we hand work over, and whether the numbers we quote back to a client can be reproduced by that client without us. Those are the things this page describes.

We take engagements where the constraints are real — existing systems, existing teams, regulatory limits, hardware that already shipped. Work with no constraints is not consulting; it is a prototype with an invoice attached.

Software is a claim about how an organisation intends to behave. When the software contradicts how people actually work, people route around the software, and the data goes with them. Fixing that is rarely a matter of a better framework.

Complexity is not a badge. Every abstraction, service boundary and queue is a permanent operational cost paid by whoever is on call. We add them when the alternative is worse, and we say which alternative we compared against.

A result that cannot be measured cannot be defended. If we cannot describe how you would tell whether the work helped, the work is not ready to start.

Handover is the deliverable. The point at which your team can change the system confidently without us is the point the engagement succeeded.

We start from what cannot change — the regulation, the existing integration, the battery budget, the team that has to maintain it. Constraints eliminate more options than preferences do, and eliminating options early is the cheapest work available.

Then we look for evidence in the running system rather than in the description of it. Descriptions are consistently optimistic; traces and logs are not.

Only then do we design, and we design at least two options so the trade-off is explicit. One option is a preference dressed as an analysis.

After the decision, we instrument it, because a decision without a feedback path is a guess with better formatting.

Most of a system should be made of things that are well understood, well documented and easy to hire for. Databases you can reason about, queues with known failure behaviour, deployment paths that a new engineer can follow on their second day.

That restraint is what buys the budget to be genuinely inventive in the one or two places where the problem is actually hard — the scheduling algorithm, the state machine, the numerical method, the sensor fusion.

We treat operability as a design input rather than a later phase. Structured logs, meaningful health checks, migrations that can be rolled back and failure modes written down before launch, not discovered during one.

And we write tests around behaviour that matters, not around coverage targets. A suite that nobody trusts is worse than a small one that everybody does.

We start from the process, not the model. If a workflow is undefined, automating it produces faster confusion. The first output of an AI engagement is usually a description of how the work is done today — which is often the first time anyone has written it down.

Agents get explicit boundaries: which tools they may call, which actions require a human, what they may read, and what they may never write. An agent with unbounded permissions is not autonomous, it is unsupervised.

Evaluation comes before deployment and continues after it. We build the evaluation set from real cases, including the ones that went wrong, and we treat a drop in that score the same way we treat a failing test.

And we are direct about the cases where a model is the wrong instrument. Deterministic rules, better data entry or a fixed process step are frequently cheaper, more accurate and easier to defend to an auditor.

A query that scans a table it did not need to scan burns real energy in a real building. Efficiency work has never needed an environmental justification to be worth doing — but the environmental effect is real, and it is measurable at the level of the system we changed.

Extending the working life of equipment usually beats replacing it with a more efficient model, once the embodied cost of the new unit is counted. Software is often what makes the extension possible: condition monitoring, better scheduling, a retrofit interface onto a machine that is otherwise mechanically fine.

Circularity is a data problem before it is a materials problem. You cannot refurbish, resell or recycle what you cannot identify, trace and assess — and all three of those are software.

We report what we measured on the systems we touched. We do not publish aggregate environmental figures we cannot verify, and we will not attach an unverifiable number to work we did.