How Should a VR Developer in Spain Show WebXR, Quest Builds, and Private Client Demos?
A VR developer should present each distinct immersive experience as one project, explain the interaction and their contribution, and provide the safest accessible proof available: a WebXR demo, store page, approved video, repository, or case study.
A reviewer may not own the target headset, have access to a private build, or know which part of an installation you made. The portfolio therefore has to translate spatial work into a clear experience, platform, role, and review path without redistributing client binaries, licensed assets, recordings of participants, or credentials.
Which VR and WebXR projects deserve separate entries?
Create separate entries for experiences with different goals, platforms, audiences, or evidence, such as a public WebXR demo, Quest app, training simulation, installation, interaction prototype, or reusable tool.
State what the user does, target hardware or browser, your role, and the shipped or tested artifact. Separate interaction design, Unity or Unreal development, 3D art, audio, backend, hardware integration, and production when the project was collaborative.
Keep platform variants together when they are ports of one experience. Split them only when the interaction, maintenance, ownership, or proof is genuinely independent.
- Public WebXR: direct demo with fallback context.
- Store app: current canonical listing.
- Private build: approved capture or anonymised case.
- Prototype: label its tested scope and current status.
What is the fast way to assemble the VR portfolio with IndieShow?
The fast way is to create one IndieShow card per immersive experience, assign its real status, and point to the most accessible safe evidence rather than forcing every reviewer to install a build.
Use the description for experience goal, platform, interaction, and contribution; use the tag for WebXR, Quest, Unity, training, installation, or another precise context. Only add a metric when it is approved and meaningful.
Order projects for the opportunity and check the private preview on desktop and mobile. The IndieShow page explains the collection before visitors open a browser demo, video, store page, or technical repository.
Build your IndieShow pageClaim your handle, organise the projects in the editor, then review the $15 one-year and $30 lifetime publishing options in the dashboard.
How can a headset-only or private experience be demonstrated?
Demonstrate it with an approved first-person capture, spectator view, interaction breakdown, synthetic build, public trailer, or case study that shows the experience without sharing private binaries or accounts.
Explain capture limitations such as edited sequences or simulated inputs. Never publish client builds, participant recordings, biometric or telemetry data, internal device-management URLs, access codes, or licensed assets without permission.
Provide captions or a written description so someone without the headset can understand the task and your contribution. Accessibility of the portfolio proof is separate from accessibility inside the experience.
How should prototypes and shipped immersive products be labelled?
Label prototypes by what was tested and products by their actual release state, and do not let polished capture turn an internal experiment into a claimed commercial launch.
Use Building or Working on for active development, a shipped grouping for released work, and Archived for retired demos or unsupported hardware. Update store and demo links when platform policies or hosting change.
Credit assets and team roles accurately. The related guides cover separating hackathon prototypes and presenting specialist 3D contributions.
Related IndieShow guides: crediting 3D and engine work accurately · separating prototypes from shipped products
Why does IndieShow fit a VR developer portfolio?
IndieShow fits because it gives headset apps, browser experiences, installations, tools, prototypes, and archived builds one scannable public page with a controlled destination for each.
A concise card can establish platform, purpose, role, status, logo, and optional approved metric before the visitor chooses the evidence format they can access.
Use IndieShow as the final map of the immersive work; store listings, captures, demos, repositories, and authorised cases remain the detailed proof.
Frequently asked questions
Which VR and WebXR projects deserve separate entries?
Create separate entries for experiences with different goals, platforms, audiences, or evidence, such as a public WebXR demo, Quest app, training simulation, installation, interaction prototype, or reusable tool.
What is the fast way to assemble the VR portfolio with IndieShow?
The fast way is to create one IndieShow card per immersive experience, assign its real status, and point to the most accessible safe evidence rather than forcing every reviewer to install a build.
How can a headset-only or private experience be demonstrated?
Demonstrate it with an approved first-person capture, spectator view, interaction breakdown, synthetic build, public trailer, or case study that shows the experience without sharing private binaries or accounts.
How should prototypes and shipped immersive products be labelled?
Label prototypes by what was tested and products by their actual release state, and do not let polished capture turn an internal experiment into a claimed commercial launch.
Why does IndieShow fit a VR developer portfolio?
IndieShow fits because it gives headset apps, browser experiences, installations, tools, prototypes, and archived builds one scannable public page with a controlled destination for each.