AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms
Senior only
Engineers on every build
3D, tracking, and backend — no junior bait-and-switch
US-based
Team, start to finish
No unnamed subcontractor added mid-project
Day one
You own the repo and the assets
Code, 3D models, and store accounts, from the first commit
10 biz days
To start
From a signed scope to the first sprint
The XR spectrum
AR, VR and mixed reality are three different engineering problems
The terms get used loosely in a pitch and precisely in engineering, which is where scopes go wrong. The distinction that actually matters is how much of the real world the system has to understand — and it decides everything downstream: the device, the SDK, and how the budget splits between code and 3D content.
Virtual reality (VR)
A fully synthetic environment, viewed through a headset. You control everything in frame, which makes the hard problems performance and comfort rather than tracking — drop below roughly a 90fps floor and users start to feel it, not just see it.
Augmented reality (AR)
An overlay composited onto a live camera feed, running on phones people already own. There's no hardware to buy, which is the whole commercial advantage, but the engineering problem shifts to tracking: the device has to agree with reality, frame by frame, or the overlay swims.
Mixed reality (MR)
Virtual objects that can be occluded by, and interact with, real geometry — a wrench that visually disappears behind a real engine block instead of floating in front of it. That requires depth sensing and spatial mapping, and it's a step change in cost over overlay AR, not an incremental one.
When VR is the right call
Training, simulation, and anything where the real room around the user is a distraction from the task. If the value is in controlling the entire environment, VR is usually the honest answer.
When AR is the right call
Reach matters more than fidelity, and users already carry the hardware. Skipping a device purchase is the whole pitch — don't spend the savings building features that only make sense in a headset.
When MR earns its cost
Only when interacting with real, physical objects is the actual product — maintenance guidance on a real machine, surgical planning against a real body — not when the same virtual content would work just as well floating in front of the camera as a plain AR overlay.
What it costs
AR/VR engagement types
Real ranges for the engagements we're actually asked to run. The variable that moves a quote is rarely the code — it's how much of the budget has to go into 3D content, and how much device-specific tracking work the platform demands.
| Engagement | Commitment | Timeline | What's included |
|---|---|---|---|
| AR proof of concept | Fixed scope | 2 – 4 weeks | A single tracked scene or feature on a phone, built to answer one question: does the overlay actually work against your real-world target. |
| AR product build (ARKit / ARCore) | Fixed scope | 8 – 14 weeks | A full native AR app with real tracking, basic occlusion, and app store submission handled end to end. |
| VR training or simulation build | Fixed scope | 10 – 16 weeks | A headset application with interaction design, scenario branching, and deployment to the target device store. |
| Mixed reality build | Fixed scope | 14 – 20+ weeks | Spatial mapping, real-object occlusion, and integration with a device-specific SDK, plus the extra QA pass MR needs across lighting conditions. |
| Ongoing 3D content and maintenance | Ongoing retainer | Ongoing | New assets as the product line grows, plus OS and SDK updates as headset and phone platforms ship new hardware. |
Ranges assume US-based senior engineers and a 3D artist on the team from week one, not brought in after the prototype. The cost driver nobody forecasts going in is content, not code: software gets built once, and the 3D model library gets extended for as long as the product ships.
What's actually shipping
The AR/VR use cases that have survived past the hype cycle
Extended reality has been through several rounds of overpromising. The use cases below are the ones that kept getting funded after the novelty wore off, because the return was measurable against the alternative.
Training and simulation
Practicing on equipment that's too dangerous, too expensive, or too rare to use for training — an aircraft, a piece of industrial machinery, a medical procedure. The alternative is either real equipment sitting idle for training or no practice at all, and VR beats both.
Remote assistance
An overlay that shows a technician exactly where to look and what to do, hands-free, while an expert watches remotely. It replaces flying a specialist to a site or walking someone through a repair over a phone call with a mental model of a part they can't see.
Product visualization before manufacture
Seeing a design at scale, in context, before committing to tooling or a production run. This is one of the clearest returns in the category because the alternative — a physical prototype — is genuinely expensive to iterate on.
Consumer entertainment is still hardware-gated
This is the honest exception. If a business case depends on headset install base, treat the adoption timeline as a real risk to plan around, not an assumption to build the schedule on — the other three use cases above don't carry that dependency.
The 3D pipeline is the real cost center
Asset production, level-of-detail variants for performance, and updating models as a product line changes are ongoing work in a way the application code usually isn't. Budget it as a pipeline with a person attached, not a one-time deliverable.
Choosing a partner
What actually separates one AR/VR team from another
Most pitches sound the same. These are the questions worth pressing on before you commit a budget to a headset or a phone-based build.
Quality and testing discipline
Ask what the QA pass actually covers — for AR that means testing tracking against real-world lighting and surfaces, not just a demo reel shot in a controlled office.
Resources and capacity for your timeline
Team size and current workload matter more here than in most software categories, because 3D content and engineering are two different skill sets that both have to be staffed, not one team wearing both hats badly.
Communication as a working relationship, not a status report
You should be able to see a build running on a real device at the end of each sprint, not a rendered video of one. A device you can hold catches problems a video hides.
Engine and platform choice
Unity and Unreal both cover cross-device VR and MR; native ARKit or ARCore is usually the right call for a phone-only AR product where you don't need the overlay to feel game-like. WebXR is worth asking about when reach — no install, works in a browser — matters more than depth of feature.
Device and OS coverage
Quest, Vision Pro, and HoloLens each have real differences in SDK, input model, and review process. A team that's only ever shipped to one of them will underestimate the second platform's learning curve.
Who owns the 3D pipeline after launch
If the only person who can open the source files leaves with the agency, every future asset update starts from a rebuild. Ask where the working files live and whether they're yours by default.
How an engagement runs
From concept to a build you can test on a device
Extended reality projects fail more often on the workshop and content side than on the code, so the process below front-loads exactly that rather than jumping straight to a build.
Identification and analysis
Understanding the actual goal — training, visualization, remote assistance, or something else — and analyzing the shortest real path to it, including whether the honest answer is AR on a phone rather than a VR headset build.
Collaborative workshopping
Working through the experience together rather than presenting a finished concept, because the constraints of the target device usually change the idea once they're on the table.
Design and development
Building the core experience against an agreed scope, in parallel with the 3D asset pipeline so content isn't waiting on code or code waiting on content.
Testing
Testing on the actual target hardware, in the actual conditions the experience will be used in — a warehouse floor, an operating room, a showroom — not just a desk in an office with ideal lighting.
Launch
Shipping to the app or device store, or to the internal distribution channel a training or enterprise deployment actually uses.
Correction and support
Launch is the start of the asset pipeline's life, not the end of the engagement — new content, device updates, and fixes as real usage surfaces edge cases a demo never hit.
Related
Related services
What AR/VR projects usually need alongside the experience itself.
Questions
AR/VR questions we get before scoping a build
What teams ask before a first call.
VR replaces what you see; AR adds to it. In VR you wear a headset and the environment is entirely synthetic, so the engineering problems are rendering performance and motion comfort. In AR the device composites graphics onto a live camera feed, so the engineering problem is tracking — knowing precisely where the device is relative to the world, many times a second.
Commercially the difference is reach. AR runs on phones your users already carry. VR requires buying hardware, which turns a software decision into a procurement one.
Mixed reality is AR with real geometry understood well enough that virtual objects can be hidden behind real ones and can respond to real surfaces. That requires depth sensing and spatial mapping, which is a step change in cost over overlay AR.
It earns that cost when interacting with physical objects is the point — maintenance guidance on a real machine, surgical planning against a real body. It does not earn it when the virtual content would work just as well floating in front of the camera.
The durable use cases are training and simulation, remote assistance, and product visualization before manufacture — all cases where the alternative is expensive physical setup. Those have survived several hype cycles because the return is measurable.
Consumer entertainment remains hardware-gated. If a business case depends on headset install base, treat the timeline as a risk rather than an assumption.
Overlay AR on existing phones is closer to the cost of a normal mobile app plus the tracking work. VR and mixed reality run higher because 3D asset production, performance budgets, and comfort testing are all real line items with no equivalent in a standard app.
The cost driver nobody forecasts is 3D content. Software gets built once; the model library gets extended for as long as the product line grows.
If the goal is visualization, wayfinding, or an overlay that guides a task, phone-based AR usually gets there without asking anyone to buy hardware — that's the whole advantage of building on ARKit or ARCore instead of a headset SDK.
A headset becomes the right call when the environment itself needs to be replaced (VR) or when the interaction depends on depth and hands-free use in a way a phone screen can't support (MR). We'll tell you which one your actual use case needs before scoping the build, not after.
It depends on the target. Unity and Unreal both cover cross-device VR and MR work well and are the default for anything that needs to run on more than one headset. For phone-only AR, native ARKit or ARCore is often the better choice because it avoids an engine's overhead for an overlay that doesn't need game-style rendering.
WebXR is worth considering when reach matters more than feature depth — it runs in a browser with no install, at the cost of some tracking fidelity compared to a native build.
You do. Source code, the 3D asset working files, and any store or device developer accounts should be registered under your own organization from day one, with us added as a developer or collaborator — not the other way around.
If the only copy of a working 3D file lives on a contractor's machine, every future update starts from a rebuild instead of an edit. Confirm where the source files live before the project starts, not after the relationship ends.