Practice

Four things we are good at

We take on the software a business already depends on, where a rewrite is unaffordable and a patch is not enough. The work tends to fall into four areas, and most engagements use more than one. Each is described here the way we would describe it to an operator, not to a procurement panel.

Cybersecurity & trust

Most of the systems we inherit were never designed to be attacked, only to be used. We start by working out what an intruder would actually reach: which credentials open more than one door, where money or records move without a second pair of eyes, and what happens to a session when someone walks away from a shared desk. From there we tighten the parts that matter first, put an audit trail behind the actions that cannot be quietly undone, and write the response down so the team can act on it at two in the morning without calling us.

Cloud & infrastructure

Infrastructure should be boring, and a bill should be explainable line by line. We move workloads onto managed platforms when that genuinely reduces the number of things that can break, and leave them where they are when it does not. The plan usually covers deploys that a person can roll back in one step, backups that someone has restored from on purpose, and alerts that point at a real symptom rather than a dashboard nobody opens. We would rather run two small services well than a platform nobody understands.

Data & applied AI

Data work starts with a question someone already asks out loud, not with a warehouse. We trace where the numbers come from, fix the places two reports disagree, and give the answer a home where it can be checked. When a model belongs in the loop, it earns its place on a narrow task with a measurable error rate, and a person keeps the decision. When it does not, a rule and a clear report do the job for a fraction of the cost and none of the surprise.

Product & platforms

A platform is what a business builds on for years, so we design for the second and third team to use it. That means plain interfaces with names that match the work, a boundary between what is shared and what each team owns, and documentation written for the person who arrives after us. We ship in stages that the operators can inspect, so the software changes under them without the ground moving, and we stay close until the new way of working has actually settled.