Enterprise XR Can Learn from Custom Software Development

An Expert Interview with Florian Haspinger, Founder & Managing Director of Hololight

Hololight is the Industry’s Leading XR Streaming Infrastructure for Enterprise

At Keyhole Software, we work with technology leaders on custom software development, cloud modernization, DevOps, and enterprise architecture decisions that turn ambitious ideas into production-ready systems. One pattern we see repeatedly across emerging technology categories is the gap between a compelling proof of concept and a deployment that actually holds up in the real world.

Today, we’re sitting down with Florian Haspinger, Founder & Managing Director of Hololight, the industry’s leading XR streaming infrastructure for enterprise. Florian works with organizations across defense, automotive, and manufacturing on taking extended reality from pilot stage to production scale. We asked him what enterprise XR initiatives can learn from the discipline that custom software development teams bring to complex deployments.

Q: Florian, why do so many enterprise XR initiatives stall after the proof of concept stage?

A: Because the proof of concept was designed to demonstrate visual impact rather than production viability. A compelling XR demo is not difficult to build. You take a capable headset, render a well-designed experience in a controlled environment, and the room is impressed. What that demo does not reveal is whether the infrastructure can support concurrent users across a distributed workforce, whether the experience performs under real network conditions, how the system integrates with existing enterprise data sources, or what the security posture looks like when sensitive operational data is involved. When organizations move from that demo environment into production planning and encounter those questions for the first time, the gap between what they built and what they actually need becomes very clear very quickly. The pilot was never designed to answer the right questions.

Q: What should enterprise technology leaders scope into a pilot from the beginning to set a realistic path to production?

A: Three things that most pilots skip entirely. First, infrastructure requirements. Where is the rendering happening, on a local device, a cloud server, or an on-premise system, and does that match the deployment environment the production system will actually operate in? For organizations in defense or regulated manufacturing where data cannot leave a secured network, air-gapped deployment is not an optional consideration to revisit later. It has to be scoped from day one.

Second, integration points. What enterprise systems does the XR experience need to connect to, ERP, asset management, documentation platforms, and what does that data pipeline actually look like in a live environment?

Third, user workflow validation. Is the XR experience being tested by the actual end users in their actual work context, or by a project team in a conference room? Those are very different tests with very different results.

Q: How does XR infrastructure planning differ from traditional enterprise software infrastructure planning?

A: The rendering demands are fundamentally different. High-fidelity XR experiences require significant compute power, and where that compute lives determines almost everything else about the deployment architecture. Hololight’s streaming architecture, a proprietary pixel-streaming stack purpose-built for cloud, on-premise, and air-gapped deployment across defense, automotive, and manufacturing, was designed specifically to solve this problem at the infrastructure layer. Rather than requiring each endpoint device to carry the rendering burden, the heavy compute stays on a server, and only the rendered pixels are streamed to a lightweight client device. The infrastructure decision shapes every downstream choice around performance, security, scalability, and cost.

Keyhole Perspective: This is the same architectural principle behind thin clients, server-side rendering, and cloud-native design generally, applied to spatial computing. Wherever the heavy processing lives determines the tradeoffs around latency, security, and scale long before a single feature gets built, which is a question worth asking of any emerging technology category, not just XR.

Q: User adoption is where many enterprise technology initiatives, XR included, underperform. What drives adoption in production XR deployments?

A: The same thing that drives adoption in any enterprise software deployment: the system has to reduce friction in a workflow the user already cares about, and it has to do so reliably. XR fails on adoption when it is bolted onto a workflow as an additional step rather than embedded as a genuine improvement.

A maintenance technician who can access equipment documentation and repair guidance hands-free, in their field of view, while working on the asset, is experiencing a real reduction in friction. A technician who has to put down their tools, remove a headset, re-enter a system, and then resume work is not. The workflow analysis has to precede the technology decision, not follow it.

Keyhole Perspective: Workflow-first design pays off well beyond XR. Any new technology risks becoming an extra step bolted onto an existing process rather than a genuine improvement to it. Teams that get adoption right are usually the ones who map the workflow before they touch the technology, not after.

Q: How should technology leaders measure whether an XR deployment is delivering business value, and at what stage should those metrics be defined?

A: Before the pilot begins, not after it concludes. If your success criteria are defined after you have seen what the pilot produced, you are rationalizing rather than measuring. The business value metrics for an XR deployment should map directly to the operational problem being solved: reduction in time-to-task completion, decrease in training errors, improvement in inspection accuracy, reduction in downtime on a production line. Those are measurable, baselineable outcomes. Define them before the pilot, build the pilot to test them, and evaluate the production case against actual data rather than impressions.

Defined Requirements Beat Impressive Demos

Across each of these questions, the same pattern shows up. XR initiatives succeed or stall based on decisions made well before anyone puts on a headset. Infrastructure requirements, integration points, workflow validation, and success metrics all have to be defined at the start, not discovered along the way.

That is not a lesson specific to extended reality. It is the same discipline Keyhole applies to any custom software or modernization engagement: defined requirements, testable outcomes, and integration planning determine whether a promising proof of concept becomes a system an organization can actually run in production.

To learn more about Hololight’s enterprise XR streaming infrastructure and deployment solutions, visit hololight.com.