TL;DR: The fastest way to choose an XR development company is to ignore the showreel and ask for three things: a build running on the device you actually plan to use, a named person for each discipline your project needs (engine development, 3D art, interaction design, on-device QA), and a written plan for the first four to eight weeks that ends in something you can put on a headset or phone. Good XR studios scope a proof of concept before a full build, test on real hardware every week, talk openly about comfort and performance, and hand over source code and source assets. Weak ones sell renders, promise every platform at once and treat 3D content as somebody else's problem. This guide covers what to check, which questions separate the two, and the red flags worth walking away from.
Hiring a team for a web or mobile app is hard enough. Hiring one for augmented, virtual or mixed reality is harder, because most buyers have less experience judging the work. A polished trailer looks the same whether it came from a real-time application running at a steady frame rate on a standalone headset or from an offline render that took a day per minute. A demo in someone else's office tells you little about how the same team handles your device, your content and your users.
This article is for founders, training leads, innovation teams and product owners who are about to commission an AR, VR or MR build and want to choose a partner on evidence. It is written by a studio that does this work, so read it with that in mind; the checks below apply to us as much as to anyone.
Start with what you are actually buying
Before comparing vendors, get clear on which kind of XR project you have, because studios that are excellent at one can be ordinary at another.
- Phone AR for the public. Product visualization, packaging, campaigns, location-based experiences. Reach and load time dominate. See web AR without an app and location-based AR.
- Headset training and simulation. Scenario design, assessment, instructor controls, fleets of shared devices. See VR training for high-risk teams and enterprise XR rollout.
- Clinical or measurement tools. Sensor accuracy, validation and data handling matter more than visuals. See clinical VR diagnostics.
- Shared or multi-user spaces. Networking, shared anchors and session management. See mixed reality collaboration.
A studio with a reel full of marketing AR filters may not have shipped a headset application that runs for an hour without overheating. A team that builds excellent training sims may never have fought a tight page-weight budget for a browser experience. Ask which of these categories their last three shipped projects fall into.
If you have not written down the basics yet (users, device, environment, what success looks like), do that first. Our software project brief guide covers what to include, and every serious vendor will give you a better answer from a page of clear context than from a one-line idea.
Check 1: Running builds, not videos
The single most useful request you can make is: "Can we try something you built, on a device, ourselves?"
Video hides everything that makes XR hard. It hides frame drops, tracking drift, uncomfortable locomotion, text you cannot read at arm's length, controls that only make sense to the people who built them, and load times. Putting on a headset or opening an AR link on your own phone surfaces all of that in two minutes.
Some client work is under NDA, and a studio may not be able to share it. That is fair. In that case ask for an internal demo, a public app or a short live session where they run a build and you watch the device output and the performance overlay. A team that cannot show you any running software at all is asking you to fund their learning.
What to notice while you try it
- Comfort. Did anything make you queasy, or did movement feel natural? Our VR motion sickness guide explains what good teams design around.
- Readability. Could you read the interface without leaning in?
- Onboarding. Did you know what to do without someone explaining it over your shoulder? Good XR interaction design makes the first minute obvious.
- Stability. Did objects stay where they were placed? Did the app recover if you looked away or stepped back?
Check 2: The team behind the reel
XR is several crafts at once. A credible team can name who covers each of these on your project, even if one person wears two hats on a small build:
- Engine development. Unity, Unreal or a native framework, chosen for your device and needs rather than by habit. Our XR engine comparison covers that decision.
- 3D art and technical art. Modeling, optimization, materials and the pipeline from source files to a lightweight runtime asset. Content often takes as much effort as code. See the XR 3D content pipeline.
- Interaction and UX design specific to XR. Flat-screen UX instincts do not transfer cleanly into a headset.
- QA on real hardware. Testing in the editor is not testing. Someone has to put the device on, repeatedly, across the builds that matter.
- Backend and integration, if the experience needs accounts, analytics, an LMS, a CRM or live data.
Ask who will actually be working on your build, and how much of their week it gets. If the person who impressed you in the sales call disappears after signing, that is worth knowing in advance.
Check 3: Device and platform honesty
A strong XR partner will challenge your device choice before agreeing to it. Ask why they would or would not pick a given headset or phone for your users, environment and budget. A useful answer covers comfort, battery life, enterprise device management, input options, availability in your region and how long the hardware is likely to be supported. Our XR headset selection guide lays out those trade-offs.
Be cautious with "we'll ship on every headset and phone at once." It is possible to target several platforms, but each one adds testing, performance tuning and input differences. A good vendor will tell you which platform to ship first, what porting to a second one would involve and what it would cost, rather than folding all of it into a single optimistic line.
Check 4: How they scope the first phase
The best sign of an experienced XR team is that they want to prove the riskiest assumption cheaply before you commit to a full build. That usually means a short proof of concept: one scenario, one product, one location, on the real device, with real users trying it. We cover how to structure one in the XR proof of concept guide.
Ask for a written outline of the first phase that includes:
- What exactly will exist at the end, and on which device.
- Which assumption it tests (tracking in your space, comfort for your users, performance with your content, whether people actually use it).
- What you need to provide: 3D source files, subject matter experts, access to a site or a test group.
- What decision you will be able to make afterwards.
Then ask how they price it. Fixed price suits a tightly defined proof of concept; time and materials often suits the open-ended work that follows. Our fixed price vs time and materials comparison explains when each one protects you, and what an XR app costs breaks down the drivers.
Check 5: Ownership, data and what happens after launch
These questions feel administrative, but they decide how much control you have in two years.
Source code and source assets. You should own both, including the original 3D files, not only the compressed runtime versions. Without the sources, every future change routes back to the original studio. Our software ownership and handover guide lists what a complete handover includes.
Data. Headsets and AR sessions can capture camera feeds, room geometry, voice, movement and sometimes eye tracking. Ask what the app collects, where it goes and who can see it. See XR data and privacy for the questions that matter.
Maintenance. Headset firmware, operating systems, engines and app stores change on their own schedule. Ask how the vendor handles updates after launch and what a support arrangement looks like. XR app maintenance covers what tends to break and why.
Red flags worth walking away from
- Every portfolio item is a video and nothing can be tried.
- No questions about your users, environment or device before a quote arrives.
- A price for the full build with no first phase or proof of concept.
- Comfort and frame rate never come up unless you raise them.
- 3D content is assumed to "come from the client" with no discussion of format, quality or optimization.
- Testing happens "in the editor" or "at the end."
- Source files and assets are not part of the deliverables.
- Claims of guaranteed learning outcomes, sales lifts or ROI figures before anything has been built or measured.
Questions to ask on the first call
- What are the last three XR projects you shipped, on which devices, and can we try any of them?
- Who will work on our build, in which roles, and how much of their time is ours?
- Which device would you recommend for our case, and what would make you change your mind?
- What would the first four to eight weeks produce, and what would we learn from it?
- How will you prepare and optimize our 3D content, and what do you need from us?
- How often will we get a build on a real device?
- What does the app collect about users, and where does that data live?
- Do we receive full source code and source assets at the end?
- What does support look like after launch, when the headset or OS updates?
A team that answers these clearly and specifically is probably one you can work with. A team that answers with adjectives probably is not.
Where Null Studio fits
We are an AI-native software studio, and XR is one of the three areas we build in alongside AI automation and custom software. Our XR work includes ERIS XR for ARCortex, an emergency response platform that helps firefighters pre-plan and train by blending digital and physical spaces in real time; Planes XR, also for ARCortex, location-based AR connected to OpenSky that places real aircraft in the real sky using live data; Nystag, VR eye-tracking diagnostics on the Vive Focus 3 for clinical assessment; and MR Camera, a multiplayer mixed reality environment where several people place and interact with 3D models in the same space.
That mix covers phone AR, standalone headsets, clinical measurement and shared spaces, which is why we ask early which kind of project you have. When the right answer is a small proof of concept rather than a big build, we say so. When we think another kind of team would serve you better, we say that too. If you need XR engineers to join an existing team rather than a studio running the whole project, talent augmentation is the other way we work.
The bottom line
Choosing an XR development company comes down to evidence you can touch. Try their running builds on a device. Meet the people who will do the work. Push on device choice, comfort and content before price. Insist on a short first phase that tests your riskiest assumption, and make sure you own the code and assets at the end. A partner who welcomes those checks is usually the one worth hiring.
Evaluating XR partners for an AR, VR or mixed reality project? Book a demo and we'll walk you through running builds, our process and an honest first-phase plan for your idea. See our XR work: ERIS XR and Planes XR for ARCortex, Nystag clinical VR eye-tracking, and MR Camera shared mixed reality.