Software that has to talk to machines
Equipment that predates the cloud, protocols documented in a PDF nobody scanned, and a device that answers in eleven milliseconds or not at all. This is the work where you cannot iterate until it passes: a wrong write stops a line, and the test environment is a running operation.
Talk to an engineerWhen teams call us
- A machine speaks a protocol the vendor documented once, in 2009, and the person who understood it left.
- Telemetry arrives, and nobody trusts it: readings drop when the link degrades and nothing records that they dropped.
- The device works on the bench and fails in the field, where the network is intermittent, the power is not clean, and the temperature is not room temperature.
- A control command has to be idempotent because the connection retries, and right now sending it twice does the thing twice.
- The plant has an operations system and an administrative system and they exchange spreadsheets, by hand, once a day.
- The call platform drops audio under load and the logs describe the application, not the SIP traffic.
What we build
Telemetry that reports its own gaps
MQTT and industrial protocol ingestion where a missing reading is recorded as missing, not silently skipped. Data whose absence is invisible is worse than no data: someone will make a decision on an average that quietly excluded the hours that mattered.
Device control that survives a retry
Commands with idempotency keys, acknowledgement, timeout and a defined state when the answer never arrives. On a network that drops, ‘did it execute?’ has to be answerable without asking the operator to look.
Bridges to systems with no API
Legacy equipment and administrative software connected without replacing either. Reading a proprietary format, wrapping a serial protocol, or driving an interface that was never meant to be automated.
Field conditions designed in, not discovered
Intermittent connectivity, buffering while offline, ordered replay on reconnection, clock drift between devices. The bench is not the field, and the difference is where the incidents come from.
Real-time voice and signalling
Asterisk and Kamailio, SIP traffic handling and call-centre systems, instrumented at the protocol level rather than only at the application.
Typical projects
Connect equipment to a system that can use it
Read from the machine, normalise, and deliver it somewhere decisions get made — with the gaps visible and the history intact.
Replace a manual export between two systems
The daily spreadsheet becomes an integration, with reconciliation so a discrepancy is detected rather than discovered at month end.
Instrument a telemetry pipeline that nobody trusts
Find where readings are lost, make loss explicit, and give operations a way to tell a broken sensor from a broken link.
Stabilise a voice platform under load
Instrument the SIP layer, find where the audio degrades, and fix the cause instead of adding capacity around it.
What you get
- A running integration in your infrastructure, in your repository
- Protocol behaviour written down, including the parts the vendor documentation gets wrong
- Instrumentation that distinguishes a device fault from a network fault
- Tests that exercise the failure modes: dropped link, duplicate command, clock skew
- A handover with the people who operate the equipment, not only the ones who write code
Questions we get asked
Why not have an AI write this integration?
It will write plausible code for a protocol it learned from public documentation. The problem is that the machine in front of you does not always follow that documentation, and the only way to find out is to connect to it and watch. That knowledge is not on the internet: it is in the equipment and in the people who run it.
Do you work on site?
Where the work requires it, yes, with the client's team. Much of the integration can be done remotely once there is a way to observe the device, and getting that observation in place is usually the first task.
We have equipment nobody understands any more. Is that workable?
That is the common case. We start by watching what it actually does rather than what the manual says, and write down the difference. Often that document is worth more than the integration.
Which protocols do you work with?
MQTT for telemetry, serial and industrial protocols where the equipment requires it, SIP for voice. If your equipment speaks something we have not seen, the first step is a short investigation to characterise it, scoped separately — and if it turns out to be a bad fit, we will say so.
What if the failure only happens in production?
That is most of them, and it is why instrumentation comes first. A failure that cannot be observed cannot be fixed under pressure, and a plant is a poor place to be guessing.
Start a conversation
Tell us what you are building, or what is currently breaking. You will get a straight answer from an engineer, not a sales script.