AR & VR Development Services
Product visualisation, training simulation and industrial AR built on ARKit, ARCore, Unity and WebXR. We start from what your users already own, and we are direct about when this is the wrong tool.
When AR or VR Is Worth Building, and When It Is Not
We will start with the unhelpful-sounding part, because it saves money. A great many AR and VR projects are commissioned because the technology is interesting rather than because it solves a problem better than a photograph, a video or a good configurator. Those projects produce an impressive demo, a press mention, and no second phase.
The cases that hold up have something in common: spatial understanding is the actual difficulty being removed. Will this sofa fit in my room, and does it look right there. Can a technician be trained on a procedure that is dangerous or expensive to rehearse for real. Can an engineer see the maintenance history of the pump they are standing in front of without going back to a terminal. Can a buyer understand a building that has not been constructed. In each of those, flat media genuinely fails to answer the question.
The counter-test is simple. If a well-shot video or an interactive 2D configurator would answer the user's question about as well, build that instead. It will cost less, reach everyone, and need no explanation. We would rather tell you that in a scoping call than six weeks into a build. It costs us a project occasionally, and it has never once cost us a client, because the alternative is an invoice attached to something nobody uses twice.
What We Build
Product visualisation and AR try-before-you-buy
The most commercially proven category. A customer points their phone at a room and sees the furniture, the appliance or the fixture at true scale, in their own space, in their own light. It reduces the return rate on exactly the products where returns are most expensive to process, because the mistake it prevents is a sizing or a suitability mistake.
The engineering is mostly plane detection, correct real-world scale, and lighting that makes the object sit convincingly in the scene rather than float above it. The harder part is operational: every product needs a 3D model, models must be optimised enough to load over mobile data, and the experience has to know current price, stock and variant. An AR viewer that shows a discontinued colour is worse than no AR viewer.
Training and simulation
Where rehearsing something for real is dangerous, expensive or impossible to schedule, VR earns its cost quickly. Electrical safety procedures, machine operation, emergency response, clinical technique, working at height. The trainee can fail safely and repeat immediately, which is the pedagogical point.
Good training builds are assessed builds. If the system cannot record what the trainee did, where they hesitated and whether they completed the procedure correctly, it is an experience rather than a training tool, and it will not survive a compliance conversation. So we design the scoring and reporting alongside the simulation, and integrate it with whatever learning system already holds your records.
Industrial and maintenance AR
A technician looks at equipment through a phone, tablet or headset and sees overlaid information: the service history, the next step of the procedure, sensor readings, which valve to close. The value is in not breaking attention to consult a manual while standing in front of the machine.
This is the category most dependent on integration rather than on graphics. The overlay is only as useful as the maintenance and telemetry data behind it, so the work is largely about connecting to the systems that hold that data reliably enough to be trusted in the field, including when connectivity is poor. Recognition also has to hold up in real conditions, which means dealing with equipment that is dirty, poorly lit or partly obscured, not the clean example in the datasheet.
Remote assistance and see-what-I-see
A field technician shares their camera with a specialist elsewhere, and the specialist annotates what they are looking at: circle this connector, point at that gauge, draw an arrow to the release catch. The annotations stay anchored to the object as the camera moves, which is what separates this from a video call.
The business case is usually travel and downtime rather than novelty. One senior engineer can support many sites in a day, and a machine stops being down while somebody drives to it. The engineering work is anchored annotation, tolerable behaviour on poor connections, and a session record so what was diagnosed is not lost when the call ends. It is one of the shorter paths to a measurable return in this category, because the thing it replaces has an invoice attached.
Architectural and property walkthroughs
Buildings that do not exist yet are difficult to sell from drawings, and the people signing are often not trained to read them. A walkthrough lets a buyer or a committee understand scale, sightlines and flow in a way a floor plan does not.
Most of the effort here is asset preparation. Architectural models come from CAD or BIM and are built for accuracy rather than real-time rendering, so they arrive with far too much geometry and no usable materials. Converting them is a defined craft: reducing geometry without losing the silhouette, rebuilding materials, and baking lighting so it looks right at a stable frame rate on the target device.
WebXR, when reach matters more than depth
An installed app is a real barrier. WebXR runs in the browser, so a link in an email or a QR code on packaging gets someone into an AR experience with nothing to download. That is a large advantage for marketing, retail and anything with one-time use.
The trade-off is honest: browser AR gives less tracking capability and less performance headroom than a native app, and support varies by device and browser version. For a product viewer it is usually enough. For a training simulation with physics and long sessions it is not. We will tell you which side of that line your use case falls on before you commit.
How We Approach an AR or VR Project
1. Test the premise first
Is spatial understanding the real difficulty, and would flat media answer the question about as well? An honest answer here is worth more than an enthusiastic one, and occasionally it ends the project before it costs anything.
2. Decide the hardware from the audience
What do your users already have, and who pays for anything they do not? Consumer use cases point at phones; supplied-hardware training points at headsets. This decision constrains everything after it.
3. Audit the 3D assets honestly
What models exist, what state are they in, and what will it cost to make them real-time ready? This is usually the largest line item and the most underestimated, so we scope it separately from engineering.
4. Prototype the core interaction
Build the one moment the product depends on and put it on the target device early. Spatial interaction cannot be evaluated from a video or a document; it has to be held.
5. Treat performance as a requirement
A frame-rate budget set at the start and measured on the oldest device you intend to support. In VR this is a comfort and safety matter, not a quality setting, and it cannot be fixed at the end.
6. Plan the integration and the content pipeline
How live data reaches the experience, and how your team adds the next fifty products or the next procedure without calling us. A build nobody can extend is a pilot with a longer invoice.
Where This Fits With Our Other Work
Because the premise deserves testing before the budget is committed, most of these projects should begin with wireframing and prototyping, and the visual and interaction design side is UI/UX design. Where the experience must show live pricing, stock or maintenance data, that connection is enterprise integration work and it is usually the part that decides whether the project reaches production.
Where AR is a feature inside an app you already have, Flutter or React Native developers handle the surrounding application, and device-connected experiences pair with firmware development. If the wider question is where immersive technology belongs in your plans at all, a technology roadmap answers that more cheaply than a build does.
Frequently Asked Questions
What is the difference between AR, VR and mixed reality?
Augmented reality overlays digital content on the real world, usually through a phone camera, so the user stays in their environment. Virtual reality replaces the environment entirely with a headset. Mixed reality blends the two, with digital objects that understand and respond to real surfaces. The distinction matters commercially because it decides the hardware your users need, and therefore how many of them can actually use what you build.
Should we build AR for phones or for a headset?
For anything customer-facing, phones, almost always. Your customers already own one, which removes the biggest barrier to adoption. Headsets make sense for training, simulation and industrial use where the organisation supplies the hardware and the session is long enough to justify putting it on. A consumer product that requires a headset purchase is selling two things instead of one.
Do you build in Unity or with native AR frameworks?
It depends on the app. Unity suits 3D-heavy experiences, simulation and anything needing physics or shared content across platforms. Native ARKit and ARCore suit a focused AR feature inside an existing app, where embedding a Unity runtime would add substantial size and complexity for one screen. WebXR suits reach over depth, since it runs in a browser with nothing to install.
What makes VR uncomfortable for users, and how do you avoid it?
Mostly a mismatch between what the eyes see and what the body feels, plus dropped frames. The countermeasures are a stable frame rate treated as a hard requirement, avoiding camera movement the user did not initiate, teleport or comfort-mode locomotion as the default rather than smooth motion, and a fixed reference point in the field of view. Comfort is an architectural constraint in VR, not a polish item.
What does an AR or VR project realistically cost to run?
The dominant variable is 3D content, not code. If you already have usable models from CAD, product photography or an asset library, the project is far cheaper. If models must be created and optimised for real-time use, that becomes the largest line item, because CAD geometry is almost never usable as-is and has to be retopologised and baked. We scope content separately from engineering so you can see which is which.
Can AR work with our existing product catalogue and systems?
Yes, and it should. An AR product visualiser that does not know live pricing, stock or variants is a demo rather than a feature. That means integrating with the commerce platform or ERP, and having a defined answer for products with no 3D model yet. Treating the integration as part of the project from the start is the difference between something that ships and something that stays in a pilot.