For experiences judged on comfort as much as on visuals
AR/VR Development
An immersive experience fails quietly, at the point someone takes the headset off feeling unwell, or an overlay lags a frame behind reality. This practice treats comfort and frame rate as engineering requirements from the first prototype, whether the target is a training headset, a consumer AR feature, or several platforms at once.
How comfort gets engineered into an immersive build
Frame rate, spatial tracking and the testing that catches motion sickness early.
90 secSample frame · video pending01Before choosing a rendering approach
Native headset SDK or WebXR is a real decision.
The choice shapes reach, performance headroom and maintenance cost for years. Four questions settle it against your actual audience.
Does the audience already own a specific headset?
A known, standardised headset fleet earns the performance headroom of a native SDK. An unknown or mixed audience favours WebXR's reach.
How demanding is the rendering workload?
Dense environments and complex interaction push toward native rendering. Simpler overlays run comfortably inside a browser.
How often will the experience need updating?
WebXR updates instantly for every user. Native builds require a distribution step, which matters for content that changes often.
What does your team already operate?
A team with existing native mobile skills extends more naturally into headset SDKs than into browser-based rendering pipelines.
| Native SDK | WebXR | |
|---|---|---|
| Performance headroom | Higher, hardware-tuned | Constrained by the browser |
| Reach | Tied to one headset or family | Any capable browser and device |
| Update distribution | Requires a release step | Instant for every user |
| Best fit | Known, demanding hardware target | Broad or unknown audience |
02Agreed before the first prototype
The ledger that keeps an immersive build honest
Immersive projects go wrong when comfort gets treated as a late-stage polish pass instead of a design constraint from day one. This ledger spells out what you bring, what we build, what returns, and what stays yours.
- Your side
You bring
- The procedure or scenario to be simulated
- Access to subject matter experts who run it today
- The headset hardware already standardised on, if any
- Our side
We build
- Spatial interaction design matched to the real procedure
- Rendering tuned to hold frame rate under headset constraints
- Comfort design that avoids motion sickness during long sessions
- Your side
You receive
- A working simulation deployed to your headset fleet
- Comfort testing evidence across a range of real users
- A build your team can extend with new scenarios
Never leaves you
- The training curriculum and certification standards behind it
- The headset fleet and its rollout to trainees
- The decision on which scenarios to simulate next
Where the line sitsFrame rate and comfort are not polish here, they decide whether trainees can use the thing at all. We treat both as requirements, not nice-to-haves.
03From concept to a comfortable build
Four stages, each closing on evidence
Immersive builds that make people uncomfortable usually skipped a stage here. This system closes each one with something tested on a real headset, not a screen recording.
Set the performance budget first
A target frame rate is fixed before design begins, because everything downstream, from asset density to interaction design, has to fit inside it.
A frame-rate budget set earlyDesign spatial interaction around real input
Hand tracking, controllers and gaze are designed against how your actual hardware behaves, not how the reference documentation describes it.
Interaction that matches the hardwareTune assets before they slow anything down
Every model and texture is tuned for real-time rendering as it is built, rather than fixed later once performance already suffers.
Assets built for real-time renderingTest comfort with real users, not the team
Motion sickness and fatigue are tested with people outside the build team, because the people who built it stop noticing what is uncomfortable.
Comfort tested on real people
04What actually moves the number
Four drivers, priced from the target hardware
Immersive work is priced against the target hardware and platform count, because these four factors change scope by multiples.
Number of target platforms
A single headset target costs less than a build that must also run acceptably on web and mobile.
Environment and asset complexity
A dense, detailed environment costs more to prepare for real-time rendering than a simple, focused scene.
Depth of spatial interaction required
Hand tracking and object manipulation cost more to get right than a fixed-viewpoint experience with simple controller input.
Comfort testing scope
Testing across a wide range of real users for motion sickness adds time that a narrow, controlled audience does not require.
05Evidence and proof
Experiences people could actually stay inside.
AR/VR proof is comfort testing that passed and frame rate that held under real content. Every record here waits for written client approval before production.
Explore case studiesA safety procedure trained in a headset instead of on live equipment.
Nexa Foundry needed new operators trained on a hazardous procedure without risking real equipment. A VR simulation held frame rate under load and passed comfort testing across every trainee.
- Trainees reporting discomfort
- Zero across pilot
- Live equipment risk during training
- Removed
An AR try-before-you-buy feature shipped inside an existing shopping app.
Aster North wanted customers to preview products in their own space before ordering. An AR overlay tuned for phone rendering shipped inside the existing app without a separate install.
- Separate app required
- None
- Asset load time
- Under two seconds
Nobody on our training floor complained of feeling sick, which our first prototype from another vendor could not say.
Sample · pending client approval
06Read this first
When AR or VR is the wrong answer
Building an immersive experience for something a flat screen already serves well spends budget on complexity nobody needed. The exits are marked plainly, and where AR or VR is justified it runs on Unity, WebXR and the major headset SDKs.
- Application development
A 2D interface would communicate the idea fine
If depth or spatial presence adds nothing to the actual task, a standard application serves the need more cheaply.
- Product discovery
The concept has not been validated with real users yet
Immersive builds are expensive to redo. Validating the core idea first keeps the eventual build honest about what people actually want.
- Team extension
You need immersive engineers, not a delivery layer
If your team already owns the creative direction and needs capacity, team extension fits better than a commissioned build.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | The target hardware and scope are known | Content and priorities | Rendering, interaction and delivery |
| Delivery pod | The experience will evolve with pilot feedback | Product decisions each cycle | Engineering and comfort testing |
| Team extension | Your studio owns creative direction | Creative and technical standards | Named engineers and continuity |
07Straight answers
Asked before an immersive build is scoped.
01Do you build for VR headsets, AR, or both?
Both, matched to your actual use case. Training and simulation usually favour VR headsets, while product previews and overlays usually favour AR inside an existing app.
02How do you prevent motion sickness in a VR build?
Through frame-rate budgets fixed before design starts, movement patterns chosen to avoid known triggers, and comfort testing with real users outside the build team.
03Can you build a WebXR experience that needs no app install?
Yes, WebXR is often the right choice for a broad or unknown audience. The trade-off against a native headset SDK is explained plainly during scoping.
04What if we already have 3D assets from another project?
They can usually be reused, though real-time rendering often requires performance tuning that offline rendering never needed. An early asset audit tells you how much work that is.
05What does AR/VR development cost?
Priced against target platform count, environment complexity and comfort-testing scope from the assessment. A single headset target costs less than a build spanning headset, web and mobile.
06Do you handle hand tracking and controller input?
Yes, spatial interaction is designed around whatever input your hardware actually supports, from hand tracking to standard controllers, tested against real behaviour rather than documentation.
07Is our idea a good fit for AR or VR at all?
Not always, and we say so plainly. When a standard screen would communicate the idea just as well, that is the honest and cheaper answer.
08Do you validate the concept before building the full experience?
Where the idea is unproven, yes. A short discovery pass before a full immersive build keeps the eventual spend honest about what users actually want.