When a service asks for something that does not exist yet
In a product that is one thing, anything you add you add for everyone. In a platform of modules, a specific request can be built for the service that made it.
A therapy lead describes the session she runs on Thursday mornings, with a particular group, in a particular way — and then asks whether the headset can do that.
Sometimes it already can. Sometimes it cannot, and in most software that is the end of the conversation. The request goes on a list. It competes with every other request from every other customer, and if it ever ships, it ships to everyone, eighteen months later, in a version that has been sanded down until it fits the average.
That is not a failure of goodwill. It is what happens when a product is one thing. Anything you add, you add for all of it.
RVer is not one thing. It is a base plus modules, and that changes the answer.
What a module actually buys
RVer is a native platform for the Meta Quest 3, running entirely on the device. No accounts, no login, no cloud dependency — patient data does not leave the building.
Capability is packaged as modules, licensed and enabled per device:
- RVer — the base immersive 360° video library
- RVer Motion — movement and physiotherapy activities
- RVer Neuro — cognitive training and stimulation activities
Because capability lives in modules rather than fused into a single application, something new does not have to be built for everybody in order to exist. It can be built for a use case — one kind of session, one population, one way a team prefers to work. It can be built for a single client. It can be enabled on one device, in one room, if that is where it belongs.
So the therapy lead is not asking us to change a product that every other service depends on. She is asking for a module. That is a much smaller, much more answerable question.
The services that did not ask for it never see it
This part matters more than it sounds.
Software that accumulates everything anyone ever wanted becomes heavy for the people who use it daily. A care assistant starting a session before lunch should see the handful of things her service actually does — not a menu carrying another institution's requirements.
Modules keep that true. A device carries what its service enabled and nothing else. Growth in the platform does not become clutter on the headset, and staff are never trained around features that were meant for someone else.
It also means a bespoke module is not a fork. Everything sits on the same base, managed the same way, updated the same way. One fleet, whatever mix of capability is running on it.
And it arrives without anyone travelling
Modules are switched on remotely, and both the app and its content update over the network.
A decision taken on Tuesday is live on the fleet. No reinstall, no engineer in the corridor, no headsets boxed up and sent away. When a module a service already has gains new activities, they simply appear.
That is how the most recent release reached the fleets already running it: both RVer Motion and RVer Neuro gained new activities, and the movement data RVer Motion produces for the clinician became more detailed. Nothing was installed by hand, and no hardware changed.
The commercial side of this — paying only for the modules you enable, on only the devices you enable them on — we wrote about separately, in why modular software suits a healthcare institution. Here the point is narrower: what the architecture makes possible to build, not what it makes cheaper to buy.
What this is, and what it is not
RVer Motion is a movement tracking and exercise aid. RVer Neuro is cognitive training and stimulation, currently in a co-validation pilot with a neurology clinic and not clinically validated. Both assist a clinician — neither replaces one, and neither makes a clinical decision.
What adapts here is commercial and operational: which capability is enabled, on which devices, in which room. The clinical judgement stays where it was.
Where the roadmap comes from
Further modules are in development, and the honest answer to where they came from is: services asked.
That is only workable because a good idea for one institution does not have to become a change for every institution. The request that would be too specific for a monolithic product — too small, too particular, too much one team's way of working — is exactly the request a modular platform can say yes to.
If your service has one of those, we would rather hear it than not.
Have a request specific to your service?
Tell us how your team works and we will show what can be enabled — or built — for it.
Talk to the team