7 Answers That Should Worry You on an AR Vendor Call
I have sat on a lot of these calls, on both sides of the table. The pattern is consistent: the demo is smooth, the deck is confident, and the answers that matter most are the ones nobody writes down.
Not because vendors lie. Mostly they answer the question you asked, and the question you asked was not the one that decides whether this ships.
So here are seven questions, the answers that should make you slow down, and what to ask instead. If you are evaluating virtual try-on or AR for a store this quarter, this is the list I would take into the call.
1. “Which kind of AR is this?” and the answer is “both”
There are two technologies wearing the same two letters, and they share almost nothing.
Object AR uses the rear camera, anchors a 3D model to the floor, and answers “will this fit in my room.” Face AR uses the front camera, anchors to face landmarks tracked frame by frame, and answers “how does this look on me.” Rear-camera surface placement has no mechanism for rendering onto a face. It is not a setting.
A vendor who says “both” without immediately splitting the answer into two product lines is either selling you a roadmap or has not thought about it. Ask which of your categories sit in which pipeline, and listen for whether the answer changes shape.
Your catalog has already decided this, by the way. Nobody chooses. A sofa cannot be tried on and a foundation shade cannot be placed on the floor. The point of knowing the difference is so nobody sells you the other one by accident.
2. “Who produces the assets?” and the answer is “we can support that”
This is the single most expensive vague answer in the category.
Object AR needs a 3D model per product, and someone has to make it. If that someone is you, your rollout speed is permanently a function of your own bandwidth, and the bill arrives per SKU with no volume discount. This is why so many stores have twenty products in 3D and then nothing. Not a failure of will. The invoices simply kept coming.
The follow-up question is the useful one: what does SKU four hundred cost, and how many days does it take? Ask it about a real number from your own catalog, not in the abstract.
For what it is worth, makeup sidesteps this entirely, because a shade is not a shape. It is region, color, finish and coverage. Four fields, not a mesh. Eyewear and jewelry do need models, and at Banuba we build those on our side, during onboarding for direct clients and automatically on the Shopify plugin and the self-service platform.
Whoever you talk to, get the answer in writing.
3. “What counts as one try-on?” and the answer is a pause
Ask this and watch the room. It is the definition that moves your bill by a factor of five, and it is almost never on a pricing page.
Is a try-on a session, a widget load, a single shade applied, or an API call? A shopper who compares eight foundation shades in one visit is either one try-on or eight, depending on the vendor. Both are defensible. Only one of them matches the model you built in your spreadsheet.
While you are there, ask what the billing unit even is. Scan a handful of app listings and you will find at least four in the same category: per try-on, per SKU, per monthly active user, per generated image. You cannot compare two plans until you convert both into the unit you actually consume.
4. “What happens above the plan cap?” and the answer is “we’ll sort it out”
Try-on traffic is not smooth. It is flat, flat, flat, then an influencer posts.
So there are two questions here, not one.
Above the cap: hard stop, overage at a stated rate, or a forced mid-month upgrade? That is the number that matters during a campaign, and it is the one most likely to be missing from the listing.
Below the cap: unused allowance is not refunded, so your real cost per try-on is the plan price divided by what you actually serve, not by what the tier includes. A plan at $349 for 15,000 try-ons is 2.3 cents at the ceiling and 8.7 cents if you serve 4,000. Your first three months will be the second number.
Get Helen Fedulova’s stories in your inbox
Join Medium for free to get updates from this writer.
“We’ll sort it out” is a fine answer from a person and a terrible one from a contract.
5. “Which engine are you licensing?” and the answer implies they wrote it
This one is for development shops, and it is the question that reprices the whole conversation.
Nobody writes face tracking from scratch. Not the agency quoting your custom build, not your in-house team, not us at the level of the underlying computer vision research. Everyone licenses or builds on an engine. What differs between a ready-made app, a dev shop and an in-house project is who integrates it and who carries it afterwards.
So a shop that talks about custom AR development without naming what sits underneath is selling you integration at the price of invention. Which may still be the right purchase, if you are outside the standard case: a native app, a platform without an app ecosystem, a white-label requirement, a flow a widget cannot express. Just buy it knowing what it is.
Two follow-ups: which engine, and have they shipped face tracking specifically rather than AR generally. A portfolio full of room-placement projects will produce a competent, good-faith quote for room placement.
6. “Can I see deep skin tones on a cheap webcam?” and the answer is the demo reel again
Every demo is a curated catalog. Five shades, one model, good lighting, one browser, and somebody who has clicked those exact buttons two hundred times.
None of that is the test. The test is warm indoor light at 11pm, a four-year-old laptop camera, deep skin tones, someone wearing glasses. The most common complaint about the first generation of try-on tools was that product color was not displayed correctly, and that taught a lot of buyers to distrust the fix as well as the problem. If a shade reads wrong, you have not delivered a rough edge, you have failed at the exact question the shopper opened the try-on to answer.
Ask about finish, not just color, because a lipstick at the right hex value with the wrong finish still reads as wrong. Matte and gloss reflect completely differently on a face.
And when it works, it is worth the trouble. Océane, a Brazilian cosmetics manufacturer and retailer, piloted on concealer and foundation, the two hardest categories rather than the prettiest, and add-to-cart went from the 3% industry average to 20.15% in the first month, later peaking at 32%.
7. “What breaks when merchandising renames a variant?” and the answer is a blank look
The unglamorous one, and the one I would read twice.
Try-on renders whatever SKU it is told to render. If the mapping between your catalog and the try-on database drifts, the widget confidently shows the wrong shade, which is worse than showing nothing, because the interface is signalling certainty while being wrong and the shopper has no way to tell.
Ask how identity is resolved, who owns the sync, and what happens when someone renames a variant on a Tuesday afternoon. In my experience that Tuesday afternoon has broken more integrations than any rendering bug.
While you are in this territory, ask whether error tracking exists before you need it rather than after.
The three questions underneath all seven
Strip the list back and it is really three things.
- Which technology does my catalog imply, so the quote matches the problem.
- Who pays for the assets, because that decides how much of the catalog ever gets covered.
- What is the unit, because everything financial downstream depends on it.
Everything else in an evaluation is negotiable. Those three are not, and none of them appear on a pricing page.
If your catalog is beauty, eyewear or accessories rather than furniture, Banuba virtual try-on is worth putting on the shortlist for four specific reasons: it renders 16 makeup product types with skin-tone-aware application so shades read correctly across skin tones, it covers makeup, hair color, eyewear, contact lenses, headwear and jewelry on one integration instead of a vendor per category, digitization is included so catalog size stops being a budget line, and it runs in the browser so your shopper installs nothing.
The no-code path starts at $49 a month with a 14-day trial, and the Shopify app installs from the App Store.
Bring your worst fifty SKUs to the demo. If it survives those, the rest of the catalog is easy.
Happy selling,
Helen
