Avawear's MOD4 paid players in LuisaViaRoma loyalty points
Aetsoft rebuilt the app that runs it and built the marketplace where players could own and resell what they collected.
MOD4 was already a working customer channel when Aetsoft joined in 2022. Players style virtual versions of garments LuisaViaRoma actually sells, compete on the results, and earn LVR points that count towards the retailer's own loyalty programme. Aetsoft rebuilt the game's mobile app on React Native, and specified, built and managed delivery of the NFT marketplace that would carry ownership of those wardrobes.
LuisaViaRoma already ran a proper loyalty programme, with tiers, points and rewards. What no loyalty programme does is give a customer a reason to turn up when they are not buying, because every mechanism in it fires around a transaction.
Avawear built MOD4 for the gap in between: a fashion game on the LuisaViaRoma catalogue, where playing earns LVR points that build status in LVR Privilege. It deepens the relationship with existing customers, and reaches players who arrive for the game with no prior connection to the brand. The next step was to let players own and trade the wardrobes they had built. Aetsoft rebuilt the mobile app, then specified and delivered the marketplace that ownership would need.
001
ClientAvawear S.R.L., the Florence fashion-tech company behind MOD4, the mobile game built on the LuisaViaRoma catalogue and connected to the retailer's LVR Privilege loyalty programme.
002
ChallengeMOD4 had already connected play with LVR points and with the products themselves. Avawear wanted to go further. Wardrobes should be property a player could resell, and holding one should earn something at the shop, such as first access to a limited drop.
003
SolutionThree connected products. The MOD4 app as the front door. A marketplace on Polygon deciding who may publish, who may buy and how money splits. luisaviaroma.com as the place value lands. Aetsoft delivered the first two and designed the integration into the third.
004
Aetsoft's roleBusiness analysis, architecture, delivery and project management for the marketplace. The MOD4 mobile app rebuilt on React Native, with backend development, in a squad alongside Avawear's engineers.
Engagement lead
Pavel Sivayeu
CTO, Aetsoft Inc
Led technical direction and delivery across the marketplace and the mobile app.
Engagement lead
Artem Kirylin
Commercial Director, Aetsoft Inc
Led the commercial relationship and the product consulting.
A loyalty programme meets the customer around a purchase, and this one wanted the rest of the year
LuisaViaRoma sells online and from its own stores, and runs LVR Privilege, a tiered programme where points earn status and status earns rewards. It works, and it works at the moment of purchase. Tiers move when somebody spends, rewards are redeemed against something they were going to buy, and status is a summary of what they have already done.
Somebody who buys twice a year is outside all of it for ten months. Reaching them in those months means buying the attention back through advertising, at the going rate, every time.
MOD4 was Avawear's answer. Players build an avatar and dress it in virtual versions of garments LuisaViaRoma actually sells, drawn from the live catalogue. They enter styling competitions, vote on each other's looks, and open boxes containing items at different rarities. Playing earns LVR points. Those points build status in LVR Privilege, the retailer's own programme, and can be redeemed for the rewards it offers. Any garment in the game links to the same garment on luisaviaroma.com.
Most loyalty gamification sits inside the rewards page, as a streak or a progress bar against spend. Here the game was a product in its own right, and it was built to work on two audiences at once:
- Customers the retailer already had, given a reason to open MOD4 on a day they had no intention of buying anything
- Players with no prior connection to LuisaViaRoma, who arrived for a styling game and met the catalogue through it
A new challenge every day gives the catalogue a reason to be opened, in a setting where looking at clothes is the entertainment. The reward comes as LVR points, which is a different lever from cutting a price. Neither is something a media buy can produce, and together they are the case for building fashion retail loyalty around a game.
Most loyalty gamification sits inside the rewards page, as a streak or a progress bar against spend. Here the game was a product in its own right, and it was built to work on two audiences at once:
- Customers the retailer already had, given a reason to open MOD4 on a day they had no intention of buying anything
- Players with no prior connection to LuisaViaRoma, who arrived for a styling game and met the catalogue through it
A new challenge every day gives the catalogue a reason to be opened, in a setting where looking at clothes is the entertainment. The reward comes as LVR points, which is a different lever from cutting a price. Neither is something a media buy can produce, and together they are the case for building fashion retail loyalty around a game.
LVR points and a digital wardrobe would do different jobs. Points record progress inside the retailer's programme and are redeemed for what it offers. A wardrobe held on chain would be transferable, which is what makes resale and holder-only access possible. Avawear wanted both, running side by side.
balance was not enough on its own
Inside a game, a collection is a database row the company can withdraw. Make it property and three things become possible, and each adds something a points balance alone does not express.
A reward the shop can act on. LVR points accumulate inside the programme, and a customer redeems them for what it offers. Ownership does a different job. It is something the retailer can look at and gate against, so a limited drop can be reserved for people holding a particular piece. The piece has to be earned or bought first, which is what makes the access worth having.
A relationship that survives a gap. Points sit inside the programme and follow its rules. A wardrobe with resale value is a thing the customer holds in their own right, whether or not they open the app again.
A price on the catalogue's desirability. Resale between players would put a number on each piece. For a retailer choosing what to stock and which labels to back, that is a demand signal arriving without a survey.
Avawear's plans followed the same logic, and they are the shape an NFT loyalty programme usually takes. The first was a fixed-price collection acting as an access card to a private community, where holding more meant earlier access. The second was larger: put the game's own items on chain so a player could sell what they had earned. Avawear later called that direction Wear2Earn.
Doing nothing had a clear shape too. MOD4 would keep working as a channel and stay a closed one. Play would keep topping up a points balance, and a points balance is a number. It records that somebody was active. What it leaves out is what they were drawn to. The retailer still could not tell a player who wants one label from a player who wants another, or offer either of them anything specific.
Solution
Three connected products, two of them built here
A marketplace on its own would not have done it. Each part works only if it knows what the others hold.
- MOD4 is the front door and the reason anyone is there. It had to keep feeling like a fashion product as the rest was built around it.
- The marketplace decides who may publish an item, who may acquire one, what an owner holds and how money splits.
- luisaviaroma.com is where value lands, through LVR Privilege and through releases reserved for holders.
Aetsoft delivered the first two, and designed the integration that would join them to the third.
Solution
Three connected products, two of them built here
The marketplace was a new product, so it was specified first.
Aetsoft ran business analysis, architecture, delivery and project management. Avawear's brief set out business goals and left the system undefined, so the first phase produced:
- Business rules and product requirements
- A software requirements specification covering administration, publishing, eligibility and settlement
- A system architecture, including how the marketplace would be read by the game and the shop UX/UI design for the marketplace and its administration console
Development, testing and stabilisation followed.
Publishing is a right Avawear grants
Any marketplace where signed-in accounts can list freely fills with items the brand never approved. For a shopfront carrying the LuisaViaRoma name, that is the whole problem.
An administrator grants publishing rights to a creator or a brand partner, and takes them back. Publisher status shows in the account list, and a new account has none by default.
Eligibility is settled before money moves
Reserved releases only mean something if eligibility is checked as a purchase completes. It holds the restriction and the list of eligible holders, and tests both at that moment. An administrator can lift a restriction on one item without touching the rest.
That is what the access-card plan needed. Holders qualify because the marketplace can see what they hold when they try to buy.
The brand takes the first sale, the creator takes every resale
Avawear takes a fee on the first sale. An administrator can change it as the market moves, and a creator sees it before minting. A creator's royalty is set at creation and applies to every resale the contracts process. Both are set when the item is created, so a resale pays the creator without disturbing the brand's cut on the first sale.
Digital garments need more than a picture
Garments are designed to move on a body, and a still image loses that. The marketplace takes video, GLB and GLTF as well as images, and renders the 3D formats in the item page.
Media and metadata can also be frozen to IPFS, which makes the file content-addressed and independently verifiable. Continued availability depends on the pinning arrangement behind it, and the architecture specifies a node for writing with public gateways for reading.
The integration was specified, and left for the phase after handover
Both connections were specified in the architecture. MOD4 would query what a player owns and dress the avatar in it. luisaviaroma.com would recognise holders when deciding who gets a reserved release. Both were designed for the phase after the marketplace was in Avawear's hands.
The decisions,
and what each one
cost
-
Decision
Chain
-
Type
Technical
-
What we chose
Polygon
-
Why
Items priced for players had to move often, and minting costs little
-
Trade-off
MATIC is less widely held than ETH, which adds a step for a first-time buyer
02/06
-
Decision
Token standard
-
Type
Technical
-
What we chose
ERC-721 for one-off pieces, ERC-1155 for editions
-
Why
Fashion releases come both ways, a single archive piece and a numbered run
-
Trade-off
Two contract paths to build and maintain
03/06
-
Decision
Payments
-
Type
Business
-
What we chose
Crypto for the first release, in MATIC and wrapped MATIC
-
Why
Card payments would have meant adding an acquirer and a settlement partner
-
Trade-off
Narrows the first audience to people who already hold crypto
04/06
-
Decision
Wallets
-
Type
Business
-
What we chose
Player-held first, custodial from a later phase
-
Why
A wallet the customer controls needs no integration with running systems, so the first release stays small
-
Trade-off
The shop can only see a holding once a player connects a wallet
05/06
-
Decision
Media storage
-
Type
Technical
-
What we chose
Object storage for delivery, IPFS freezing as an option per item
-
Why
Fast rendering by default, with verifiable provenance where a creator wants it
-
Trade-off
Frozen metadata cannot be corrected afterwards
06/06
-
Decision
Administration access
-
Type
Technical
-
What we chose
The admin console kept off the public internet, reachable over VPN
-
Why
It holds publishing rights, fees and eligibility lists, so it is the part worth protecting
-
Trade-off
Staff need a VPN client to do routine work
Choosing the network, the token standards, the payment route and the wallet model is the work itself. Blockchain consulting settles that technical set-up against how the business needs to operate, before anyone writes a contract that is expensive to change.
Wallets were the closest call, because that choice decides how much of the audience gets through sign-up. Wallets the player installs keep the build small. They also put a crypto sign-up step in front of a fashion customer, which is where that audience stops.
Holding wallets for the customer removes that step. A player signs in to MOD4 as they always did, and the shop can see what they hold.
That needs an identity and wallet model shared across the products, which is where custodial wallet development belongs in the design. A provider of that kind holds keys under policy and exposes wallets a business can attach to an account it already has. The cost is real. Authentication has to work across all three products, and the company becomes responsible for keys its customers rely on. Running key infrastructure is a different commitment from running a shop, which is why that phase starts with a provider built for it.
There was no client system for the marketplace to fit into, so Aetsoft owned it end to end, project management included.
models, because the two products
needed different ones
MOD4 was live and had its own engineers, so it ran the opposite way. Aetsoft worked in a squad with Avawear's team on daily calls, and owned the mobile app. Backend development was shared with the client's CTO and backend engineer.
That team also moved the app from Xamarin to React Native, work the client's own record describes as complex and heavy on graphics and animation. MOD4 was almost entirely animated garment rendering, so the framework underneath decided how the product felt. React Native draws through the GPU and runs animation outside the main thread, so a heavy scene keeps moving while the rest of the app works.
What was
delivered
Results
What Avawear's team received
- The marketplace, with its web front end, administration console, user and token services on AWS, and the Polygon contracts behind them
- The MOD4 mobile app, rebuilt on React Native and released through the app stores, with new features and continuing backend development
- Product requirements and business rules, covering the marketplace and its administration
- A software requirements specification covering publishing, eligibility, settlement and administration
- A system architecture, with the QA environment and DevOps documentation behind it
- Complete UX/UI designs for the marketplace and its administration console
Frequently asked questions about loyalty gamification
-
What is gamification in a loyalty programme?
Using game mechanics, such as challenges, levels and collecting, to earn engagement as well as reward spend. Most schemes put a progress bar on the rewards page. MOD4 made the game itself the product.
-
Does gamification actually increase customer engagement?
It changes what you can offer, which is the honest version. A game gives somebody a reason to open your app on a day they were not buying, and shows you what they put together as well as what they bought. Whether that converts depends on merchandising, and vendors quoting uplift figures rarely say which they measured.
-
How do you gamify a loyalty programme for a fashion retailer?
The fit is direct, because the catalogue is already visual and trying things on is already the pleasure. Build the earning into something people would do anyway, pay in loyalty currency, and link every virtual item to the real one.
-
Our customers already have accounts. Why add a wallet?
An account says who somebody is. A wallet says what they hold, and only the second lets you reserve a release for people who earned their way in. If that distinction does not pay for itself, a tiered scheme is cheaper.
Tell us what you want a customer to do between purchases, and what holding one of your items should earn them. We will tell you what needs settling first.
