Wine Label Scanner Apps: How AI Sommeliers Work and What It Takes to Launch One

Point a camera at a wine label and get back the region, the grapes, the style, what it should taste like, how cold to serve it and what to eat with it. It is one of the cleanest uses of on-device vision and a language model together, and it solves a genuinely common moment: standing in front of a shelf of bottles you know nothing about, with a meal in mind and no idea which one fits. The interesting part of building one is not the scanning — the operating system very nearly does that for you — it is deciding what the app knows, and what it does on the days nobody scans anything.

TL;DR:

  • Scanning is three stages: extract the label text, resolve it to an identity, then explain it. Stage one is close to free; stages two and three are the product.
  • You do not need a million-bottle crowdsourced database. That buys you one thing — what other drinkers scored this exact label — and nothing else.
  • Retention does not come from scanning, which is occasional. It comes from the daily loop that works with no bottle present.
  • Food pairing is the feature people actually open the app for, more often than identification.
  • Keeping the wine list on the device removes accounts, resets and personal data obligations in a single decision.

Table of Contents

How Label Scanning Actually Works

There are three stages, and they are not equally hard.

Stage one — read the label. The camera captures the bottle and text recognition extracts what is written on it: producer, cuvée name, vintage, appellation, alcohol percentage. On iOS this is the Vision framework, runs on-device, costs nothing per scan and works offline. The difficulty here is physical rather than computational — wine labels are gold foil on dark glass, photographed in a dim restaurant at an angle, often in a script chosen for elegance over legibility.

Stage two — resolve it to an identity. A string like "Château Something 2019 Saint-Émilion Grand Cru" has to become a structured understanding: this region, these grapes, this style, this typical profile. This is where a lot of the perceived accuracy lives, and where a partial read still has to produce a useful answer. If the vintage is unreadable but the appellation is clear, the app should still say something true about Saint-Émilion rather than failing.

Stage three — explain it. Turn the identity into what the person actually wanted: tasting characteristics, flavour notes, serving temperature, decanting, and what to eat with it. This is the part users judge the app on, and it is entirely a writing problem — the same facts can read like a textbook or like a knowledgeable friend, and only one of those gets opened twice.

Pro Tip: Design stage two for graceful failure before you optimise stage one. A scan that returns "this is a Rioja, here is what that means" is a good experience; a scan that returns an error because it could not read the vintage is not.

The Database Question, and Why It Is the Wrong One

Nearly everyone who considers building a wine app stops at the same point: Vivino has tens of millions of labels and hundreds of millions of ratings, so how could anyone compete?

The answer is that this is a question about one feature, not about the category. A crowdsourced database buys you exactly one thing that nothing else can: what other drinkers thought of this specific bottle. That is genuinely valuable and genuinely unmatchable, and if community ratings are your product then the incumbent has already won.

But it is not needed for any of the rest. What a Barolo is, why Nebbiolo tastes the way it does, what temperature to serve Chablis, whether this bottle works with the lamb — none of that is bottle-specific data. It is general wine knowledge, it has been written down for a century, and a language model has it. The knowledge layer needs no scraping, no community, no cold start, and it answers the question most people are actually asking, which is not "how did strangers rate this" but "is this any good for what I am about to eat".

So the first decision is which product you are building. The ratings product requires a decade and a community. The understanding product requires good writing and a careful prompt, and it is available to a small team this quarter.

Pairing Is the Real Feature

Identification gets the install. Pairing gets the use.

The moment people reach for a wine app is more often "I am cooking steak, what should I open" than "what is this bottle". The first has a clear answer, happens weekly, and needs no camera. The second happens in a shop and needs good light.

Building pairing as a first-class surface — searchable by dish rather than only reachable after a scan — changes the shape of the product. Steak, seafood, cheese, pasta, pizza, dessert: these are the entry points, and each one should work on its own without a bottle in hand.

The Daily Loop

A pure scanner is opened a few times a month and deleted in the third month. The apps that survive give a reason to open on an ordinary Tuesday.

Two things work reliably. The first is a daily wine and food combination — one pairing, recommended plainly, that a person could act on tonight. The second is short-form wine knowledge: a grape, a region, a serving tip, a piece of winemaking history, delivered one at a time rather than as a course to complete. Both are cheap to produce and both turn a utility into a habit.

The failure mode to avoid is the streak. Wine is not a productivity task and gamifying consumption is both tonally wrong and, given the subject, a poor idea on its own terms.

The No-Account Wine List

Every wine app wants a saved list — bottles you liked, bottles to try, bottles you scanned and want to remember.

The default instinct is accounts and cloud sync. It is worth questioning. Requiring sign-up before a person can save their first bottle is the single most expensive screen in a casual consumer app, and it arrives at the exact moment the user has just experienced something they liked. Keeping the list on the device removes the sign-up, the password reset, the session handling and the personal data obligations in one decision.

The trade-off is honest and should be stated rather than hidden: a device-local list does not survive a lost phone and cannot be shared between devices. For an app used a few times a week by one person, that is usually the right side of the trade. For an app aiming at collectors with cellars, it is not.

Getting the Tone Right

Wine has an intimidation problem, and most wine software makes it worse by assuming knowledge and using vocabulary as a filter.

The opportunity is the opposite posture: explain without condescending, answer the question that was asked rather than the one an expert would prefer, and never make someone feel they should have known. Practically, this means a sommelier feature that answers "what do I get for a Tuesday dinner under fifteen euros" as seriously as it answers a question about malolactic fermentation.

This is a copywriting discipline more than an engineering one, and it is the most-copied and least-replicated part of a good wine app.

How Wine Apps Make Money

  • Subscription — unlimited scans and sommelier access. Best fit: the value is ongoing and the costs are per-use, so the models line up.
  • Affiliate — links to retailers. Pays well where it works, but needs commerce integrations and regional stock, and a recommendation the user cannot buy locally is worse than no recommendation.
  • One-off unlock — pay once for the full reference. Suits the app's character, caps revenue per user, and leaves ongoing model costs unfunded.
  • Advertising — the weakest fit. The audience is small and premium, and ads destroy the calm editorial feel that makes the app pleasant to use.

The regional complication worth knowing about up front: alcohol is advertised and sold under different rules in different markets, and anything that moves from information towards selling picks up obligations that vary by country. An informational app carries very little of this; an app with a buy button carries a lot.

Build or Buy

Built new, a wine app of this shape is a few months of work: the scanning pipeline and its failure handling, the knowledge layer and its prompting, the pairing surface, the daily content loop, local persistence, and an App Store submission. Commissioning it lands in the tens of thousands of euros, and — as with the dating and file-transfer categories — the time goes into the unglamorous parts: making a bad photograph still produce a useful answer, and making the writing sound like a person.

Buying one already published skips the submission and, more usefully, skips the months of prompt iteration that decide whether the output reads as knowledgeable or as generated. Our cost calculator prices the new-build route.

A Finished One, as a Worked Example

The decisions above describe WineGuide | Taste, a React Native app in our catalogue that is live on the App Store.

Scan a label with the camera and it returns the region, grape varieties, style, tasting characteristics, flavour notes, serving recommendations and food pairings. Ask the Sommelier handles the questions a scan does not — grapes, regions, pairings, serving temperatures, wine styles, or simply which bottle to pick for dinner. Food Pairings is a first-class surface built around dishes rather than bottles: steak, seafood, cheese, pasta, pizza, desserts.

The retention layer is the one this article argues for. Daily Combination gives one wine and food pairing a day with a plain recommendation for what to serve together, and Wine Facts delivers one piece of wine knowledge at a time. Explore Wine covers grapes, regions, styles, flavours and serving tips as a browsable reference rather than a course.

My Wine List saves scanned and discovered bottles — and, as argued above, requires no account. The sale includes the full source and the App Store listing transfer, so the reviews and ranking history move with it.

The panel below reads the catalogue row directly, so the price and availability there are current.

Sources

FAQ

How does a wine label scanner app work?

Three stages. The camera captures the label and on-device vision extracts the text — producer, cuvée name, vintage, appellation, alcohol. That text is then resolved into an identity: which producer, which region, which grapes, which style. Finally a knowledge layer turns the identity into something readable — tasting characteristics, serving temperature, food pairings. The first stage is nearly solved by the operating system frameworks; the accuracy of the second and the usefulness of the third are what separate a good app from a party trick.

Do you need a huge wine database to build a wine app?

No, and assuming you do is what stops most of these apps from being built. A crowdsourced database of millions of specific bottles wins on one thing: telling you what other drinkers scored this exact label. It is not needed to explain what a Barolo is, what temperature to serve it at, or what to eat with it — that is general wine knowledge, and a language model has it. Deciding which of those two products you are building is the first decision, and the second is far cheaper to reach.

What makes people keep using a wine app?

Not the scanning. Scanning is occasional and situational — it happens in a shop or a restaurant, a few times a month at most. Retention comes from the reasons to open the app when there is no bottle in front of you: a daily wine and food combination, short pieces of wine knowledge, and a personal list of wines worth remembering. The scan is what gets the app installed; the daily loop is what stops it being deleted.

Should a wine app require an account?

Not for a personal wine list. Requiring sign-up before someone can save their first bottle costs more installs than the cloud sync is worth, and storing the list on the device removes the account system, the password resets and the personal data obligations in one decision. The trade-off is real — a saved list does not survive a lost phone and cannot be shared between devices — so it is a choice about who the app is for, not a shortcut.

How do wine apps make money?

Four routes, in rough order of how well they suit a small app. A subscription for unlimited scans and the sommelier feature fits best, because the value is ongoing. Retailer affiliate links pay well but require commerce integrations and regional inventory to be useful. One-off unlocks suit a reference tool but cap revenue per user. Advertising is the weakest fit: the audience is small and premium, and ads undermine exactly the calm, editorial feel the category depends on.