RDV Systems
“The productivity we had before was borrowed. It belonged to one person. The productivity we have now belongs to the whole team.”
Please introduce your company - what does a typical project workflow look like?
We have two main vectors. The first is 3D modeling and visualization of infrastructure and development projects: roads, interchanges, industrial facilities, urban developments. Sometimes it's purely for presenting a future development to a client or the public, sometimes it's to help stakeholders understand how a project will unfold in phases. Sometimes it also feeds into road safety and insurance compliance analysis: does this road or interchange actually meet the required standards?
The second vector focuses specifically on roads, either future designs or existing infrastructure, where we work with point cloud data, typically LiDAR scans, and run analysis on them.
Clients come to us with requirements: PDFs, high-resolution aerial imagery, 2D or 3D sketches. The existing state is our starting point, the ground truth we anchor everything to, and what we actually build on top of it is the future development they're planning. The initial modeling is done primarily in AutoCAD, which we know inside and out, and sometimes in MicroStation. In the US, which is our market, that's what more than 90% of firms use. From there, everything runs through our own proprietary pipeline into Unreal Engine, and the final deliverable is a cloud-based interactive platform with video recording, virtual tours, and live layer controls: weather, dates, animations.
.webp)
How did you manage files and versions before Diversion? Was something not working?
Two separate systems. The dev team was on Git and AWS CodeCommit, mostly by legacy. The modeling team had no concept of version control whatsoever. They had a shared drive with folders named V1, V3, V_final, "Don't Delete." That was their system, and they were perfectly happy with it. When I joined and told them this isn't how you work, they pushed back: "No, no, this works great for us, what's your problem?"
The honest answer is that it did work, but only because we had an exceptionally strong team lead who held the whole thing together through sheer personal discipline. It was genuinely effective, but that's exactly the problem. When she relocated and left, her replacement would have struggled to naturally navigate her manual system. He came in already on Diversion, so it wasn't an issue. But if he had inherited the old workflow, it would have been. The way I see it, the old system was a house of cards that someone happened to miraculously keep in the air. You can't build a company that way.
"The productivity we had before was borrowed. It belonged to one person. The productivity we have now belongs to the whole team."
Has Diversion affected collaboration between teams from different disciplines?
When we were still actively developing our legacy engine, the dev team and modeling team had to interact more. But once development on the legacy engine slowed down, the two teams became largely disconnected. Now with Diversion, both teams share a common language and common access to resources. If someone from development needs to pull a project, they just pull it. No asking around, and everyone is working from the same source of truth.
What was the moment you realized you needed a better version control solution?
For me it was obvious right when I first joined and saw the old workflow. The team saw it when we moved to Unreal Engine, that was their clear moment: legacy is legacy, let's turn a new page and do it right. That's when we brought in Diversion.
Why did you choose Diversion over other options?
We looked at Perforce, Git-based solutions, and Diversion. For Git, it wasn't even a consideration for the modeling team. I don't want to complicate their lives with commands and technical overhead. It has to be embedded inside the Unreal Editor, and for that you really only have two options: Perforce and Diversion. We went through the full setup with both: connected Perforce to S3, ran the whole evaluation alongside Diversion. In the end, Diversion was simpler, easier to manage, and gave us easy control over our storage with basically a button click instead of needing someone to manage it. Price was also a factor, and Diversion came in cheaper.
What was the Diversion onboarding like? Especially for non-technical team members.
It was seamless. These are people who had no idea what version control even was. When I explained branching to them, the first reaction was "what does that even mean?" But then they connected inside the Unreal Editor, saw the Desktop App, and it just clicked. Download a project: click. Sync: click. No commands, no technical knowledge required. They understood: this is how you work, it's easy, it's not scary, and they just started using it properly. What could have been a very painful change management challenge simply didn't happen, because the interface removed all the friction before it could become a problem. Today the whole modeling team is 99% self-sufficient. They occasionally ping the dev team when something unusual comes up, but for the vast majority of cases, they handle it themselves.
Which Diversion features are most valuable for your workflow?
Without question, the Unreal Engine integration. Without it embedded directly inside the Editor, the modeling team simply wouldn't have adopted it. Full stop. Beyond that, the pace of version releases is something I really appreciate. Diversion keeps up with new Unreal Engine versions quickly, and for us that matters enormously. We depend on engine updates for bug fixes and new capabilities, and not having to wait around for plugin support to catch up is a real competitive advantage. The Desktop App is clean and functional, does exactly what it needs to do.
"The old system was a house of cards someone happened to miraculously keep in the air. You can't build a company that way."
.webp)
Has Diversion changed the way your team works day-to-day? Did it have an impact on productivity?
The biggest day-to-day change is transparency. Before, only certain people knew which folder was current, who had the latest version, which drive had what. Now anyone, whether dev team or modeling team, can just pull the project they need without asking anyone. There's a shared language between two teams that previously had completely separate workflows. And there are no more question marks: "Was this the latest version? Did you take V6 when V8 was already out?" None of that. You don't need to know, and you don't want to know.
The productivity impact runs deeper than convenience. The way I think about it: the productivity we had before was borrowed. It belonged to one person, and when she left, it would have walked out the door with her. The productivity we have now belongs to the whole team. It's structural, not dependent on any single person keeping the whole picture in their head. That's not a marginal improvement. It's a different way of operating entirely.
"Without the Unreal Engine integration embedded directly inside the Editor, the modeling team simply wouldn't have adopted it. Full stop."
What would you tell other companies still using manual folders, Git, Drive, or Dropbox?
Game changer. It synchronizes the entire team in a very convenient and easy way. It gives you proper version control the way the software industry has been doing it for 30–40 years. It's absolutely a leap forward in project management, no doubt about it. And even if you think your current system is working (ours also "worked," with the right person managing it), it changes the entire team's approach. Two teams, a shared language, common access, no confusion about versions. That synchronization is critical, and version control done right is what makes it possible.
