Checks, runs, metrics and incidents across web, publishing, AI and blockchain systems — flow metrics with their denominators, daily verification of live products, and alerting designed not to cry wolf.
Most organisations argue about delivery performance from memory. Telemetry ends the argument. A monitoring system that reports green because it has not heard anything is worse than no monitoring, and a flow metric reported without its denominator is worse than no metric.
What we build
A unified model across web, publishing, AI and blockchain systems: the check is the definition, the run is the recorded result, the metric is the aggregate and the incident is the record of what went wrong. One schema; everything else is query.
Not to pass. A check that has not reported inside its window becomes an explicit unknown — distinct from passing, distinct from failing — because a monitoring system that calls silence green has been quietly broken for everyone who has used one.
Throughput, cycle time, work in progress, change failure rate and deployment frequency, each reported with the population it was measured over. A number without a denominator is a slogan, and slogans are what get presented when the real metric is bad.
Browser-level journeys that re-run the thing a real user actually does, every day, against the real production system. The point is not synthetic uptime; it is a durable record of whether yesterday’s product still works today.
Pages tied to user impact and to pre-agreed service-level objectives, with the noisy alerts moved to dashboards or deleted. A suite that cries wolf gets switched off, and the cost of a switched-off suite is paid in the incident everyone misses.
The hard parts
A vendor who cannot tell you where their own discipline is difficult has either not done it or is not going to tell you the truth about your project either.
A system that distinguishes pass from fail from unknown admits more ignorance than most dashboards are prepared to show. That is the point. Hiding the unknown behind a green tile is where confidence decays and incidents accumulate.
Any metric a team is measured on is a metric they will optimise for, including by splitting the work. The design of the measurement system has to assume this and look for it, rather than treating gaming as a cultural failure to be exhorted away.
Once a team has learned to ignore the alerts, no amount of retuning restores trust in the next page. The budget for noise is small and spent carelessly, which is why the first job of this discipline is deleting things rather than adding them.
Stack
The full stackThis is what we reach for when the decision is ours. When you already have an estate, we work in it — the stack is part of the engagement, not a precondition of it.
Roles we staff
The reasoning, published
Every capability has a matching domain in the knowledge library. Read it before you talk to us — it is the fastest way to tell whether we know what we are doing.
The four key metrics are the best-evidenced delivery measures available, and they break the moment anyone is rewarded for them. Precise definitions, the specific gaming each invites, and how to report them so they survive contact with executives.
Practitioner · 10 minFlow time, throughput, flow efficiency, flow load and flow distribution — what each one tells you, how to instrument them from an ordinary Jira or Linear board, and why percentiles and Monte Carlo beat averages and estimates.
Practitioner · 10 minStory points were invented to stop teams being compared on hours. Reporting velocity upward reintroduces exactly the problem they were meant to solve, and the damage is predictable. What to report instead.
Foundational · 10 minHow to buy it
Capability answers who works on it. The engagement model answers what we are accountable for, how it is priced and how it ends.
Other capabilities
Probabilistic systems
LLM applications, retrieval systems, agents and applied ML built to a standard you can put in front of a regulator — with evaluation harnesses, cost controls and failure behaviour designed in rather than discovered in production.
Software that acts
Systems that choose their own next step — tool-using agents, orchestrated workflows and automation that spans your existing systems — designed so that what they are permitted to do, and what happens when they are wrong, are decided up front.
Irreversible deployment
Protocol and application development where a deployment cannot be rolled back and a defect is a withdrawal. Contract engineering, security review, upgradeability design and the on-chain boundary decision.
Gated releases
iOS, Android and cross-platform applications delivered continuously despite a third party sitting between your merge and your users — staged rollouts, feature flags, release trains and a native-versus-cross-platform decision made on economics.
The paved road
The substrate the other three stand on: cloud infrastructure, deployment pipelines, observability, data platforms and the internal paved road that determines how fast every team above it can move.
Software that moves
ROS2 applications, perception and state estimation, embedded and motor control, and the simulation-first workflow that lets behaviour be proven in a simulator where failure costs nothing before it meets hardware.
The work between the systems
Integration between the systems you already run, scheduled jobs with named ownership, cross-system reactions and the auto-recovery that keeps them honest — because an automation that fails silently is worse than no automation.
Publishing at cadence
Ghost and headless CMS work, editorial workflow and scheduled publication, membership and subscription publishing, and the migrations that move a publication between platforms without losing URLs or archives.