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.
A bug in a web application prints a stack trace. A bug in a robot moves something. The response is not more caution at deployment time — it is to move the iteration into a simulator where it is cheap, and to measure the gap to the real system honestly rather than assert it is small.
What we build
Node topology, action and service design, lifecycle management and a command-and-telemetry layer that is not fused to one chassis — so the application survives a change of hardware and so the simulator and the real robot speak the same protocol.
Sensor pipelines across camera, lidar, radar and IMU, calibration, extrinsics and the filter design that produces a usable pose and a usable world model under noise. The work ends with a number for how uncertain the estimate is, not an assertion that it is accurate.
Gazebo, Isaac Sim or MuJoCo as the primary development environment, with scenarios and a scorecard that evaluate behaviour under the specific conditions that matter — not whichever ones are easy to set up. The simulator is the test harness, not a demo.
The firmware and real-time control underneath the stack: microcontroller work, motor control, CAN and other field buses, and the determinism budget that the control loop depends on.
Domain randomisation, system identification and the measurement regime that quantifies the sim-to-real gap. A deployment plan that treats the first contact with hardware as an event to instrument, not a milestone to celebrate.
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.
The worst outcome is not a stack trace. It is a damaged mechanism, a damaged environment or a damaged person. Every delivery practice that assumes a cheap revert has to be rebuilt around that fact, which is why the iteration happens in a simulator.
Behaviour that works perfectly in simulation can fail at first contact with hardware, because something in the model was wrong or missing. The honest version of this discipline treats closing the gap as its own ongoing engineering problem rather than something that resolves on its own.
The same system touches real-time embedded code, control engineering and probabilistic ML. Each has its own tooling, review culture and failure modes, and the integration between them is where defects hide most reliably.
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.
Recovering the original meaning of the metaphor, distinguishing the four kinds of debt, and making the interest payment visible in terms a finance function can act on. Including the cases where not paying it down is the correct answer.
Advanced · 11 minA test suite is a portfolio of instruments bought to answer different questions, not a coverage number to be maximised. How to design one for daily deployment, including flakiness, contract testing and the legitimate role of testing in production.
Practitioner · 11 minBranching strategy is a batch-size decision with organisation-wide consequences, not a matter of developer taste. Why merge cost rises with branch age, what replaces the long-lived branch, and what must be true before trunk-based development works.
Practitioner · 9 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.
Evidence over opinion
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.
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.