What Augmented Reality is, and what it is not
Augmented Reality places digital content into a view of the real world, registered to real surfaces and objects, without replacing that view.
The registration is the part that matters commercially. A digital object that holds its position against a shelf, a machine or a face is doing something a video overlay cannot, and it is the tracking that carries the engineering cost. An experience that simply floats a graphic over a camera feed is a filter, and the two are priced very differently even though a buyer often describes both as Augmented Reality.
Augmented Reality is not Virtual Reality, which replaces the view entirely. It is not Mixed Reality either, though the boundary there is genuinely blurred. Mixed Reality implies the digital content understands the geometry of the room and responds to it, rather than only being anchored to a point in it. Buyers routinely arrive using all three terms for the same project, and the first job of a serious scoping conversation is to settle which one the work actually requires.
What hardware ships today
Most enterprise Augmented Reality delivered today runs on a smartphone the customer already owns, not on a headset.
That single fact reshapes a budget more than any other. A phone-based build reaches a large audience with no hardware line at all, which is why campaign and retail work concentrates there. A headset build reaches far fewer people, and adds procurement, provisioning, charging, cleaning and device management to a project that a buyer costed as software.
Within phone-based work there is a second split, between a native app and the browser. Web-based Augmented Reality removes the install step, which is decisive for anything a member of the public meets once. A native app justifies itself when the experience needs performance, offline capability or deep access to the device that the browser does not grant.
Headset and glasses hardware moves too quickly for a register page to quote a list price responsibly. Prices change without notice, differ by region and are frequently discounted, so the honest instruction is to price the specific configuration with the manufacturer at the time of the build rather than to trust a figure published months earlier. What is stable is the shape of the decision: the device class determines the audience, and the audience determines whether the project is a campaign or a deployment.
What enterprises actually deploy
Published Augmented Reality work concentrates in retail, brand activation and product demonstration far more than in the industrial use cases the category is usually pitched on.
That is a claim the register can support directly, because every record traces its case studies to a public source. Reading across the studios currently on record, the pattern is consistent, and it is worth setting against the assumption that Augmented Reality is primarily a field-service technology.
Consumer and retail work dominates. Aircards publishes web-based activations for Nike, Louis Vuitton and Sephora, all reached through a browser rather than an install. FFFACE.ME documents in-store work including an Augmented Reality mirror for Nike at JD on Oxford Street and a retail activation for Bershka. The common thread is a short, high-traffic engagement where the install step would have killed the conversion.
Product demonstration is the second cluster, and it behaves differently. Draw & Code publishes work for Toyota and Mercedes-Benz Vans where the object being shown is large, expensive or impossible to bring into the room. These projects tend to be longer lived than a campaign, because the asset produced has a use beyond a single event.
What the published record does not support is the industrial maintenance narrative. Very little remote-assistance or field-service work appears in public case studies relative to how often the use case is described in vendor material. That absence is worth stating plainly rather than writing around, and a buyer scoping industrial Augmented Reality should ask directly for delivered examples rather than capability claims.
What drives the cost of a build
No credible public source publishes what an Augmented Reality project costs, and this register does not publish one either.
That is a deliberate position rather than a gap. Price data on studio directories is almost always self-reported through a submission form, which makes it a marketing figure rather than an observation, and a register that ranks on public evidence cannot launder a self-reported number into a fact. What can be stated is what moves the number, which is more useful to a buyer preparing a budget than a range with no basis.
Four things drive the cost of an Augmented Reality build more than anything else.
- Asset production. Three-dimensional models are usually the largest line and the one buyers underestimate most. A catalogue of a hundred products is a hundred modelling jobs, and existing CAD rarely converts cleanly to something a phone can render in real time.
- Tracking difficulty. Anchoring to a printed marker is inexpensive. Anchoring to a face, a body, a moving product or an unprepared room is not, and accuracy requirements drive this cost far faster than visual quality does.
- Integration depth. An experience that stands alone is a fraction of the cost of one that reads live inventory, pricing or customer data. The integration is frequently the critical path, and it usually sits with the client rather than the studio.
- Device and platform spread. Every additional target multiplies testing rather than adding to it. Supporting two platforms is materially more than twice the work of supporting one, because the defects appear at the boundaries.
A useful discipline is to ask a studio which of those four dominates the estimate. A studio that has delivered will answer immediately and specifically. One that has not will answer with a total.
How long a build takes
Timeline in this category is governed by asset production and client-side integration, not by application development.
This is the most common scoping error. Buyers plan around the engineering effort they can see and then lose a quarter waiting for product data, brand approval or access to a system the integration depends on. The application is often the shortest pole.
Sequence matters more than duration. Asset production can begin before the application exists, and it usually should, because it is the line most likely to slip. Integration work should start with a written contract about the data, since discovering that live inventory is not queryable in the way everyone assumed is a mid-project discovery that resets a schedule.
The register does not hold delivery timelines, because studios do not publish them consistently enough to compare. A buyer should treat any timeline quoted before the asset and integration questions are settled as an estimate of the software alone.
How to assess a studio
Ask for delivered work in your scope, then check whether the work is described by client or by feature.
This is the single most efficient filter, and it is the one this register applies before a company is eligible at all. A studio that organizes its work section by client and describes what was delivered is showing evidence. A studio that organizes by capability and describes what it can do is showing a brochure. The distinction separates the two populations quickly, and the methodology behind that standard is published in full so a buyer can apply it independently.
Three further checks are worth the time.
Verify the credential at its source rather than on the studio's own site. A platform partner badge should appear in the platform's own directory, and an award should appear in the award body's announcement. Both are trivially checkable and are asserted more often than they are held.
Ask which platform the delivered work actually shipped on. Capability pages list every platform a studio would accept work on. Case studies name the one a project ran on, and the gap between those two lists is frequently large.
Ask who owns the assets when the engagement ends. Three-dimensional models produced for a build have value beyond it, and ownership is easier to settle before the work than after.
What the published record does not tell you
Most published Augmented Reality case studies do not name the device the work ran on, and almost none say when it shipped.
Across the case studies this register documents, roughly one in nine names a target platform and around one in twenty carries a date. That is a disclosure pattern rather than a research gap, because the same studios publish client names freely: about three quarters of the corpus names the client. Studios treat the brand as the credential and the technical target as detail.
Two things follow for a buyer. A portfolio cannot be read as evidence of experience on a specific handset, headset or browser stack unless the case study says so, and the absence is common enough that asking directly is normal rather than adversarial. Recency cannot be read either, so a portfolio that looks current may document work several years old.
This register records platform only where a third party attests that delivered work ran on it, which is why platform coverage here is thin rather than generous. The rule and its tiers are set out in the methodology. A studio naming its own capability is not evidence that anything shipped on it.
Further published work in this category
The Augmented Reality record in the register is broadest in brand activation and retail, and it thins quickly outside them.
Aircards publishes campaign work including an out-of-home campaign for e.l.f. Cosmetics and a loyalty activation for Delta Air Lines, which between them cover the two commissioning patterns in this space: a campaign with a fixed run and a programme attached to an existing customer account. The second is the harder build, because it has to survive contact with systems the studio does not own.
Education and workforce entry are a smaller but steadier group. Bit Space Development publishes Trades Town, built with the Manitoba Construction Sector Council, which is commissioned by a sector body rather than by a brand. That commissioning route changes the evidence a studio is asked for, because a public body usually wants a stated learning objective where a brand wants reach.
Where these projects fail
Augmented Reality projects fail most often on distribution rather than on the build.
The application or experience works, and too few people open it. A campaign that depends on a shopper scanning a code in a store depends on store staff placing the code, on the print run carrying it and on the shopper having a reason to try. None of those are engineering problems and all of them sit outside the studio's control, which is why a launch plan belongs in the scope rather than after it.
The second failure is a tracking assumption that does not survive the real environment. Marker-based work needs the marker to be present, lit and undamaged. Surface tracking needs texture and stable lighting. A demonstration recorded in a studio proves the software runs and proves nothing about a shop floor at closing time or an outdoor site in rain, and the gap between the two is where pilots quietly stall.
Third, asset ownership is settled too late. A retailer with a hundred products and no usable three dimensional models has a content problem rather than a technology problem, and content is usually the larger number. Deciding who produces, owns and updates the assets before the build starts prevents a working application that cannot be extended.
Where to go next
Every studio referenced here is on the public record with its sources and its verification date. The complete list of studios delivering this work, ranked and filterable, is the Augmented Reality development register.
Scoped rankings sit against a service, an industry, a use case or a location rather than against the category as a whole, because a studio strong in retail activation is not thereby strong in industrial training. There is no single best Augmented Reality company, and any list presenting one is answering an easier question than the buyer asked. Most of the other pillars on this site document the same suppliers from a different angle, which is worth knowing before a shortlist is drawn. Nearly every studio delivering Augmented Reality work also delivers Virtual Reality development, and most of them deliver Mixed Reality development as well. A shortlist assembled here will rarely be specific to one technology, so the choice of technology is better settled against the problem than against the supplier list.
Two use cases account for most of the published Augmented Reality work in the register. Training and simulation is the deeper of the two and product visualization is the more commercially direct. By sector, the register documents more Augmented Reality work in healthcare and in retail and ecommerce than anywhere else, and both sectors impose constraints that do not travel between them.
