Development

What we are building now

Three pieces of software in active build. Each entry says what it does, who it is for, where it actually stands today, and the one engineering property that makes it worth building.

Our own product · In development

ActionableWhy

The problem. Customer experience surveys collect two kinds of answer. The ratings are easy to chart. The written comments are where the actual reasons live — and they are where nearly all of a researcher's time goes. Generic sentiment tooling flattens "the staff were rude" and "the website crashed" into the same negative score, which tells a business nothing it can act on.

What it does. ActionableWhy does the part a careful human researcher would do: it reads every written response, decides which of the survey's own drivers each one provides clear evidence for, and quotes the supporting line back. The researcher reviews and overrides; the machine assists and never decides.

The property that matters. Every classification is traceable to the customer's own words. Nothing is paraphrased, and an uncertain match is dropped rather than guessed — a quiet result is more useful than a confident wrong one.

For research teams and customer experience practitioners. Status: in development, running on Australian infrastructure in Sydney.

Client work, pro bono · Listening tests outstanding

Binaural Cue

The problem. A choreographer directing contemporary dancers can only cue the whole room at once. There is no way to place a sound at a particular point in space for one dancer, move it while they dance, and leave everyone else undisturbed.

What it does. Each dancer wears headphones. Sounds — a beacon tone, noise, a spoken instruction, the soundtrack — appear to come from a point around their head, and a director moves those points live, sending cues to one dancer, to some, or to all.

The property that matters. It runs entirely offline, on the machine in the room. A rehearsal does not depend on a network, and spoken cues are generated locally rather than sent anywhere.

For Opensource Dance Lab, for whom we built it pro bono. Status: every planned milestone is implemented; listening tests on real hardware are still outstanding.

Our own product · In design

strongbox

Most ways of keeping a recording private rest on a promise. strongbox rests on the maths: video is encrypted on the device, and our servers never hold the keys. We cannot read what is stored with us, and neither can anyone who compels us.

What makes it unusual is the consent model. A recording exists only while every person in it agrees it should, and any one of them can withdraw that agreement. Typical use is a small group holding something that must not circulate: a rehearsal, a class restricted for intellectual-property reasons, a family archive.

There is no feed, no audience, no discovery and no sharing outside the group. It is a vault, not a platform.

Status: in design. Scope, threat model and cryptographic design are agreed and written down; implementation has not begun.

What we do not publish

These descriptions stop at what each product does and the engineering property that makes it trustworthy. Architecture, data models and the specifics of how each one works are not published — not out of mystique, but because they are the work. If you need that detail for a commercial reason, write to us.

Get in touch