La Quille: how we developed an iOS and Android mobile app

Elvis Web Case Study · iOS and Android mobile app · November 2026

Standing in front of a shelf of rum, the question is always the same: Will I like this bottle? It is this simple question that is answered by La Quille, the mobile app for iPhone and Android that we developed here at Elvis Web. You scan a label, and the app compares the rum’s profile to your tastes and displays a personalised compatibility score.

In this article, we describe the transition from a free Version 1 to a Premium Version 2: the concept, the technical choices, the design decisions — including what we chose not to do — and the lessons we’ve learnt for any mobile app project.

The idea: just one question, not a catalogue

Existing rum apps are often just catalogues or notebooks. They assume that the user already knows what they like. La Quille is based on a different premise: a beginner doesn’t always know how to describe their tastes, and a seasoned enthusiast wants above all to avoid making a mistake when faced with a well-stocked shelf.

The product is therefore built around a single action — scanning — and a single outcome: a clear score, accompanied by a few easy-to-understand reasons.

V1: a free platform that covers the essentials

Version 1 covers the core features of the service: label scanning, manual search, detailed product information, compatibility score, favourites, history and basic taste profile. It was released on the App Store in June 2026.

One principle guided what followed: this foundation must never be compromised. When you introduce a paid service, the temptation is to restrict the free content to encourage people to subscribe. We did the opposite: the scan, the score, the RhumDex — a collection that grows as you discover new rums — and the post-tasting reviews remain free, even in V2.

The engine: six sensory axes and two profiles

Each rum and each user are described in terms of sensory characteristics: sweetness, fruitiness, herbal/floral notes, woodiness, intensity and complexity. The compatibility score measures how closely the rum’s profile matches that of the user.

Why a sixth axis in V2? In V1, vegetal, floral and fresh cane notes were grouped together with fruitiness. As a result, a very floral agricultural rum might have had its ‘fruitiness’ artificially lowered, when in fact it was simply expressing a different aromatic profile. This separation makes the profiles more accurate: a fresh cane agricultural rum now scores highly for ‘vegetal’ notes, whilst a rum with exotic fruit notes scores highly for ‘fruity’ notes. This distinction is particularly useful for agricultural rums and white rums.

The requirement was clear: no data loss. Profiles are not reset, the history is not deleted, and there are optional fields for older products, so that the display updates gradually.

Two profiles rather than one. You don’t drink rum as an aperitif in the same way as you would savour it. The initial questionnaire therefore branches out according to the user’s habits and can create an ‘Aperitif’ profile, a ‘Tasting’ profile, or both. The scores are then adjusted to suit the active profile.

Distinguishing between what we perceive and what we like

A common pitfall for apps that learn from user feedback is to confuse perception with evaluation. If ‘I love this rum’ increases its ‘smoothness’ score, the profiles drift towards the extremes.

We have therefore laid down a strict rule: the assessment never alters the sensory axes. Post-tasting feedback distinguishes between perception — is this rum sweet, oaky, floral? — and appreciation — did you like it, would you buy it again?

The questionnaire also adapts to the level specified: simple and quick for a beginner, and more detailed for an experienced user, whose answers carry greater weight in the learning of product profiles.

Freemium: what remains free, what becomes Premium

Version 2 introduces a Premium subscription that unlocks ‘My Cellar’, the ‘What to drink?’ feature, an advanced tasting diary, profile trend analysis, advanced filters and personalised monthly recommendations.

Technically speaking, a subscription is not just a simple button. You need to integrate StoreKit on the Apple side and the Google Play Billing Library (Android side), validate receipts on the server side, then manage renewals, cancellations, expiries and purchase restores. An error in this module has a direct impact on turnover and may also result in rejection by the app stores. This is the area that requires the most testing, including in a sandbox environment.

My Wine Cellar and ‘What to Drink?’: Design Decisions

Ma Cave lets you manage the bottles you own; ‘What to drink?’ suggests, from amongst them, the one that best suits the occasion: an aperitif, a tasting, or whatever takes your fancy. That’s where the choices proved most enlightening.

• Never make up data. No default price, no market estimate. The ‘purchase amount entered’ simply adds up the prices entered by the user and specifies the number of bottles on which it is based.
• Remove a misleading average. We have removed the ‘average cellar compatibility’ and the average sensory profile: an average can describe a rum that does not exist, and a cellar is under no obligation to be balanced. Only the score for each bottle is retained.
• Don’t try to force the result. If only one or two bottles are actually suitable, the app suggests one or two – not three, just to make it look nice. It’s better to say that none are suitable than to make a random recommendation.
• A neutral ranking. The score remains the main criterion. Only secondary criteria, such as whether a bottle has already been opened or which one was tasted most recently, are used to break ties between similar scores. No commercial criteria are taken into account.
• Distinguish between the concepts. A bottle is either unopened, opened or finished — its physical state; it is ‘tasted’ if there is a review. Owning a bottle says nothing about whether you have tasted or liked it: the app therefore does not ask for this information when you add it.
• One data sheet per reference. Three identical bottles result in a single record, but each purchase can retain its own price and date in the database.

This simplicity is deliberate: it is better to have a few reliable functions than an impressive but imprecise dashboard.

The technical choices that matter

As for mobile, we have selected React Native to deliver iOS and Android apps from a shared codebase. The server is based on Node.js and a base PostgreSQL, whose line-level security isolates each user’s data.

Two details made all the difference.

Stable product identifiers

Each rum has a unique internal identifier, independent of its line in the catalogue import file. A renamed product retains its identifier; a withdrawn product is archived rather than deleted; and a merged product redirects to the previous one. This ensures that updating the catalogue does not disrupt the history, favourites or log.

The scanner that can say ‘I don’t know’

It’s better to display ‘unrecognised rum’ than an incorrect reference. Every failure adds to a queue of unrecognised scans, which the team uses to enrich the catalogue.

Publish on the App Store and Google Play

Publishing on both app stores requires preparing elements that are not technical in nature. For an app relating to alcohol, both app stores have classified La Quille as 18+. They also require a precise declaration of the data collected: a privacy policy on Apple’s side, and the ‘Data Security’ section on Google’s side. These declarations must accurately reflect the product and the privacy policy, in accordance with the GDPR.

You should also read the following carefully: Apple’s validation rules and the Google Play content policies, particularly when a subscription is offered: the terms and conditions for renewal and cancellation must be clearly stated in the product description.

Initial findings and lessons learnt

The initial feedback is encouraging: the app shows 4.9/5 on the App Store, based on what is still a modest sample. We prefer to leave it as it is: the launch is recent, and it is the method that interests us here.

1. Protect what is free. A reliable foundation, which has never been compromised, builds the trust that makes the subscription credible.
2. Don’t automate everything. An average or a rough estimate undermines the credibility of a recommendation engine.
3. Think about data right from the start. Stable identifiers, nullable fields, archiving: everything that helps avoid breaking what already exists.
4. Test payments as you would critical code. Sandbox, receipts, edge cases.
5. Write few functions, but write them properly. Every feature that is added is a feature that needs to be maintained and explained.

Frequently Asked Questions

How long does it take to create an app like La Quille?

It depends mainly on the scope. The scan and the score form the foundation; the subscription, the journal and the wine cellar add significant challenges: payments, data and testing. We will go into more detail about the order of magnitude in a forthcoming article on the cost of a mobile app.

React Native or native development?

React Native allows most of the code to be shared between iOS and Android, thereby reducing costs and development times. Native development retains the advantage for very specific requirements, such as high-performance graphics or advanced system functions.

Is the app free?

Yes, for the most part: the scan, compatibility score, RhumDex and post-tasting feedback are free. Premium is an optional subscription.

Further reading: La Quille, designed by Elvis Web · La Quille’s official website.