STOM Research

STOM Research is a well-funded research arm with a specific job: find the friction points that software can alleviate. Sometimes the friction is already there and nobody has named it. Sometimes the more interesting move is to create one.

That second half is not a joke, and it is worth being precise about. Every product category begins as a friction nobody felt until something made it visible. Nobody missed the software they had never used. The research question that actually generates products is not "what are people complaining about," which gets you incremental improvements to things that already exist. It is "what would people find intolerable once they knew it could be otherwise." Answering that requires deliberately introducing the contrast, and that is a thing you have to fund properly to do at all.

Being well funded is what makes the difference between the two modes. Chasing reported complaints is cheap and produces small results. Investigating a system deeply enough to see the friction its own users have normalised takes time that has to be paid for before anyone can tell whether it will pay off. We treat every investigation like a map: not just what happens, but why it happens, what constraints shape the outcome, and which patterns repeat when real-world conditions change.

STOM Research is also the parent of Team of Monkeys, the studio behind our cybersecurity tools, our webOS and Tizen apps, and our TV Channels. It drives the robotics work described in Our Mission and the data provisioning at WorldPoint Instruments. Every one of those started as a friction point somebody mapped first.

How a friction point becomes a tool

Our public security tools are the visible output of this process, and each one traces back to a specific piece of friction. Checking whether a site leaks something an attacker would want was work that required expertise and a stack of separate utilities, so WP Security Report and Drupal Drip collapsed it into one click. Site security had no legible unit of measure you could watch improve, so Security Report Card assigned a grade. Inspecting a single tab's traffic meant running a full packet analyser, so Tab Shark scoped it down. Nobody could say how an AI crawler saw their page, so CrawlCheck scored it.

The pattern holds in every case: identify a task that is possible but annoying enough that people skip it, then remove the annoyance until the task becomes routine. Most security failures are not exotic. They are ordinary checks that nobody ran because running them was tedious.

What makes a system legible

We do not just observe how technologies work. We go into their architecture, their dependencies, their failure modes, and their potential for enhancement. Our teams build layered models: inputs and interfaces, storage and processing, and the operational signals that indicate health or stress.

That layering matters because complexity is rarely evenly distributed. Most systems are boring in ninety percent of their surface area and genuinely difficult in the remaining ten. Finding which ten percent is the actual work. Once you know where the difficulty lives, you can explain the behaviour in plain language without losing the technical precision an engineer needs to implement a change confidently.

Where assumptions break

Our methodologies are designed to uncover the hidden mechanisms that power modern systems: software architectures, hardware implementations, network protocols, and data processing pipelines. What we are hunting for are the handshake points, the seams where one component's assumptions meet another's guarantees and the two do not quite line up.

Those seams have recognisable shapes. Timing windows, where correctness depends on an ordering nobody wrote down. Edge-case inputs that were never in the test set because nobody imagined them. State transitions that are unreachable in theory and routine in production. Dependency mismatches that stay invisible until load, latency, or a version bump makes them visible all at once. None of these are exotic. They are simply the places where a system's real behaviour and its documented behaviour diverge, and they only surface under pressure.

Why agentic systems change the analysis

Software that acts on its own changes the failure surface in a specific way. When a human drives a workflow, a human is available to notice that something looks wrong and stop. Remove that, and the system needs to carry its own judgement about when to proceed and when to halt.

This is the same problem as multi-agent coordination generally, and the same reason our agentic teamwork framing runs through everything we build. A team of agents can accomplish more than one, but only if handoffs are explicit, state is inspectable, and every participant fails loudly rather than quietly. An agent that silently produces a plausible wrong answer is worse than one that stops and says it is stuck. We analyse agentic architectures with that priority: not how impressive the system is when it works, but how it behaves at the boundary of its competence.

What we deliver

Findings alone are not the product. Decisions are. Our engagements typically produce a set of artifacts designed to survive after we leave.

How we work

Prototype, measure, refine. We treat a system as a living machine with feedback loops, not a static diagram. Deep technical review is paired with fast experimentation so hypotheses get validated early, while course corrections are still cheap.

Throughout, we document assumptions and unknowns explicitly. The client team should always be able to tell which of our claims is proven, which is probable, and which still needs verification. Collapsing those three categories into a single confident-sounding report is how bad decisions get made, and we would rather hand over an honest map with blank regions marked than a complete-looking one that is partly fiction.

Responsible research

We approach sensitive systems with discretion and care, and we treat safety and ethical constraints as part of the engineering rather than a compliance step at the end. When we identify vulnerabilities, we prioritise remediation pathways and coordinated disclosure practices that reduce exposure without stalling progress.

The reasoning is straightforward: technical capability is only valuable when paired with discipline. This is also why our public security tools are scoped to sites and networks you are authorised to test. The same principle applies whether the work is a private engagement or a free Chrome extension.

Research that shows up in products

Much of our most significant work stays confidential, but its effects are visible in what we ship publicly. The rigour used to analyse infrastructure informs how we build apps: faster experiences, fewer dead ends, clearer behaviour under load, and privacy-first defaults.

Living-room software makes this concrete. A TV app runs on constrained hardware, is driven by a remote instead of a pointer, and may stay open for hours. There is nowhere to hide a memory leak or a lazy render loop. The constraints of the platform enforce the discipline the research recommends.

Continuous learning

After a project ends we run retrospectives: what broke, what improved, and which metrics actually mattered. That knowledge becomes reusable guidance for the next engagement, which compounds. We also push clients to maintain documentation, so future teams can understand past decisions without rediscovering the same problem from first principles.

Working with us

Our partnership model is meant to be helpful, not mysterious. We explain the why, we provide the how, and we leave behind artifacts that reduce future friction. Whether you are optimising legacy systems, validating new capabilities, or preparing for the next wave of agentic technology, STOM Research works as an extension of your team.

Reach us at support@teamofmonkeys.com.