A developer woke up one day and wanted to control his computer’s mouse by moving his head. And AI was there :))
People have always “dreamed” of solving seemingly “unnecessary” problems like this. There’s nothing strange about that. But now, with AI, some of those ideas don’t have to disappear a few seconds later when they hit the “impossible” wall.
Matteo Gaudioso realized the sensor he needed was already in his ear: his AirPods.
AirPods already have sensors that can detect movement. But a Linux computer can’t easily use that data.
So Matteo started investigating the connection with Claude Code. After many failed attempts, he found a way to read the motion data and turn it into cursor movements.
The result was MousePods, an open-source project that works with supported AirPods models on Linux.
According to Gaudioso, the initial work took an afternoon and involved roughly 300 failed attempts, earlier open-source research, protocol analysis and tests on real hardware. Claude helped with research and coding; Gaudioso made the decisions and checked the results himself. His technical journal explains the protocol and Bluetooth setting involved.
It’s a useful little tool. But I think the story raises a bigger question: How many capabilities are already inside products we own, but aren’t easy to use where we want them?
A Feature Can Exist Without Being Available to You
A product can contain a sensor, a connection or useful data. That doesn’t mean we can use that capability wherever we want.
Sometimes there’s a technical barrier. The systems can’t talk to each other. Sometimes a company decides that supporting a particular platform isn’t worth the development and maintenance cost. And the platform owner often decides which interfaces give us access to the data.
The capability is there, but it can’t reach the place we want to use it.
I don’t know how many people want to use their AirPods as a head-controlled mouse on Linux. Probably not a huge audience :) But for someone who wants to control a computer without using their hands, that small feature could meet an important need.
Product roadmaps are usually built around the work that benefits the most people. A small group’s need can be real, but the cost of building, testing and supporting a solution can keep it waiting for its turn.
The need doesn’t disappear. It just remains unsolved.
The Economics of the Missing Bridge
I think this is where AI could change the equation.
Think about what it takes to turn an idea into something that works. You have to read documentation, study what others have done and run experiments. Something won’t work, so you figure out why and try again.
That work was part of Matteo’s project too. Claude helped him research and write code, but he still had to make the decisions and check the results on real AirPods.
AI doesn’t make all that work disappear. But it can reduce some of the cost of research and experimentation. That could make certain projects practical for one person or a small team, even when solving them for a small user group previously didn’t seem worth the effort.
Of course, MousePods is one example. It doesn’t mean every compatibility problem will be easy to solve. According to the project repository, AirPods 3 and AirPods Pro 2 have been tested on real hardware; some other models remain untested. Windows and Android aren’t supported at the moment either.
Experimenting may get easier, but technical limits and the need to maintain a solution remain.
What Can Product Teams Learn From This?
When a user wants to use our product in a way we don’t support, we usually ask: How many other people want this?
I think there’s another question worth asking:
How hard are we making it for someone who wants to solve the problem?
Maybe we can’t build the feature ourselves. But we can offer a clear way to export data. We can document an interface. We can let other tools connect to our product reliably.
That could allow users or other developers to solve some of the needs our own team can’t fit into its roadmap.
Of course, opening everything to everyone isn’t a simple decision. There are security, privacy and support questions. But keeping a capability inaccessible has a cost too: users give up on the need, move to another product or try to find their own solution.
I think these three questions are a good starting point for product teams:
Which features can customers use in one place but want to use somewhere else?
Which small groups are trying to build their own solutions because their needs haven’t made it onto our roadmap?
If we offered a reliable, documented connection, could those users meet their own needs?
Maybe a new feature idea will come out of that. Or maybe, instead of building a new feature, it’s enough to help people connect the tools they already have.
The Product Doesn’t End With Its Feature List
When we buy a device, what we can do with it is largely shaped by the features its manufacturer makes accessible and the uses developers choose to support.
That won’t change overnight. Platforms still control access, and some barriers remain difficult or even impossible to cross.
But as the cost of experimentation falls, we may see more small groups build the missing bridges for their own needs.
Maybe the next useful feature in a product we already own won’t come from a manufacturer’s update. A user might simply decide not to set aside that small question this time:
What else can I do with this?