VRROOM: Lessons learnt building a VR social platform that arrived at the top place on a VR store

It’s exactly one year since we launched the Alpha of the VRROOM platform, the social XR space dedicated to concerts and life shows. We started this project from scratch in July 2022, and in this one year and a half, we have built a lot and obtained remarkable results: we collaborated with important artists like Armani White and Jean-Michel Jarre, won some awards, and one day we even reached the top place of the Pico Store.

This project has been the biggest one I’ve ever worked on, and since my role is the CTO, I have been to follow its evolution from the driver’s seat. I’ve learned a lot this year and a half working on VRROOM, so I feel the need to tell you about the story of our project and the important lessons that I’ve learned along the road. There is so much to say that I could probably write a book about it, but for today I will just put the most important takeaways in a very long article (let’s say a small book). I think it could be interesting for you to see what happens behind the curtains when a “metaverse platform” is being built, and also to learn some lessons in case you want to start a similar project by yourself.

Let’s start from the real beginning…

Should you really build a platform?

Whenever someone proposes you to build a social VR platform, something like VRChat, the first thing you should do is ask yourself if you really need to build it. The answer, in most of the cases, is no. There are already some wonderful platforms that allow you to build user-generated content, and in most cases, you can rely on what is already out there. 

For instance, if you want to build a social VR place, probably you can do that in VRChat. For a workshop, ENGAGE can give you everything you need. For a little multiplayer game for Gen-Z, you can try Roblox. And so on. These platforms already do all the heavy lifting for you (networking, avateering, account management, etc…), and you can just focus on building the experience, saving a lot of time and money. Furthermore, these platforms already have an audience, so you need to make less effort in trying to attract users.

This is not just something I’m telling you, but it is also what I’ve advocated for three years inside VRROOM whenever people asked me if we should have built our platform instead of using external ones. My answer has always been “No”, because I knew building a proprietary platform would have been very expensive and complicated. We have built great experiences on top of VRChat, which is an amazing platform, has a lot of daily users, and has good building tools, so we could just happily rely on it. For three years, we went on creating content on VRChat, but also The Sandbox, Roblox, ENGAGE, and other similar solutions. 

Then why did we decide to try to build our own product? And when should you make a similar decision? Well, I think there are a few stars that have to align:

• You have a clear use case not well covered by the other platforms: If to do your content, you have to shoehorn it every time to the rules of the other platforms, with results that leave you somewhat unsatisfied, then probably you should create your own platform. In our case, doing concerts, we absolutely needed features like ticketing, which were not available on most of the other VR platforms
• You have the money to build it: as a rule of thumb, if you can not get at least $1M, do not even try to build your platform. A platform with user-generated content is a mammoth project, and you need a lot of money to build it and market it. We could start this journey because we had an established experience-building business, plus we finally got access to various grants to build our vision
• You have the foundations of the team to build it: be sure to have a team of experts that know how to build this new platform, or that at least can learn very fast. In our case, we have been doing successful VR concerts (including epic events like the one in Notre Dame with 75M views) for three years, so we knew what we were doing.

Since these conditions were fulfilled, in 2022, we all agreed that we should have tried to build our platform. Regarding the last condition I listed, I was not sure I was the right person to be the CTO of such a massive project, but I like challenges, so I thought “Ok, fuck it, let’s make this happen” and the project was kickstarted.

Brace yourself

Before embarking on building your platform, be prepared that this will be a very long and complicated project. Imagine the most complex project you worked on, make it 10x, and you get how it is building a social VR platform with user-generated content. A few weeks ago, I participated in the podcast with Artur Sychov, the CEO of Somnium Space (another cool social XR platform) and we agreed that you have to be totally crazy to try to build your own platform.

Be prepared to learn a lot about how to organize a team, improve a lot your technical skills, solve problems of all possible kinds, fail at a million things, have a constant emotional rollercoaster, but especially, to have no idea what you are doing all the time. It’s like being put on the driving seat of a rocket going at maximum speed… when you have barely the idea of how to drive a car.

Take some time before starting the project… prepare psychologically for a very long and tiresome marathon. And if I can give you a suggestion: read, read a lot.

Some days ago, I was discussing this topic with “Mister President” Alvin Graylin, who is an avid reader himself and we agreed that books are an incredible boost to your knowledge. If you, like me, have never been involved in such a huge project, as soon as the opportunity to build a platform gets more concrete, start reading books to improve your skills. I read a few books about software architectures and also about how to be a good CTO and these turned out to be incredibly useful to be able to succeed at my job. (I could suggest you a few titles if you want)

And I’ve not stopped there, I still read every day to improve: these days I’m reading the book “Making A Metaverse That Matters” to learn how we can improve our products using the lessons learned from the story of Second Life. 

Finally I have some time to read @slhamlet 's book during these holidays! I've just started… the first pages have been interesting, I will tell you how it is when I've finished it. It's good to learn from who has started being in virtual worlds much before me…#metaverse pic.twitter.com/eAapmdIozq

— TonyVT SkarredGhost (@SkarredGhost) December 27, 2023

Also, be prepared to run a marathon: such projects span multiple years, so it is not just something you build fast and forget, but a project that will be part of your team’s life for a long time.

Define your vision

Once you have decided to start your platform, it’s time to define exactly what’s your final vision. What do you want to build? What is the end goal? Think as if you had infinite resources and aim at the infamous “5 to 10 years” timespan (see Vitillo’s law of technology).

Some of the questions you should answer yourself are:

• What is the problem your platform solves? You should know this from the previous analysis about why you should build your platform
• How does the platform solve this problem? 
• How does your solution work? Imagine your app long term, how it works, how people are using it, what are all its possible features, etc…
• What is special about you? What is your “unique value proposition”? What is your magic for which people should use your platform and not the already existing ones?
• For whom is it targeted? This is a very important point: in our case, when building a platform for concerts, you may aim at super-top professionals like Taylor Swift, or you can aim at hobbyists, like the teenager who sings the songs of Taylor Swift under the shower. It’s important to define who you are building the platform for because this is going to influence everything, from marketing (e.g. different categories of users use different social media) to UX (e.g. if you target tech-savvy people, the interfaces can be more complicated, if you target non-techie people, interfaces should be slick and simple), to prices, to everything
• What are your founding values? For instance, do you care about privacy? Do you care about safety? This may influence your decisions a lot as well. For instance, if you care about privacy, you need to be careful about what data you track of your users, while if you don’t care, you can go into full tracking mode and steal all data you want and sell them to advertisers

In our case, the purpose was (and still is) to build the best metaverse platform for creating immersive/hybrid shows and for enjoying them. We have very strong values like safety, privacy, accessibility, and inclusion (I will talk about them in a dedicated chapter). The long-term target creators are all people who have the talent to set up a show, may they be professionals or hobbyists.

As I’ve learned over the months, all the people in the team must be aligned about what is the mission of the company and its long-term vision. This gives everyone a common direction, and also a reason for working so hard every day: being on a mission to “build the best metaverse platform for concerts” is pretty cool and motivating. If you don’t specify this well, different people may go in different directions, causing some incoherence between departments: for instance, the marketing may promote something while the dev team is building something slightly different and this may create a mess. 

Start from your MVP

Now that you have dreamt about your future, it is time someone slaps your face and wakes you up. 10 years have not passed by, you have not even started building your product, and most probably, you don’t have infinite money in your pockets. So… what do you do? You start with an MVP.

In the lean startup philosophy, you always start with a Minimum Viable Product, which is a barebone product that shows the most important functionalities of your solution. After you have dreamt about your destination, you have to focus on your first step, which is a basic version of your solution, to put on the market, to see its reaction.

What this basic version is up to you, but remember to plan for it considering the money you have, the team you have (or you can build with your budget), and the time you have to do your launch. Usually, you have some budget from a seed fund or a grant, a small team, and you want to launch something in a few months to have quickly something to show investors to try to get more money to make the project go on. And you have to think about what you can build in these conditions that can still be interesting for your target users.

In our case, the MVP is what we launched with the Alpha of the platform: an application showcasing a cool VR concert where people could enjoy the event together, everyone with their own personal avatar. Since user-generated content is one of the most important features of VRROOM, the first concert in the platform should have already been built using some primordial creator tools of the platform. That’s it. Many features were left out of this solution because they didn’t fit the resources we had: for instance, there was no ability to friend other people (this feature has been introduced in our early access version) and the concert experience was hardcoded into the build executable (a dynamic system with downloadable worlds has been added in the early access version, too). We launched the minimum application needed to see if people could be interested in what we wanted to build. And trust me, even with these huge limitations, the application was incredibly difficult to build.

Even if you have to build a smaller version of your dream, don’t forget to add some little special things in it, to make it more memorable to your users. For instance, we added a system to let users shoot pictures with a virtual phone and then share them to social media directly from within VR. This is something that very few platforms have.

Of course, when designing your MVP, imagine also what should be the next steps after it, so a roadmap at least for 6-12 months. But trust me, almost nothing of what you will write will actually be done. Perspectives will change so much after you have done your first chunk of development and your first launch, that most probably whatever you have planned should all be rewritten.

Build your team (and do project management)

Once you know what you want to build, it is time to build your team to do that, if you don’t have it already. There are entire books written about team building and management, so I will not try to describe something you can already find written in more detail elsewhere. But I can still give you a few pieces of hiring advice:

• Hire talented people
• Hire people not only for their technical talents but also for their soft skills. Especially, think if they are good to work in a team with the other people you have. Platform building requires a lot of teamwork and also the ability to work under high pressure, so look for these qualities
• If you’re building an XR platform, look for someone with previous experience with AR/VR technology and with previous experience with multiplayer applications. Multiplayer always adds a lot of complication to every application, so having someone who is already used to this is a big plus
• Think about all the figures you may need. You don’t need only developers, but also people who can work on UX, audio, QA, etc… Strategize who you need now and who you need later. And hire the people you need full-time, and get as freelancers the ones that don’t need to work every day (e.g. in our case, for the platform per se we didn’t need a full-time audio designer, so, for now, we are relying on freelancers)

This is what I can instead say about team and project management:

• Give your team clear values
• Write down a clear process to build and deliver. Talking about coding, for instance, what people should do before coding? What are the coding guidelines? Is there a review process after the code has been written? For instance, we use a slightly modified version of Microsoft guidelines for C# for the coding phase, and every code is reviewed during the pull request stage
• Try to ask for high standards from everyone. In exchange, be supportive of everyone, and help everyone to grow. One of the most moving things that has happened these months has been seeing the growth of some of the developers, who have improved so much during the development of the platform. And I’m moved also by seeing how much I myself have improved
• Hire a project manager to help keep track of deliverables and timelines
• Define the software used to communicate. For instance, we use Microsoft Teams for almost everything
• Plan as much as you can: it’s better if people know what they are doing now, what are they doing later, and how their work is going to fit what all the other team members are doing. A platform is made of a lot of pieces, and all of them should fit together, so everyone must speak with all the other professionals who are involved in building the parts that are somewhat related to his work to coordinate how the parts should fit together
• Organize meetings to keep people on the same page. Standup meetings exist for a reason… do them. It’s important that the coordination happens inside every team (e.g. between the developers), and also among teams (e.g. dev team and marketing team). As I’ve said, platforms are huge projects, and it’s easy to lose coordination, that’s why regular meetings help people stay on the same page. I know meetings are boring, and make everyone lose a lot of time… but without them, it is impossible to make such a big project happen

Design your software

At every stage of development, before you start doing anything, you should design what you are going to build. And this is something to be done at various levels.

At a higher level, you should design what’s the end goal: for instance, when we were building the alpha version, we imagined how the alpha version could be. But then, after you have this high-level understanding, you should go one level lower and start designing the various parts that compose the application. This part is performed by the various heads of departments and regards their field of expertise:

• The CTO designs the high-level software and network architecture of the application
• The UX designer does the same for the user experience, and also for the UI, in case there is not a specific UI designer
• The art director writes down what’s the graphical style and the mood of the experience
• The sound designer imagines what parts of the experience require audio, which should be the sound effects, etc…

This moment is crucial because it is where the real deal starts. Every head of a department prepares the work for all the employees to start working and coordinates with all the other heads to make sure that the final result of all the work they are doing is coherent. Without this initial stage, everyone would just start working and doing stuff without an underlying coherency, leading to disasters. 

What I’ve learned in my software development career is that the most precious work you do is before you start writing code. Writing code is a skill on its own, but at the end of the day is quite mechanic work, and we are seeing how ChatGPT can already partially substitute developers for simple tasks. What elevates us above machines, at least for now, is the ability to architecture the code, to understand from high level to low level how things are interconnected, and how they should be designed so that the final application is modular, efficient, and maintainable. This is a sort of technical art that requires vision across all the software, and also across all departments, that’s why it’s hardly replicable by a machine for now. ChatGPT will eventually get there, but it will require years, in my opinion, while for the dull writing code task, it’s almost getting there. 

I’m speaking about software architectures because that’s my task as a CTO, but similar reasonings hold for every department: Midjourney can do interesting drawings, but AI still is not ideal for designing the graphical style of a big project. Speaking about the graphical style of VRROOM, designing it was a hard task on its own. I was talking with our art director Lapo Germasi about it and he explained to me one key difficulty of his task: “How can you define the graphical style of a platform where the user-generated content will have its style, and every piece of it will be different from the other ones?”. He also told me that every choice he could make could have had a ripple effect: for instance, choosing a very strong style for the avatars and our home environment would have probably made creators all lean to choose a similar style for their experiences, to make it coherent. So this would have implicitly limited their creative freedom, which was not what we wanted. For this reason, he leaned towards something more “neutral”, so that every creator could feel freer to decide his style in the experience (you can still see this in the cozy style of our home space). 

Getting back to my job, I had to decide what were the technical foundational blocks of our platform. I picked Unity as the game engine because it is one of the best ones out there, I’m good at using it, it has a great community that can support you in case of issues, and it is also the first engine to be compatible with XR headsets when they’re out: Apple itself talked about Unity during the announcement of the Vision Pro. For the multiplayer, I also went for one of the gold standards of the industry: Photon, which with its latest Fusion product also increased a lot the number of people allowed for a single instance/shard (up to 200). Unity XR and Unity XR Interaction Toolkit would have been the ground of everything XR-related because they ensure cross-platform integration of XR interactions among all the headsets. Sometimes the XR Interaction Toolkit may feel limited when compared to some alternatives, but the fact that it is a standard solution and is cross-platform makes it compelling. Meta Quest Unity integration, for instance, offers amazing advanced functionalities, but they are available only for Quest, so it would have forced the team to write custom interaction code for all the different headsets and we had no time to do that. Some Unity plugins on the Asset Store are cross-platform and offer very realistic interactions in XR, but they are maintained by a single person, and it would have been a risk for us to base the foundations of our huge platform on one guy who could decide to stop working in whatever moment. Unity XR was a much safer choice.

I want to put a little stress on the Photon Fusion thing and the 200 people per instance: ideally, in a platform for doing concerts, you would like to have thousands of people in the same instance, so that you could recreate the same situation that happens in real life with concerts in stadiums, where a lot of people meet and sing together. But doing this is practically very complex now because the technology is not ready. First of all, there are the problems of networking: every avatar should exchange the position about its pose with all the other computers, and this creates a huge data exchange. With many optimizations, on Photon you can arrive at up to 200 people together, which is a good number, but still not the thousands we are hoping for. Even worse, there is also the problem of visual performance: even if you could have 200 people all around you, most probably the Quest 2 wouldn’t be able to show all those full-body avatars without having performance issues. That’s why we are currently aiming at a safe 20-40 avatars per instance, with the plan of increasing this number over time, by optimizing performances both on the network and the visual side. In the future, we may even think about using solutions like RP1 that showed during tests that they can support thousands and thousands of people together in VR.

Designing such software is all a matter of compromising different factors. The choice we have taken of having full-body VR avatars is one of them: it’s good to have avatars with legs, but this means putting a burden on performances, because inverse IK to calculate the legs’ position has a cost, and also showing the avatars with the legs has a computational cost. But we evaluated that we were ready to sacrifice a bit of performance to have avatars that felt better. The design stage is full of these compromises.

We also had a few discussions about going or not going for the Web route. I’m a huge believer in Web XR, I think that eventually, the metaverse should have a strong web component. The web makes an experience accessible from every device starting from a simple URL: it’s handy, fast, and universal. The problem is that currently all the systems to develop for WebXR are very rough, and the resulting graphics of WebXR applications are usually quite underwhelming. While speaking with the artists, we decided together that while enticing for the future, for the present, going to the WebXR route would have caused us various headaches, just to obtain a final visual result that wouldn’t have been that great for our users. We do VR concerts, also quite cool ones, and it’s important to provide them with the right graphical level, so for now going web would have not given our users what we wanted to give them. We still keep an eye to see what happens on the web side, to evaluate if eventually do a switch in the future.

Cloud streaming was also an option, but it would have raised a lot of the costs (streaming video is quite expensive), so for now we decided to skip it.

When I was young, I thought that people designing software were just geniuses with long beards that entered a trance state and then inspired by some god wrote the whole structure of a project. The reality is much different, maybe because my beard is only medium-sized: writing an architecture is an iterative process: you usually write it, and then you revise it and you improve it in the days after. Plus it should be challenged by your peers, who point out issues, that you have to fix. It also requires doing experiments: for everything I was not sure what to do, I had to spend some time testing and experimenting with my assumptions. This is important for coding, but it is even more important for UX: remember that there are no standards for interactions in XR, so it’s hard to design how to make the user do something in a natural way without doing many experiments about it, and asking various people in the team to test the prototypes and give the designer their impressions.

Audio and UX are usually the forgotten children of the design stage. We always think about visuals, and, in fact, when talking about a headset, we always speak about resolution and FOV, while audio is a very important component as well. Some people in Hollywood say that audio makes up 50% of the result of a movie: imagine how audio can increase the tension in a horror film, for instance. For us, who work with VR concerts and shows, audio becomes even more relevant than for others, and our CEO Louis Cacciuttolo always pushes the topic of audio quality during meetings. That’s why it is important to onboard an audio designer and/or some audio engineers in the team.

UX is usually another field that many teams overlook, but it is actually of critical importance. A UX designer onboard can see the experience from the point of view of the user, and imagine what would be the best flow for him/her for everything that app should do. It makes a difference between an experience that is pleasant and one that is hardly usable. Having onboard a UX designer who knows how to do XR experiences is of critical importance, and luckily we have our amazing Mike who can do wonders. Our UX designer made sketches for the UI, implemented prototypes for every feature that had to be developed, and wrote a lot of specification documents for developers to follow. When we started the development of VRROOM, we hadn’t found the UX designer, yet, so we just started with some temporary ideas I was having… to then found later, when Mike arrived, that they were all not that great… so we had to redo part of the development to fix the flow using his expertise. UX designers must do their job before the development starts, otherwise, later you have to redo everything when the actual design arrives.

Software as a living creature

It’s interesting how such a big project evolves. It is like it goes on with development cycles, with every one of them bringing substantial changes. In parallel with that, there are some small changes carried on during a single cycle. It is like the project evolves with its own life, growing up a bit like a living creature.

There are some moments, usually after the various milestones, where it is important to stop for a moment and think if there are ways to improve how you are working. These changes may require the codebase, the architecture, the processes, or other stuff. And when they are carried out, they are going to do a little revolution on what you are building. One example regarding VRROOM is what happened after the alpha was delivered. I started to rethink the whole architecture of the project, and I realized that the project was built more to be a standalone multiplayer application that should be delivered in a few months than a platform meant to be developed for many years. So we started working on an important refactoring with Denis, our lead developer until the whole organization of the VRROOM project was more coherent with what we were building. After that, working together became much better.

The interesting thing about all those changes is that sometimes you do not notice you have to do them until you arrive at the point that you need them. Two factors contribute to this. The first one is that the project grows, and growing it develops new necessities to be handled well. As a stupid example, if your project just has 10 files, probably you can put all of them in the same folder. But when it grows and it gets to 200, you feel the need to separate them into subfolders otherwise they are a mess to manage. The bigger the project, the more the need for more organization, more processes, and more rules. Talking about the above example of the alpha: the structure of the project was good for its purpose, that is the alpha launch, but it felt not good for the future projections of the application, so we needed to improve it.

The second thing is that while the project grows, you also usually grow a lot professionally, so you start noting how more things could be done better. If you asked me in January 2023 how was the status of the code of our platform, I would have told you that we had very little technical debt, meaning that overall the code was good. But today, looking at some specific parts of the code that was written one year ago, I’m more like “This could have been made better”. The thing is: the whole project around that code changed, and I’ve also improved a lot my skills, so now that code feels a bit obsolete to me, and it needs to be refactored. And I can bet whatever you want, that after the refactory that part of the application will be good again, but maybe in two years, I’ll feel the need to change it again.

Another thing that may trigger this willingness to change is the change in external conditions. Just to give you an example: now Apple has announced its headset, the Apple Vision Pro, but while we started developing VRROOM, the launch of an Apple device was just a rumor. The foundations of the VRROOM applications should work on the Vision Pro (Unity, Photon, and XR Interaction Toolkit are all compatible), but probably some minor parts of it may have some compatibility issues with iOS. We have to verify it, and in case we want to launch on Vision Pro and in case the compatibility test fails, we need to rethink some parts of the codebase to make it compatible not only with PC and Quest but also with Vision Pro.

It is like the application has its own lively growth. It evolves, changes over time, and also adapts to externally changing conditions. This is the reason why agile makes a lot of sense: having strict roadmaps would surely lead to failure. You have to just prepare a strong timeline for the next 2-3 months and for later you have to just specify some looser direction. If you do differently, be prepared for all your plans never to be followed.

Development

After I’ve spent a lot of time talking about how to design everything, how to organize the team, and all the rest, the time has come to finally speak about the action phase. You may expect that this paragraph may be longer than all the other ones combined… but actually, probably it will be one of the shortest.

The reason is: action is just action, there is not much to say. If you and your colleagues have to develop, you write code. If you have to do 3D models, you use Cinema4D and you do them. There is nothing special to say, and for this making a VR platform is the same as making Minesweeper for Windows (my favorite game when I installed Windows for the first time in my life).

For this phase, I have just a few suggestions:

1. Never stop improving the process. During the development of every milestone, try to learn what can be done better, make a test with part of the employees, and if that thing works, expand it to everyone. As I’ve said, platforms are gigantic applications, and every improvement in the process may benefit many people in the company. As a title of example: at a certain point I did a quick test with unit testing in Unity and I found it pretty handy. So our lead developer made a test, too and he totally fell in love with it. We then started slowly to implement automatic unit testing in the whole development team. The reason is that unit testing makes the development phase slower, but then gives you a huge advantage during the QA phase, and also when you refactor something
2. Try to enforce discipline. Such a huge project requires military-level discipline to keep the project tidy for everyone. Talking about the development, enforce the coding guidelines, enforce a directory structure, never compromise modularity, etc… The moment you start to be loose with these rules, everyone starts violating some of them, and it starts a downward spiral that makes the project a mess. I have some kinda big projects I worked on in the past that started as tidy, and ended up as a disaster where you never know where you could find some files.
3. … but be practical. The priority is delivering. Always, at every cost. As I always say “The users do not care if we used the best programming partners for everything, if the features do not work”. The last days before delivery are when you can make some exceptions and compromises. If rules become a bit looser, the team can go faster and deliver. Not to mention the fact that being picky about comments guidelines when people are crunching and working in the evenings is a good recipe for being beheaded like the French kings during the Revolution. You can still take notes in your task-management program about all these dirty things that have been done and fix all of them after the release.
4. Trust the process. The process is what makes you deliver: it ensures people work in the best way possible and all the people stay coordinated. So, standup meetings are necessary, even if may seem like a waste of time that could be used for actual production. Code reviews are fine to make sure the application works. Inter-team meetings make sure people do not go in a different direction. Believe in the process.
5. Improvise. Adapt. Overcome. NOTHING will go according to plans. Be ready to find issues and solve them, sometimes in a creative way. Be prepared that there will be delays with everything and some features will have to be cut down. And be sure that something you imagined will not be doable because of some reasons. You will say “FUUUUUUUUUUUUUUUUUUUUUUUUUUUCK” a lot of times

Crunching time

The development of such a huge product is going to cost you a lot of time and energy. One thing that I also noticed, is that everything takes always more time than expected: maybe an expected bug is haunting you; maybe you get sick and so you have to slow down for a few days; maybe you realize all the intricacies of a task only when you are actually doing it. Especially the last problem is very common: you start with a task, and then you realize all the real underlying problems only when you start doing it and you speak with the other people that are involved in other tasks that are related. And this means that at the end of the day, you always risk being late with the timeline you planned in the beginning. And if you are late, then you and your team have to crunch to deliver in time for the next release. It’s known in the software production environments that a bit of crunch always happens in the last few days, so the mission is trying to reduce this crunch to a minimum. And this is an art I’m still learning.

Since we had some crunch for every release, I got to learn the hard way some lessons on how to reduce it. The most important thing is to plan everything well, and in particular:

• Always do the design phase before doing a time estimation. If you don’t know exactly what you are going to do, it is impossible you estimate its time reliably
• Always multiply the planned time for some factor to take into account the unexpected: I would suggest a multiplier from 1.3x to 2x, depending on how optimistic you are usually in your planning. So if you think that something is going to take 2 weeks, consider that most probably it is going to take 3.

One thing that is better, if possible, for the good of everyone, is not having very hard deadlines (i.e. an exact date at which you ship an exact set of features)… but sometimes they are necessary for marketing purposes (e.g. to tell everyone when the launch of your platform is going to happen). My suggestion is to use hard deadlines only when strictly needed for a big marketing push (e.g. if you have to do a big launch of the v2.0 of your platform) and for the rest use only intermediate release dates in which you can skip a feature if it is not ready that day yet. 

Another suggestion is to be very careful with the combined release of content and platform together: for instance, both for the launch of our alpha and our beta/early access, we shipped both a platform update and a big concert: Web7/LeJuiice/Maxence for the Alpha and Armani White for the early access. But trust me, having the whole production team work on two big productions at the same time, is going to create a huge stress and a huge coordination effort. If you can, avoid it: it’s better if you work on your platform update, and then maybe 1 month later you do the big event to do the marketing push of your platform. This has two big advantages: first of all, you separate these two big peaks of work, making it easier for the team to handle all of this; and then, since at the launch of your new version for sure you will have some little bugs, you have some time to validate your new version and fix some bugs before you do your very important event.

QA

Remember to do tests of the solution you are building. Establish as many automatic tests as you can, so the software can undergo regular safety checks without any effort. Sometimes the work that someone does breaks the work of others, but no one notices, so automatic tests may save you.

If you can, perform regular testing sessions even just with people on the team… just testing everything at the end is a recipe for disaster. BUT… I’ve noticed that it is hard to do this when the foundations of the platform have not been finalized yet: how can you test a platform that does not exist yet? The initial phases are quite critical, because you are building separate parts of the product, and they can only be merged when they are finished, and only at that point you have your first duct-taped platform prototype. From this moment on, you can do more tests, but before, this is pretty complicated.

Remember also to test the whole platform before every important launch, possibly with external people who can test it and give it an external point of view. Do some stress tests, which will be important, especially for the backend and the multiplayer. Try to involve as many people as you can, I would say 20-30 is the bare minimum. You can take these people from your community or collaborate with an external VR testing company (if you don’t know any, I can suggest one). Having external people is important because you as the creator are used to following the path that you know that it works, but what is obvious for you is not for the others that see your product for the first time. Besides, other people usually do other things that are different from the ones you do: for instance, during a session we had with testers, we discovered that our user account registration process was broken, but we did not realize it before because all of the development team already had a VRROOM account, so no one was registering anymore during out tests.

As a big suggestion, considering the latest issues we had ourselves, I suggest you try to test the platform in the most realistic conditions that you can. So don’t just test an ideal case, but test various cases that may happen for real: if users have to download a 500Mb package, don’t do just a test with a 10Mb one, because you may not spot all the problems that may arise.

Hiring a QA Manager can help you with this process.

Backend and website

It’s easy when talking about a VR social platform to just think about the VR experience, but actually, the whole system includes many other entities, like the backend and the website, which are critical for its success. And these parts have to be built coherently with the VR application so that they all work like cogs in the same machine. Also, the branding between the various parts of your solution (in particular website and application) should be coherent.

Talking about the website, it’s important to decide which features are important to be there. The website is where people may land after they click an ad about your platform that they may find somewhere, so it is where they should find information about how is the platform and what is happening there and they should perform an action (e.g. registration). This is why my colleague Thibaut insisted so much on having a list of the events running on the VRROOM platform there: this way people can see what is happening in VRROOM, get intrigued by the platform, and download it. The website is also where there is the user area, where we put the list of pictures the user has shot in the experience so that he/she can download them and share them on social media from all the devices.

The backend is something that will grow in importance the more you develop the solution. It is really a foundational part of what you are building because it saves the information about the users, the worlds, the avatars, and all the main things that comprise your experience, so care about it a lot, because it is a component that may decide between the success and the failure of what you are building. When I started building VRROOM, the first version of the backend just looked like a support for the VR experience, but the more I went on, the more it gained tremendous importance. Care about it a lot.

User Experience and accessibility

I’ve already stressed a lot about the importance of the User Experience, so I will not repeat it. No, wait, let me do it one more time: the UX is super-important, so work with a professional to ensure that it is good. User Experience is pervasive in everything you do: when we were designing the alpha concert, the first concert to ship with the alpha version of the platform, the UX designer made the artist change the dimension of the spaces people were in because it wouldn’t have been coherent with the dimension of the safety bubble of the users. 

The UX designer is also important to implement accessibility, which is something I strongly advocate for. Sometimes just with a little effort, you can make your experience more inclusive. For instance, he worked to design an input scheme that was symmetrical in both hands, so that the whole experience could be enjoyed even by people with only one hand (with a thumbstick click you can also switch between smooth locomotion and teleport with snap rotation, so you can also fully move only one hand). The experience also calculates the height appropriately if you are seated. We tried to think about some color schemes that could be used by people with some type of color blindness. Mike has been great in thinking about all these features since the beginning of his work. And most of them didn’t increase the development time much. I’m not saying that our platform can be used by everyone (yet), there are still many features that could be integrated (I would love to arrive at the level of Owlchemy Labs in terms of accessibility), but at least we are working with the right attitude to arrive to that end goal.

Safety, Privacy, Inclusion

Safety, privacy, and inclusion are some of the values of our team. But, let’s be honest, these words are repeated a million times by everyone now, and they started to lose real meaning. We wanted instead to implement them for real, but how could we do it properly?

We decided to partner with the entity that is considered the best institution in the field, which is XRSI. Kavya Pearlman, the founder of XRSI, was very happy to collaborate with us and contribute to making our platform a safe place to be in the social XR space. We hope that in the long run, we can become an example to follow for others.

There are a million things to think also about these three points. For instance, regarding privacy, you should track the users the least that you can, and whatever you track should be anonymous and not sold to third parties. This means having less data to be used for analyzing what the users are doing, which is bad on the practical side, but it is good to guarantee a fundamental right to your users.

Regarding safety, trust me, there are so many things to think about that your mind may melt. Let me tell you some example questions that came to our mind in the past months:

• Should you start with the safety bubble of the users on or off? On is much safer, but it keeps people distant, making social interactions harder
• If I block a user, should the user know that he has been blocked or not? If he knows, he knows he misbehaved and he can improve, but he could also get angry and rage against the others
• When should a user be kicked out of the room? How many people are necessary to take this decision? If the number is too low, this opens up an opportunity for trolls to go around for rooms and kick away innocent people, but if it is too high no one is ever kicked out

These are questions that you don’t know how to answer if you have never worked in this specific field. Luckily we asked many of these questions to our friends at XRSI and got many interesting answers. I’ll tell you one of the most interesting of these insights we received: safety measures should be proportioned to the size of the audience of your platform. If in the beginning, maybe you are a community of 50 people, most probably you are just a bunch of passionate people who are friends with each other, so there is no need to have super strict safety rules. They could even be counterproductive: if for everything people have to do there are a million safety checks, the few people that arrive on your platform will find it pretty clunky and complicated, and will just go away. You will never create a community this way. But when you have 15,000 people onboard, well, for sure there are some bad apples in the chest. So you must have some safety process in place. When you have 100,000 people including children, well, you must be more careful about everything, to avoid trolling, child harassment, discrimination, and other stuff. So adapt your safety rules to the community you are serving: if you have a mature platform with many people inside, people will also accept more to go through some hurdles to use your application.

Safety is a hard topic and we are still working a lot to implement it properly. Some things make it handling it even more complex and one of them is client modifications. Guaranteeing safety with an application that has been modded is much more complex because the malicious user has a version of the application that does not obey the rules (so it could ignore the command to be kicked out for instance). I guess this is one of the reasons why VRChat implemented Easy Anti Cheat… a decision which, the more I do this work, the more I understand.

Safety has also ripple effects on many other things you do, starting from the user experience. Let me give you a little example: the safety bubble may be implemented in a way that you can not get closer to the other users by a certain distance (e.g. 50cm) so that you can not physically harass them. This is good. But what if you have in your experience a corridor with a final door that is one meter wide? A malicious user could activate the safety bubble and put himself in the middle of the door, preventing anyone from passing. A safety measure could be used for trolling: I guess now you know why I told you that UX and safety are going to give you a lot of headaches…

Talking about inclusion, well, this is another great thing to implement, but it’s another complex topic. And avatars are the first things to check in this sense. Making a fully inclusive avatar system is an enormous process, it is a product on its own, and companies like Ready Player Me just do that as a job. For a small startup with limited resources, building that and also a platform is impossible. So what you can do? Well, there are various roads to be taken: in our case, we thought that since RPM does its job so well, it was worth directly integrating Ready Player Me and offering inclusive avatars for everyone. The company was very reactive in answering our queries, and the integration was soon done. I have also to say that integrating Ready Player Me in Unity is quite simple, so it was worth doing it. Besides RPM we also wanted to offer a bunch of our avatars, but at that point, the art director suggested making them gender-less and without a clear ethnicity. The first version we did for the alpha resulted in kind of weird humans with beige skin, which were not good enough, so for the Early Access we went on making avatars which were very typical of our platform. Our avatars now are represented by humans covered with masks, and a dress style that is representative of some musical tribe (e.g. electronic vs rock music). There is nothing visible about their gender or their skin color, so they are fully inclusive. Plus they are cool and very typical of our platform, so they are distinctive traits. And they are coherent with our mission of delivering VR musical performances. A big thumbs up for our art team.

SDK

If you want to get user-generated content, you have to give users a way to generate content (you don’t say?). There are various strategies to do that, like you can offer a full-fledged complex SDK that only professionals can use, or you can provide a no-code solution that all hobbyists will love, but that professionals will find dummy. You can create your own editor or use an existing one. You can force people to create experiences from inside VR or by using a flatscreen application. There is no right or wrong solution, just different approaches.

We decided to go for a dual approach. First of all, we decided to go for the same route as other platforms like VRChat or Spatial, that is creating a Unity SDK for the experiences. This has many advantages: Unity is already well-known by many people and its editor is incredibly powerful. Also, Unity is already done, so you do not have to waste time and money to build your editor from scratch. The Unity SDK is the best solution for a team of professionals wanting to create a bespoke VR performance. On the other side, to attract also non-techie people, we offer through our website the possibility to create your events in already existing worlds, so even if you have zero technical knowledge, you can still perform on our platform.

Building a Unity SDK is a very interesting exercise because you have to build something generic and you have to provide enough tools for creators to build what they want. But at the same time, you should limit any malicious use: if a creator wants to build a world that deletes the hard drive of the users, this should be prevented. An SDK should also be flexible and easily usable. And it should evolve over time but at the same time keep as much compatibility with the past as possible, otherwise every world that is built with a previous version of the application does not work when an update is released, making all those world creators angry (thanks Denis for reminding this to me every time).

The only way to properly test if your SDK is good is to ask people to make content using it and get feedback about that. And the first people you should ask are the people on your team: build content with your own SDK, so you spot what could improved.

Our SDK offers an if-this-than-that engine and audio/video playback facilities, but after the first feedback from the first creators, we already digging into how we can add more features to it. The goal is to make it ideal for people who want to build events in XR.

Content

When you are building some user-generated content platform, you most probably have to build the first pieces of content yourself. This is useful for especially two reasons: the first one is to have some content to be enjoyed on your platform, otherwise, your users arrive and there is nothing to do and they go away. The second one is the so-called “dogfooding”: you try your product, in this case, the SDK, and you evaluate how good it is. If your team can not use the SDK you are building, probably it should be improved. 

It was during the development of our content that we realized some features were missing from our SDK: our creative people made us notice that they could not do something they had in mind, so we added the related functionalities to the SDK. Anyway, it is important to notice that you should not add to the SDK everything that is requested by your team, or you risk overfitting it to just what your team wants. You have just to add what can be useful for every one of the creators that will use your development tools.

If the content should be a showcase of your product, make it stand out. One of our creations I’m the proudest of is the Early Access launch concert we did with the American rapper Armani White. And this is for two reasons: one is that we chose a good artist because Armani is a growing star of the American rap scene. And then we had a very strong idea for it: our art team ideated a multiverse concept, that made users navigate the same space but seen in different parallel universes. The users started the concert at a Philadelphia crossroads, with Armani White singing. On the walls of the streets, there were two portals: when a user entered one, he came out from the other one, being again in the same space with the same people, and Armani White, but seeing the graphics completely changed. So for instance, after the first entry, he found himself in a green field with the graphical style of Rick & Morty. Entering the portals again led him to go to a space station. But in all these spaces with these different styles, the singer and the people were still the same and still in the same position. The fun thing was that the change was local to the user that did that, so every user found himself in a different parallel universe, creating fun when they were describing to each other the world they were seeing. Something that for one user was a sea shell for another one was an arcade coin and this made the interactions pretty funny. This was a very unique experience in VR, and surely all the people who tried it want to go back to see the next concert in VRROOM. Try to do something like that: something unique that can stand out in VR, that exploits the peculiarities of the technology.

Making compelling content in VR is hard and we learned how to do it by experience over the years. It is even harder because it is a new field, and sometimes to do it properly you would need some professional figures that do not exist yet because they are in the middle between physical live shows and game development. So you need to take someone who is not totally fit and make him adapt to the new role (e.g. a light designer working with traditional concerts and make him adapt to work with Unity in VR).

Artists management

If you have a platform that does VR concerts or live shows, you have always to remember that the management of the artists is not an easy feat.

First of all, you have to find artists that are willing to perform on your platform. It may be easy when you are Epic Games, you have millions of users on your Fortnite game, and you have millions of dollars to spend. But if you are a startup with a new platform and a limited budget, it can be pretty tough, because, of course, the labels are not sure if they can trust you. Remember that all artists have a reputation, and if your new platform crashes, or there is some sexual harassment happening, etc… this can have a negative ripple effect on the reputation of the artist. Even more simply, if the experience you create is going to be bad, of course, online magazines will say that that artist had a bad show, and this is not good for him or her. So there is a lot of work to do to convince the labels that you can deliver something good. Having some people who can introduce you and endorse you to labels is going to help a lot, so if you need to operate in the music business, find connections that operate in that space.

Most probably, for the first shows, you won’t be able to secure the most famous singers, and honestly, that’s even good. If you start with some less-known artist, you don’t risk a huge backlash in case of problems. Plus if the artist is smaller, it is going to drive to your platform fewer users, which is going to stress less all your infrastructure (reducing the risks of malfunctioning). Ideally what you want is to grow step by step, starting to provide a good experience with some emergent artist and then go towards a more famous one at every next concert. This is exactly what we did: with the alpha we had three emerging French artists, and for the Early Access a rising star of American rap, then at Christmas, we tried with a legend of electronic music like Jean-Michel Jarre.

It is also important that you build the experience together with the singer, so it’s good that your creative team proposes ideas, but they have all always to be validated by the artist. The same holds for the avatar: the visual appearance is very important for a performer, so the singer or someone from his team should approve his avatar. We saw how the avatar is important ourselves since our first collaborations with Jean-Michel Jarre in VRChat: we always dedicated a lot of effort to ensure that his avatar was cool, and was as close as possible to how he imagined himself to be in the metaverse: this meant working with a shader artist to provide nice FX around his avatar, and with a mocap studio to be sure that his movements were tracked well in VR. A fun fact that Maud Clavier, the COO of VRROOM that usually deals with artists, always tells during presentations is that before the Welcome To The Other Side concert, Jean-Michel asked for a picture of the face of his avatar, so he could make the same haircut in real life and be perfectly similar to his virtual counterpart. This shows how much appearance is important.

If you have to bring the singer into the virtual world, you should be able to track all his movements while he sings with some tracking suit and gloves. I’m not going into much detail here, because that should be a dedicated post per se, but suffices to say that you need to find a system that tracks the body very well and that results in motion data that is as clean as possible. Usually, this tracking should happen in a dedicated room and performed by experts in the field and this poses the other problem that you have to manage the artist traveling to that location.

Even if you manage all of this, you’re left with the enormous problem of the music rights: you will probably gain the rights to do the concert and its replays just for a limited time… or sometimes just for one performance. So after a certain time, you will have to take down your experience and hide it from the public, unless you re-negotiate everything with the label again. This is a huge nuisance on its own.

I’m writing this chapter to make you understand that artists’ management can be very complicated, and you should start looking for the artists that may perform on your platform as soon as you decide to do a concert. Trust me that in the beginning, it will require you much more time than you expected.

Legal issues

Don’t forget to care also about the legal side of what you are doing. As a starter, you need a privacy policy and a term of service for your platform: you can not even publish on the stores if you don’t have them. Then there is the cookie policy for the website. There are all the GDPR rules to comply with if you are based in Europe. There is everything about IP to be considered, and for instance, in your experience, you should not put anything that is IP-protected. You should be careful about IP in user-generated content: you have to be clear about who has the responsibility for the violation in case a user puts some protected IP (e.g. a famous pop song) in the VR world he creates. If you need to distribute a piece of software, like your SDK, you need a license for it. I think you have it clear that you should have a legal consultant.

Legal things will affect your user experience as well: for instance, as for GDPR rules, you should not gather certain kinds of personal data unless it is truly needed, and this limits which field you can put as mandatory in the user registration phase. To be sure that the user-generated content is not going to violate any laws, you have also to set up a moderation process for all the public experiences on your platform. This is also what we did on VRROOM, where every public performance should be moderated by us.

Marketing 

You can do the best product ever, but if no one knows about it, then the world will not even know that you ever built it. Marketing is an important part of the mix that makes a platform successful. A platform is made of people… if people do not go to a social VR platform, there is no “social” anymore.

I’m not a marketing expert, so I’m not going into much detail here. Plus, I’m waiting for us to have a big reach before telling you what truly worked marketing-wise. But also here, I can provide you with some suggestions.

I have helped a bit in trying to do outreach for our platform by contacting some VR magazines about it, and I have to say that I confirm what everyone in the field already knows: getting visibility in XR is truly hard. The VR magazines are just a few, and many of them shut down after a while (I still remember when VR Focus was a thing…), and the ones that survive are overwhelmed by requests. Not to mention the fact that they are mostly focused on games because it is the sector that interests the most in XR at this moment. So getting visibility for your new “metaverse platform” when another gazillion came out during the Meta hype, is pretty hard. A similar situation happens with XR Youtubers: many of them have their kind of favorite content, some are super famous and overwhelmed with requests, others are too expensive, etc…

I’m on both sides of the fence, so I know how is the situation: I have not much time for writing articles myself, so I can just give visibility to a few companies. Anyway, what you can do is still try to contact all of these magazines and content creators and see what happens: some of them will be kind enough that even if they can not make a piece of content for you will still help you somehow, like retweeting your tweets about the platform. Some of them will still publish you, and this is how we were featured on Mixed News, Real O Virtual, and the Week in the XR column of Forbes. 

If you want to be published, also give your story an interesting cut that is worth a publication. If you spread the news as “The best VR social platform is out”, I would ignore it for my blog, because I’ve seen 1000 of these claims. But if you write “The first social VR platform with 10000 users in the same room” or “Our social VR platform launches with a concert of Dua Lipa”, well, you have my interest.

Marketing of your platform should also balance the promotion of the platform itself and the content. If you have a very strong piece of content, it is a good thing, because it attracts the attention of everyone, but it risks stealing the attention to what the platform is good for. For instance, everyone knows the amazing concert that ENGAGE did with Fatboy Slim, but I don’t know how many of these people know that ENGAGE is one of the best platforms for professional meetings in the metaverse. Here there is not a rule to follow: it’s a matter of balancing, and you find the right mix with the experience. But you need eye-catching content to attract the attention of people: all the spikes we had on our platform had been on the occasion of very cool events we were hosting (like the concert of Jean-Michel Jarre for the 400 years of the Versailles Palace).

If you can, ask also support from the stores. I’ve seen Meta promoting the content going onto the official Quest Store with a blog post. Sidequest put a banner for free for some time about my fitness game when I launched it. Pico selected VRROOM as a featured experience during the alpha and early access launches. Platform holders have a good reach, so this is also a good way to promote what you are doing.

Marketing is an activity that is pervasive to your whole team as well. The marketing team needs to do its job, and so needs material from all the other production departments, like visuals to share with the art team, or some information about the latest bug fixes from the development team to write a tweet about it. This coordination work is not always easy to perform, because the production teams have to do some overwork to facilitate marketing, which is usually seen as an afterthought (and yes, I’m guilty about this, myself, too). But marketing is as important as production, so all this work should be done. 

As a last piece of advice: promote your platform as much as you can. Otherwise, all your efforts will be in vain. I will never cease to stress it: kickstarting the users’ ecosystem is one of the most difficult things ever, because you have to create a community from scratch, and if you don’t have it, you are going to die. Think about VRChat: maybe it was not the most advanced platform when it came out, but it became so successful because it was able to attract a big loyal creative community which makes it the amazing product it is now. 

Delivering

When you think about having finished everything… well, there is still a lot to do to deliver your platform. For instance, you have to publish the application to the stores and this is not trivial.

Every store has its way of doing things, but one very important factor to consider is the review time. For instance, on the Quest Store (App Lab), an approved application is not reviewed for new updates, while on the Pico Store, it still happens. Itch will let your app go live immediately after you create a page for it, while Steam requires a long review process before the first version of your executable can be released to the general public. Be informed about all these waiting times, or you risk not delivering in time for your launch. For instance, since Meta Store requires long review times for the first submission of the application, and the subsequent updates are immediate, we submitted as first version to App Lab a very rough version of our app, so we could improve everything we needed while the application was being reviewed and then we applied all the enhancements as an update the day before the launch. We instead had issues with the launch day on Steam for the alpha because the app was approved, but Steam required the store page to be live for two weeks before the build could be downloaded, so the launch on Steam happened as closed alpha. Consider all these times while delivering. Also remember that the submission to the stores requires a lot of graphical assets and a catchy description of the application, which should be provided by the marketing team.

Since the delivery of the application is a delicate moment (if you do it wrong, this may affect the experience of your users), be sure to automate the process. If you do it manually, do like me: have a written checklist of everything you have to do, with exact instructions on what you have to do, and follow it literally. This way you reduce a lot the chances of any errors.

Before you are sure you have delivered, do a last paranoia check on everything: you don’t know how many bugs I have found with the “just one last test” strategy…

Launching

Your platform will have multiple “launches”. There is the first one, where you finally come out of stealth, and then there is a new one for every new big update or new important piece of content.

Every launch is different, and some are exciting and others are a bit anticlimatic. For instance, our launch with the alpha concert was very exciting, with many people arriving on the platform to enjoy it. We really felt that launch day. Other moments, like when we started a little movie festival the month after, showcasing 360 videos every day on our platform, was like nothing happened: I published everything on all the stores, and then… nothing happened. Yes, some people went to watch those movies, but there was not a “big launch moment”.

If the launch is a hot one, be prepared to support your users. Someone will have a crash, someone else won’t understand how to use the application, etc… so be there on Discord, via e-mail, or whatever else the communication channels of your company.

And then… be prepared for what happens next, for the good or the bad! However it goes, just remember one thing: delivering is already a remarkable result. Many projects die without finishing: if you managed to deliver something decent on time, you are already a hero. No one of your users is going to say this to you, but I’m here for that. You are amazing.

Succeeding

This year we had our moments of success. Both on the occasion of the alpha launch and the early access launch we found ourselves in the top 10 of the most downloaded free apps on the Pico Store. During the Alpha concert, we were even in first place in Korea and Europe! I had never been at the first spot in a store, whatever it was, and this has been an incredible emotion for me and the whole team! We were above popular VR apps, and even above the Calvin Harris concert… wow! The Alpha concert gave us a lot of satisfaction, with many positive comments online and even a Stereopsia Crystal Owl award for Best Technical Achievement.

VRROOM and the company COO Maud were recently mentioned on TechCrunch in an article about the concert we did with Jean-Michel Jarre. It was also interesting to see someone working at Meta mentioning on Linkedin VRROOM together with Horizon Worlds and Fortnite as interesting platforms to have concerts in the Metaverse.

When you work hard to deliver a product of value, the results are always coming, and having some moments of success can repay you for all the huge effort you carried on for months.

Failing (…even when succeeding)

But life is not always fair: sometimes you work for ages, you kill yourself to deliver and then things do not go as expected. Successes are what keep the morale of the team high, but failures are what are going to teach you lessons. And trust me: you will keep failing a lot of times because social VR worlds are such big projects, that it’s normal that from time to time, things are going to get bad. And the irony is that many times, it is the fact that they are going well that will make everything go bad. Since I like to honestly talk about failures, well, let me tell you about some that we had.

Let’s start with the alpha concert: it was an alpha launch, it was a test, and it was very successful. Even too much since we were the top app on the Pico store. When the concert ended, we were still the top app on the Store, but there was nothing to do with it anymore because the alpha test was over. So people kept downloading the application with high expectations (it was the #1 in the store!), they found nothing to do and review-bombed it in disappointment. We had to remove temporarily the app from the store to stop this downward spiral. The day after I published this image in our internal chats to joke about our situation.

During the Armani White US premiere and the Versailles concert, instead, we had some issues with our cloud. Many people connected, and this overloaded the backend, which started having issues in serving all the users. Some people managed to enter the experiences, others were left out. The irony of these situations is that usually, everything works on the cloud except one tiny thing that becomes a bottleneck and prevents everything from working correctly. I remember also VRChat talking about similar issues when they had a backend issue a few years ago. A backend is always a complex structure, and maybe a part of it, that was tested with 1000 people was working, and then with 5000 reveals a problem that causes slowdowns and crashes (I’m writing random numbers, of course). One thing I noticed is also that when there are malfunctions, users keep to try re-entering multiple times to see if the issues have been fixed, but all this re-entering is adding even more stress to the cloud systems, speeding up the crashes.

What can you learn from our failures? Well, a few practical lessons:

• No matter how much you write everywhere “early access”, “beta”, and “experimental”, etc… people want things to work, and if they do not work, will still give you one star on the stores. So don’t rely on these labels to protect you from negative reviews
• I know your focus is the launch, but also think about what happens after it. Never leave your users without anything to do in your space. This is the reason we now have a public plaza where people can chill out all the time, even if there is no event running
• Test test test test everything before a launch. But no matter how much you test, sometimes the number of users or the behavior of them will cause you problems. Even the big players had failures of this kind, sooner or later (do you remember the backlash for the Foo Fighters concert on Meta Horizon Venues?). The important thing is learning from the errors and fixing them for the future
• Be there during the failing moments and talk to people. Every time we had problems, both during internal tests and public events, just the fact that I was there explaining the situation and saying that I was sorry was enough to make people understand the situation and be less angry. Most users understood that we were building something incredibly complex and we were doing our best while still in Early Access, and even become very supportive. It’s not easy being there in the middle of the (shit)storm, but it’s the right thing to do. Listen to people, and make sure their voices are being heard
• If there is a failure, of an internal or public event, organize a replay of it, so that people that could not enter the first time, can try again the second one. This will make everyone less angry

Failures hurt. A lot. But after a moment of anger and sadness, do not let them stop you. They are part of the process, and if you are sure you have a good product, go on developing it. Think about what happened with No Man’s Sky: its launch was one of the worst backlashes in the history of gaming, but now after they have delivered on their promises update after update, it is a game loved by a huge community. If they recovered from that horrible launch, you can also recover from your little failures. Be honest, keep improving, and people will eventually love what you are doing.

Content & Communities

If you are building a social VR platform, you must have the social component, that is a community of users that frequently go to your platform. And for this community to exist, you must have a decent amount of content that they can enjoy. 

All of this is the trickiest part of your work. Building the platform per se is hard but it’s a deterministic thing: you follow the right procedure and you build your software. But then you do not want a ghost town, you want it to be alive, and this means having people inside, and also having people that create their content for your platform. Attracting these people is incredibly hard. See how many difficulties Meta is facing with Horizon Worlds: notwithstanding the enormous efforts it is undertaking, and even putting Horizon always in front of your eyes when you use the Quest, it is still facing problems with user count and retention.

Having just launched a usable version of our platform, we are still at the beginning of this journey with VRROOM, and I will share with you some better pieces of advice in some months. For now, I just remark that you should ask yourself “Why people should come to my platform? And why should they stay?”.

Future perspectives

After every launch, as I’ve said, you have to reconsider what you are doing and see what you can improve, what of your original roadmap still checks, and what should be changed because the situation is different than what you thought about.

Now, after our Early Access launch and the Versailles concert, we are working on the new versions to be released this year. And especially we are looking to create our community of creators, people that were looking for an open platform to create XR performances, concerts, and live shows. If you are among these people and are interested in collaborating with us, please reach out through this form: https://vrroom.world/en/creator-program/

I can not spoil what we are working on right now, but the direction we are taking is trying to improve our product so that it can be better both for people wanting to do events and live shows in XR and for the people who want to enjoy them. And having just introduced the ability to friend people, we also want to invest more in the social feature of our platform. Wish us luck!

Final words

First of all, I want to thank you for having arrived at this point of the article, I hope that it was useful for you reading this. Then I want to thank all the people in VRROOM for the amazing work we are doing together: I thank everyone, with a special mention to the ones with whom I spend most of my time, that is (in no particular order): Maud, Louis, Lapo, Victor, Giovanni, Thibaut, Fabio, Anthony, Denis, Daphnè, Medhi, Ihor, Emmanuel, Georgy, Mike, Denis. Also a big thank you to all our community that has been always supportive towards us.

We are just at the beginning of our long road to establishing our platform, and we welcome everyone to collaborate with us in our journey. We are currently raising funds, so we would be happy to join forces with anyone interested in investing in this innovative project. But we are also looking for people who want to create shows on our platform, or simply users that would like to enjoy shows. In case you have any collaboration proposal in mind, reach out to me at my e-mail tonyvt AT skarredghost DOT com or use our contact form on the website.

At the end of the day, it’s good to be building something cool with all of you. Ours is a story of success, of some little failures, but especially of a lot of work. We are not architecture astronauts, but people making their hands dirty to try to make the metaverse happen for real 🙂  Let’s do it all together.