Episode 3: Enterprise VR Development Tools? What Development Tools?

“Girl with the Pearl Earring” Johannes Vermeer © 2025 Rocinante Research, AI Generated

Once upon a time — okay, five years ago — Enterprise VR was this close to being the next big thing. Consultants, L&D, and Marketing couldn’t shut up about how it would revolutionize training, collaboration, and simulation. The future was so bright, you practically needed a headset to look at it.

And yet, here we are in 2025, and Enterprise VR has pretty much crawled back into the supply closet. What happened?

Previous episodes tackled whether Enterprise VR actually had value (spoiler: yes) and uncovered how hardware vendors managed to shoot themselves in the headset.

Episode 3 pokes fun at the underbelly of VR software development tools to determine if software is the true villain in our story. It is broken into four scenes, so you can ease into the pain that is Enterprise VR development:

• and most importantly, to ask why the question: Why is developing VR applications like building a spaceship with a spork?”
• Scene 1: A History Lesson on Enterprise Development Technologies A macro lesson on the tools and technologies enterprises use to build internal applications. IOW, the decoder ring to understand the phrase, “Just because you could build webpages and mobile apps does not make you a VR developer.”
• Scene 2: The Unity vs. Unreal debate Looks at the two biggest players in VR software development tools to understand why we obviously needed another tech holy war.
• Scene 3: Wait, how many people are on your VR team? How much is this application going to cost to build, test, deploy, and manage?
• Scene 4: The rise of no-code development platforms from the Duct Tape & Pray School (Because non-developers understand what it takes to build an enterprise application better than those neckbeards in IT).

Quick Summary for the TLDR crowd:

Enterprise VR was supposed to be the future — until it tripped over its own software stack. From the Unity vs. Unreal holy war to bloated dev teams, it was clear everyone was flying by the seat of their pants. And when IT finally got involved — things got worse. The only survivors were no-code tools and low-budget 360VR projects. TLDR: software probably wasn’t the villain, but it was definitely driving the getaway car.

Scene 1: A History Lesson on Enterprise Development Technologies:

Or how we went from white lab coats to XXXL pizza-stained T-shirts — without somehow burning the whole place down.

“IT Sitting in on a VR Code Review” © 2025 Rocinante Research, AI Generated

Enterprise software development isn’t just a story — it’s an epic saga of human stubbornness, bad decisions, and heroic efforts to glue the future onto the past.

You can neatly categorize it into eras, much like archaeologists do with ancient civilizations — except instead of human burial remains and pottery shards, we’ve got Lotus Notes servers, Fortran, punch cards, and passive-aggressive Jira tickets. Oh, and that suspicious smell coming from the data center break room.

Each era had its own holy relics (technology), priesthoods (developers), and rituals (SDLC, RAD, JAD, IE, and the ultimate square peg in round hole — Six Sigma). Each era also came with its own tech stack, quirks, and corporate trauma. Understanding these eras is key because IT developers tend to get trapped — skill-wise and emotionally — in whatever era they started their career in. So yes, it is possible to carbon-date a developer by just listening to the buzzwords they still use unironically.

Now, if you’ve never had the joy (or horror) of peeking behind the curtain of a large enterprise IT shop, brace yourself: it’s not so much a “department” as it is a migrating herd of complexity, stitched together by thirty years of “temporary” solutions that somehow became permanent. Calling it “organized chaos” would be generous — imagine a piñata filled with bees, placed on a trampoline, being struck repeatably by a stick built with COBOL and hope.

And that’s just the software development side. If we added operations, support, architecture, project management, or product management to the discussion, we’d need to hire a grief counselor and maybe an exorcist.

As a consultant of more than 30 years, I can promise you entire industries have been built around helping companies survive their own IT departments.

Table 1: “Enterprise Software Development Eras (Partial)” © 2025 Rocinante Research

If you didn’t grok the table above, VR software development begins occurring around the exit of the Mobile & API-Driven Era so let’s pause and double-click into developer skills as this is where Enterprise VR tools like Unity and Unreal enters the picture in 2016.

Developers entering the workforce in and around 2016 cut their teeth on Mobile Apps, APIs Java, .NET, C#, and HTML. No Fortran, COBOL, Lisp, or SmallTalk for YOU!

This is important but keep it in your back pocket for now. Now back to our regular programming.

Scene 2: The Unity vs. Unreal debate

“Agile is my safe word” © 2025 Rocinante Research, AI Generated

Before developing enterprise VR applications and after you’ve selected your target headset, the next critical decision is choosing a development platform.

Back in 2016, there were a handful of options; Unity, Unreal Engine, 360VR/WebVR, and Proprietary Engines. Each required a firm commitment, as switching platforms later often meant a significant code rewrite. Compatibility with your chosen headset was also essential, as not all platforms supported every device. Proprietary Engines were mostly for defense contractors focused on simulation. For the purposes of our discussion, we are only focusing on the following 3:

• Unity, a Danish company based out of San Francisco, is a powerful cross-platform game engine and development platform widely used for creating mobile phone and VR (Virtual Reality) interactive experiences and applications. Unity uses C# for scripting and provides a rich asset store, physics engine, and rendering tools to streamline VR development. Unity is licensed by developer seat.
• Unreal Engine, owned by Epic Games, is a high-performance development platform used for creating advanced VR experiences and applications (and just about every AAA computer game ever published). Known for its stunning graphics and realistic physics, is based on C++ for development. It’s widely used in gaming, simulation, and architectural visualization. Unreal is licensed using a shared revenue model (EX 5% of total sales) as it was really used to create commercial applications.
• 360VR/WebXR development tools are used to create immersive 360-degree virtual reality experiences, typically for non-interactive or lightly interactive content such as training videos or virtual tours. These platforms often serve as a steppingstone for companies new to VR, offering an accessible entry point but with limited interactivity and scalability.

Sure, there were other ways to build VR apps — but most enterprises just handed the whole thing off to consultants or creative agencies. Why?

Because convincing IT to retool a backend dev to build a one-off VR proof-of-concept was like asking your dad to install TikTok — confusing, mildly dangerous, and ending in a shouting match about why he needs a brand deal to support his “Back-in-my-Day” coaching business.

And let’s not forget: VR made marketing departments giddy. It was shiny, it moved, and it looked great on a tradeshow reel, so they were more than happy to skip the IT gauntlet and throw it over to their favorite flashy ad agency. Farming it out was faster, prettier, and didn’t involve begging IT for server access. (remember this point for future episodes).

It’s important to note that consulting companies tended to gravitate towards Unity (similar coding tools and licensing model to traditional IT efforts) and Creative houses gravitated towards Unreal Engine (because you know… Pretty!).

Table 2: Comparing Unity to Unreal

What determined the development platform? Easy: whatever the dev team already knew.

If they cut their teeth on mobile apps or .NET, they spoke fluent C# and naturally gravitated toward Unity. If they had a background in game engines — or just liked rendering bananas in ultra-HD — Unreal was home. In the world of Enterprise VR — Unity was far more common for a majority of builds because the dev team had experience with the core technology (C#) and the license model was more predictable.

In nearly every case, the enterprise ended up footing the bill to upskill third-party vendors on these shiny new tools. Why? Because very few people had ever actually built a VR app before. And if you were building a simulation? Forget a quick 6-week turn and burn — you were staring down man-years of work. By 2019, the average VR project took 12 -18 months and cost somewhere between $500K and $2M. (Yes, cheaper options like 360VR/WebXR existed, but we’ll get to the bargain bin later.)

And because everything was so new, Unity and Unreal didn’t exactly play nice. You couldn’t just build in Unreal and then switch to the Unity (or vice versa). Choosing a platform meant locking yourself in. If you changed your mind? You were basically starting from scratch.

So naturally, each enterprise picked a single platform, standardized their toolset, and created a consistent experience across all VR apps… right?

Of course not.

IT wasn’t involved. The business side made decisions based on budgets, buzzwords, or which vendor had the flashiest pitch deck, the lowest cost, and most attractive sales rep. The result? If you built three apps, they were probably developed three different ways by three different vendors — with completely unrelated user experiences.

Using these apps back-to-back felt like jumping between a flight simulator, a cooking show, and “Asteroids”.

Eventually, IT caught wind of the chaos and said, “You know what? We should build this in-house and do it right.”

And then…everything got worse.

Scene 3: Wait, how many people are on your VR team?

“What You Got vs. What You Need” © 2025 Rocinante Research, AI Generated

You have a few VR prototypes under your belt and leadership is very excited at what they have seen and want to see more. Your boss is putting pressure on you to stop outsourcing development and asks you “what it would take to bring VR development in house.” Excited, you put together a list of what you need:

The Enterprise VR Development Dream Team:

1. Production Lead: The person in charge of herding the cats, holding the budget hostage, and pretending everything is on schedule (it isn’t).
2. Project Manager: Lives in spreadsheets, breathes Gantt charts, and exists solely to ask, “Can we get an update on that?” every 14 minutes.
3. Learning Lead: Makes sure this isn’t just “cool tech” but also, you know… actually teaches someone something. Wild concept.
4. Creative Lead: Wears glasses with no lenses, says things like “aesthetic narrative arc,” and fights everyone over color palettes.
5. Technical/Development Lead: Writes 100 lines of code and 300 lines of Slack messages explaining why the last update broke everything.
6. Interactive Learning Lead: Translates corporate training into VR magic — turns “don’t touch that” into a virtual fireball experience.
7. Script Writer: Crafts dialogue for training avatars that somehow need to be professional, relatable, and not sound like a lawyer.
8. Story Board Designer: Draws glorified comic books to help executives pretend they understand what this project is about.
9. Game Engine & Platform Developer: The sorcerer behind the curtain who makes the headset do things, occasionally sacrificing a weekend (and a goat or two to the Unity community).
10. 3D Modeling & Asset Creator: Builds realistic office chairs, plants, forklifts, and brings awkward avatars to life in glorious low-poly detail.
11. Animation & Motion Capture Creator: Wants to mocap everything — including the intern sneezing — because, you know… “authenticity.”
12. Physics & Interaction Designer: Makes sure things don’t float, fall through floors, or accidentally slap you in the face with virtual objects while moving from Point A to Point B. Usually.
13. Audio & Spatial Sound Designer: Makes a PowerPoint about the emotional arc of a door creak. Wears headphones all the time and silently judges you.
14. User Experience Engineer: Screams into the void when Creative Lead says “just make it intuitive” for the 12th time.
15. Production Artist: The last-minute miracle worker who fixes every asset, graphic, and UI element after everyone else has signed off.
16. Deployment, Testing & Performance Optimization Engineer: The person responsible for making sure the app doesn’t melt the headset or crash when someone blinks too hard.

With excitement, you begin to put together your budget and staffing request. As you go through it you begin to realize that unless you are building 3+ VR experiences in parallel, many of these roles are not needed 100% of the time so it may be necessary to find people that can wear multiple hats and skillsets — or just backfill specific spots with a contractor. Time to reach out to IT to help understand what you’ll need and maybe over to marketing where are the creative people are hiding.

“What I discovered is that many of these skills are not normally found in an enterprise, so our team was a collection of contractors, creatives, trainers, developers, and executives. The biggest problem I had was creating and deploying these types of solutions involved having people that didn’t normally work together — work together.” — Immersive Experiences Lead F500 Company.

The next thing you know is your boss called you into their office — and HR has joined him. Oh shit. Time to get on your bicycle and start pedaling.

“What happened? What went wrong? Well, everything. Underestimating the time it took, realizing that legal and/or HR needed to be involved in everything to do with the script, learning objectives, and outcomes, underestimating the budget, managing the scope, managing the different personalities and egos, and delivering a solution that resembles the initial vision. Do you know it took 6-months just to finalize the script as we spent most of our time trying to convince HR and Legal that NO ONE talks like that in real life. We were 7-figures and 8 months over budget.” — VR Project Leader F200 Company.

ROCINANTE: Rarely, in more than 8-years building interactive solutions for clients had I run across a single company that built their own interactive solutions in-house more than once or twice. They looked at the bills, the timelines, the interdepartmental trauma — they just noped out. Building your own sounded cool but ended many a career.

The exception? Companies that went down the 360VR route and discovered no-code solutions. And defense contractors who don’t really think about budget unless you are exceeding $50M for the project (and those that think $1M is a rounding error).

Scene 4: The rise of no-code development platforms

No-code VR development platforms allow users to create virtual reality experiences without writing code. These tools offer visual interfaces, drag-and-drop functionality, templates, and built-in logic systems — empowering non-developers like designers, educators, and subject matter experts to build VR content for training, education, and storytelling.

It’s like building Ikea furniture… if Ikea made forklifts.

“Pre-historic No-Code Approach” © 2025 Rocinante Research, AI Generated

No-Code VR Development Tools

Advantages:

• Fast Prototyping — Build and iterate quickly without needing a developer or deep technical skills.
• Lower Cost — Reduces reliance on expensive engineering teams for MVPs or basic training scenarios.
• Accessibility — Empowers trainers, educators, and designers to directly create content.
• Prebuilt Components — Often includes templates for menus, environments, and interactions.
• Cross-Platform Deployment — Some tools allow exporting to web, mobile, and multiple VR headsets with minimal setup.

Disadvantages

• Limited Customization — Difficult or impossible to implement advanced features, AI, or custom logic without learning how to play “Twister.”
• Performance Bottlenecks — May not be optimized for complex enterprise-scale VR applications.
• Scalability Issues — Less suited for large-scale, multi-user simulations or photorealistic environments.
• Vendor Lock-in — You’re tied to the features, limitations, and pricing of the no-code platform.
• Limited Source Code Access — Cannot modify the underlying engine or integrate custom SDKs easily.
• Custom enterprise integrations (e.g., AI, IoT)
• Large-scale multiplayer simulations
• Training that requires fine hand motor skills

“No-Code solutions shine in industries where there is high turnover, and you need to teach an unskilled worker to perform simple physical tasks. It’s a lot more exciting than sitting through an e-learn, and they don’t start anything on fire. There are a few companies where I have heard there are more than 400+ 360VR training experiences — all built in house.” — G2000 Learning Lead

Conclusion: Did Software Kill Enterprise VR?

The enterprise software development landscape was already a hot mess of tech debt, tool sprawl, and skill silos. Then someone tossed in VR — an exotic new ingredient with zero recipe cards.

No standard platforms. No reusable assets. No playbook.The tools were fragmented, the platforms incompatible, and the skillsets required looked like a requirements doc for the next Avatar movie.

And yet… for all the burned budgets and abandoned headsets, there was a spark.

“Somewhere in the ruins, the no-code tools and Unity or Unreal prototypes showed us that maybe — just maybe — this could work for the right problems, with the right people, using the right expectations. A simple 360VR training didn’t need 16 roles and a mocap rig. It needed someone who knew the job and someone who could drag-and-drop with a bit of style. No-Code doesn’t address simulation, collaboration, or some of the more comprehensive types of multi-user training scenarios, but it helps keep the foot in the door.” — G2000 Learning Scientist

In the end, building VR software at scale was like throwing a surprise birthday party in a minefield: expensive, confusing, and liable to blow up your career if you stepped in the wrong place.

Was software the villain in this story? Not completely. Let’s call it an accomplice. Along with unclear business goals, undercooked budgets, wildly misaligned teams, and a tech industry that promised a holodeck and delivered us MESH.

What happened to all those execs who pushed seven-figure VR projects? Oh, they’re leading AI strategy now. Naturally.

We’ve identified both Hardware and Software as contributing factors to the failure of Enterprise VR. But they are not the only culprits. Up next in “Episode 4: The IT Problem, or How the middle finger can be used as a pointing device” we dive deeper into the maelstrom of dealing with IT to deploy VR solutions in the enterprise.

Published May 8, 2025

=-=-=-=-=-=-=-=-=-=-=-=-=-=

If you liked this article, smash that share button like you’re flailing through a Beat Saber solo on Expert+ after three espressos. Got thoughts? Cast them into the comments like a cursed spell — I accept praise, hot takes, unsolicited philosophical rants about Ready Player One, and your most unhinged theories about how an AVP is secretly Skynet in a ski mask. If you hated it, just shout “Spatial computing is just iPadOS for your face!” into your next VRChat session and remember it could be worse… you could be staring into the black mirror of a Meta Quest Pro wondering if you ever actually left that team-building simulation in 2019. (You didn’t. You’re still in there. The facilitator just never logged back in.)

About the Author

Daniel Eckert retired from 29-years of consulting in late 2023 after spending 8-years on the front lines of Enterprise VR, preventing big companies from overhyping, under-investing, or half-baking VR solutions. He also co-authored the landmark paper The Effectiveness of Virtual Reality Soft Skills Training in the Enterprise — a paper cited half as often as any VR pitch deck containing the words “immersive synergy pipeline.” Daniel now spends his semi-retirement as a Principal at Rocinante Research. (Yes, the name is a Don Quixote reference. Yes, it’s ironic yes, and yes, he still wears the armor. Check out some of his other articles on Medium.

Articles in the “WHY ENTERPRISE VR FAILED” series:

• Why Enterprise VR Failed — The Prologue (April 1, 2025)
• Episode 1 — Overpromising and underdelivering? The Benefits of Enterprise VR. (April 8, 2025)
• Episode 2: Strapped-in and Let Down: How Enterprise VR Got Duped by Consumer Tech April 22, 2025)
• Episode 3: Enterprise VR Software Tools? What development tools? (May 8, 2025)
• Episode 4: The IT Problem, or How the middle finger can be used as a pointing device (July 18, 2025)
• Episode 5: Corporate Learning and Development: Where good ideas and dreams go to die. (September 2025)
• Episode 6: User Experience: “You want me to wear this clunky thing on my head for HOW long?” (Q3 2025)
• Episode 7: VR/Spatial Consultancies: The rise and fall of the Metaverse Industrial Complex (Q4 2025)
• Why Enterprise VR Failed — The Epilogue, or WTF can I do now to turn this all around? (Q4 2025)