Bundling Hardware With Your XR Training Platform. What a Software Studio Should Settle Before Co-Branding a Headset.

That route is sound. The problem is the order in which most studios walk it. They start with the visible decisions, the logo, the colour, the box, and leave the structural ones until after a purchase order is signed. By then the structural decisions have already been made for them, by whichever device they happened to pick.

This paper sets out what a software studio should settle before it co-brands a headset, in the order that protects the training product it has already built.

Why the hardware decision comes before the announcement

A training platform is a promise about outcomes. The client is buying the assurance that a worker who completes the lockout module has practised the isolation sequence correctly. That promise depends on things the studio's code does not control: how accurately the device tracks hands, whether it holds a charge through a shift, whether IT can manage it remotely, and whether it will still receive updates three years from now.

Once the studio's name is on the device, every one of those becomes the studio's problem. A client who sees a studio logo on a headset that will not connect to the plant network does not call the hardware maker. They call the studio.

Typical pattern. A studio picks a capable consumer-derived headset for a pilot because it is available and familiar to the developers. The pilot succeeds. The client asks for two hundred units with the studio's branding. The studio then discovers that the device's management tools assume a consumer account per headset, that the firmware update schedule is set by someone else, and that the model is approaching the end of its production run. None of these were visible during the pilot because the pilot never needed them.

The lesson is not that the first device was wrong. It is that the questions that decide a fleet are different from the questions that decide a pilot, and they need answering before the brand goes on.

Co-brand, white label, ODM or OEM: what each one lets a studio control

"White label" is used loosely. In practice there are three or four engagement models, and they differ mainly in how deep the studio's control goes. QWR's existing paper on ODM vs OEM vs Co-Brand covers the full comparison. For a training studio the useful lens is narrower: which model protects the training product?

Co-brand or white label on an existing device. The studio changes the surface: logo, colour, packaging, boot screen, perhaps a preloaded launcher. The tracking system, the firmware branch, the data path and the product lifecycle stay with the device maker. This is the fastest route to a branded unit and the one with the least control. QWR's paper on what a brand actually controls in a co-brand deal goes into what typically sits outside the studio's reach.

ODM on a validated reference design. The studio starts from a platform that is already engineered and certified, then customises within defined limits: shell, materials, colour, software image, sometimes sensor options. Because the core is frozen, time to market is shorter than a ground-up build. At QWR this route is described as reaching market in three to six months on frozen reference designs.

OEM to the studio's own specification. The studio defines the product and the manufacturer builds it. This gives the most control and takes the longest. Few training studios need it, and those that do usually have a very specific form factor or environment in mind.

The deciding question for a studio is not "which is cheapest" but "which decisions do I need to own to keep my training promise?" If the modules depend on precise hand tracking, the studio needs a say in the tracking stack. If the clients are in regulated sectors that demand long support windows, the studio needs a say in the firmware roadmap. If neither applies, a co-brand arrangement may be enough.

What the studio must settle on the device side

These are the questions that turn a pilot device into a fleet device. Each one maps to a promise the studio is already making to clients.

Tracking, hand input and play space

Every module in the catalogue makes assumptions about the hardware. A work-at-height scenario assumes the trainee can walk and look down. A lockout sequence assumes the device can see the trainee's hands well enough to register a lock being applied. A classroom induction assumes neither.

Before choosing a device, map the catalogue against three questions. Does each module need positional tracking (six degrees of freedom) or only rotational (three)? Does it rely on controllers, hand tracking, or both? How much physical floor space does it assume? QWR's paper on 3DoF vs 6DoF explains why this is a procurement decision rather than a spec line. A studio that co-brands a device which cannot run a third of its catalogue has created a support problem it will pay for in every renewal conversation.

Fleet management, kiosk mode and identity

Enterprise training headsets are shared. One device may serve three shifts and thirty workers. That makes three capabilities non-negotiable:

• Remote management. IT teams expect to enrol, configure, update and wipe devices from their existing mobile device management tool, not from a vendor portal they have never heard of.
• Single-application lockdown. A trainee should land in the studio's launcher, not in a general-purpose home screen.
• Session identity. Each training record must attach to the right person, on a device that many people use.

QWR's paper on kiosk mode, secure boot and remote MDM covers what each of these mechanisms actually delivers. For the studio, the point is simpler: if the co-branded device cannot be managed the way the client's IT team already manages devices, the studio will be asked to fill the gap with people.

Firmware and update commitments

Firmware is where co-brand arrangements most often disappoint. The studio's modules are tested on a specific operating system build. When the device maker ships an update, the studio needs to know in advance, test against it, and decide when clients receive it.

Questions worth putting in writing before signing:

• Who decides when an update ships to devices carrying the studio's brand?
• Can updates be staged, tested and rolled back?
• How long will the device receive security and operating system updates?
• What happens to supply if the underlying platform reaches end of life?

QWR's papers on firmware and OS update commitments and on the cost of a three-year support contract without firmware control set out the full list. The short version for a studio: a three-year enterprise contract on a device whose firmware you do not control is a three-year exposure you have not priced.

The data path

Training clients increasingly want results in their learning management system, not in a separate dashboard. That means the device has to produce records, hold them when offline, and send them somewhere the client trusts. The companion paper in this batch, Getting Training Records Off the Headset, covers the standards involved. For the co-brand decision, the relevant question is whether the device and its operating system allow the studio to build that path without workarounds.

What the studio controls on the finished product

Studios often assume that putting their brand on a device means owning it. Ownership is usually narrower, and it is worth being exact about it before the first conversation with a manufacturer.

Intellectual property. Clarify who owns the finished product's design, the customised software image and any tooling created for the project. In an ODM arrangement the manufacturer typically retains the underlying platform IP while the brand owns its specific customisations. In an OEM build more can sit with the brand. Whatever the model, write it down. QWR's paper on what white label means once the NDA is signed covers how narrow that can be in practice.

Customisation boundaries. QWR uses a hard points and soft points framework. Hard points are the parts of the design that protect optical performance, thermal behaviour, certification and sensor accuracy; they do not move. Soft points give the brand freedom over geometry, materials and colour, material and finish. A studio should ask any manufacturer for the equivalent map before designing anything, because it decides what "custom" can actually mean.

Volumes. Ask how sample quantities, pilot quantities and production quantities differ, and what changes between them. A studio with fifty pilot units across five clients has different needs from one placing a single order of five hundred. The manufacturer's answer will shape whether a co-brand programme is viable at the studio's current scale.

Certification. A device sold into a market needs that market's marks. If the studio plans to sell in India, ask whether the platform already holds the relevant approvals or whether certification is part of the project. QWR's XR certification map sets out which marks apply where.

The commercial questions that sit underneath

Bundling hardware changes a studio's business, not just its product. Three questions are worth answering internally before talking to any manufacturer.

Who holds the inventory? If the studio buys devices and resells them, it carries stock, warranty exposure and cash tied up in hardware. Some studios prefer a model in which the client buys devices directly from the manufacturer under the studio's brand. Each choice has different margin and risk.

Who handles a dead unit? When a headset fails at a client site, the client will call the studio. Decide in advance whether the studio swaps the unit from its own spares, ships it back to the manufacturer, or routes the client to the manufacturer's support. QWR's paper on structuring warranty and RMA argues that time to restore matters more than length of coverage.

What happens at renewal? A three-year training contract may outlast the device generation it started on. Plan how clients move to the next device, and whether the studio's content will run on it without rework.

Typical pattern: what breaks when these questions stay open

The failures below are illustrative, not drawn from a specific deployment. They are labelled as typical patterns because they recur across the category.

The orphaned fleet. A studio co-brands a device that the maker later discontinues. Clients who bought in year one cannot buy matching units in year two. The studio ends up supporting two device generations with one content team.

The update surprise. A firmware update changes how the operating system handles background processes. A module that sent results reliably now drops them when the headset sleeps. The studio learns about it from a client's compliance team.

The management gap. The client's IT team cannot enrol the co-branded devices in its existing management tool. Devices are updated by hand, a few at a time. The studio sends an engineer on site to help, and the cost of that visit is not in any contract.

The tracking ceiling. A studio co-brands a rotational-tracking headset because it suited the induction modules that won the first contract. The second client wants confined-space and work-at-height training, which assume walking. The studio either builds a cut-down version of its own modules or recommends a different device, which undermines the reason for co-branding.

Each of these could have been prevented by a question asked before the logo went on.

A settlement checklist, in order

1. Map the catalogue to hardware requirements. Tracking, input and space for every module, current and planned.
2. Decide which decisions you must own. Tracking stack, firmware timing, data path, lifecycle. This tells you which engagement model you need.
3. Confirm fleet management. Remote enrolment, kiosk lockdown and session identity, working with the tools your clients already use.
4. Get firmware commitments in writing. Who ships updates, how they are staged and rolled back, and for how long.
5. Settle IP and customisation boundaries. What you own, what the manufacturer keeps, and what can and cannot change.
6. Agree volumes and certification scope. Sample, pilot and production quantities; which market marks are included.
7. Decide the commercial model. Inventory, warranty handling and the path to the next device generation.

Only then design the shell.

Where to go next

If your catalogue is mapped and you are ready to match it to a hardware platform, start with the Platform Finder or read how ODM engagements are structured.