Telegram Tap-to-earn Game

Dropee is a Telegram-native tap-to-earn game that turns everyday chat sessions into quick, rewarding play. Players join through the DropeeBot, complete simple taps, combos, and quiz-style challenges, and earn in‑game coins and crypto rewards along the way. Instead of long tutorials or complex interfaces, Dropee fits inside a compact mini‑app UI that feels closer to a playful sticker pack than a finance tool. Seasonal events, daily questions, and special “Daily Combo” puzzles give players reasons to return, experiment with different strategies, and compete with friends in short bursts throughout the day. With an upcoming $DROPEE token generation event, the game is evolving from a viral Telegram pastime into a richer ecosystem where long‑term players can benefit from the value they helped create—and where new LiveOps systems, vibecoded in no‑code tools and paired with AI‑generated visuals, continuously refresh the game’s look and feel.

2024 – 2026

+500K monthly users

Players

15M total users

Reach

3M connect-ed wallets

Web3 layer

#1 on Dappradar (Gaming on TON, multiple weeks)

Ranking

+5B spins completed on the main wheel

Engagement

CONTEXT

Building games inside chat,

not app stores

Dropee lives entirely inside Telegram, so players never visit an app store, download an app, or create a traditional account. Discovery happens through links, screenshots, and community forwards instead of paid acquisition. The goal was to design Dropee as a game that feels native to chat—fast to start, low commitment, and easy to share—while still being deep enough to keep people playing beyond the first curiosity tap.

Telegram App

Telegram Bot Chat

Opening Dropee inside Telegram

Role and responsibilities

Owning the game

experience end to end

As Lead Product Designer, I co‑shaped Dropee’s core loop, UX flows, and visual system across the Telegram mini‑app and supporting surfaces. I partnered with product and engineering to translate goals like retention, virality, and TGE-readiness into specific mechanics such as Daily Combo, Question of the Day, and event surfaces tuned to Telegram’s constraints. Beyond core gameplay, I also lead the design and implementation of LiveOps systems and the visual language for events, from interaction patterns down to the smallest icon.

CORE GAMEPLAY LOOP & DAILY SYSTEMS

Design strategy:

short sessions, long arcs

Dropee’s core loop is deliberately simple: tap to earn coins, use coins to trigger upgrades or milestones, and watch your progress respond instantly. Each 30–60 second session is built around that rhythm—open the bot, tap, claim, maybe make one small decision—and then drop back to chat. Around this loop, we layered a set of lightweight rituals that give players reasons to say “I’ll just do one more thing” without turning the game into a grind.

Daily Combo introduces a small configuration puzzle that rewards experimentation and creates a quick, satisfying goal beyond raw tapping. Players try different combinations to unlock boosted rewards, which nudges them to engage more deeply with the system. Question of the Day adds a quiz‑like interlude that breaks the tap rhythm, reinforces brand recognition, and offers another low‑effort way to earn. Both features are tuned to be completable in under a minute. Still, together they anchor a reliable daily ritual: open Dropee, tap, check Combo, answer the question, and leave with a sense of closure and progress.

As the core loop and daily systems settled, a new challenge appeared: keeping Dropee feeling fresh without bloating the interface or relying solely on bigger rewards. We needed a way to introduce novelty, experiment with different reward structures, and plug deeper into the game economy—ideally in a format that could one day be opened up to the community itself.

LIVEOPS & VIBECODING

Designing LiveOps as games within a game

1. Designing a configurable LiveOps engine with NocoDB

To solve this, we started vibecoding LiveOps in the no‑code tool Lovable, backed by NocoDB, so we could ship new mini‑experiences as fast as we could imagine them. To scale LiveOps beyond one‑off events, we first treated them as data, not features. Together with our backend team, we defined a NocoDB schema that describes each event as a reusable template: name, duration, steps, costs, rewards, cosmetics, currencies, and timing. Each “Pathway” event is essentially a row set in NocoDB—steps as arrays of costs and rewards, plus a cosmetic block with background image, fallback color, and icon URLs.

The Dropee backend reads that NocoDB configuration and injects it into the main Telegram mini‑app. When a player opens a LiveOp, the parent mini‑app spins up an iframe and sends a structured INIT_DATA payload via postMessage: event config, step list, currencies, player balances, current progress, and end time. On the Lovable side, we built a transformation layer that turns this raw, flat data into clean internal types (FREE, CURRENCY, USD steps; cosmetics with a three‑tier priority for background image, color, or default gradient), so the UI is always rendering a well‑typed representation of whatever lives in NocoDB.

---
name: Badge Room — Trophy Cabinet
description: >A mobile-first progressive badge collection UI embedded as an iframe widget. Players earn currency through gameplay, hit cumulative thresholds, and claim badges displayed in a 3D glass trophy cabinet. Communicates with a parent app via postMessage for init data, progress updates, claims, and haptic feedback.
version: 1.0.0
category: gamification-widget
tags: [gamification, badges, trophy-cabinet, iframe-widget, postMessage, mobile-first]
---

<role> You are a mobile game UI engineer building an embeddable badge collection widget. The widget runs inside an iframe, receives configuration and player state from a parent app via postMessage, and sends back user actions (claim, close, haptic). Your design language is rich, skeuomorphic 3D — glass shelves, wooden cabinet rails, glowing jewels, and pedestal-mounted badge icons. </role> <context>

<domain> A "Badge Room" feature for a mobile gaming platform. Players accumulate an event currency over time. When their balance crosses cumulative thresholds, badge milestones unlock sequentia...

Originally, our backend team would generate a base Lovable project for a new LiveOp—for example, a starter “Pathway” file that I could then remix into a new LiveOp layout kind or visual theme: tweak step counts, cosmetic priorities, density, and layout, then reconnect it to the same NocoDB schema. Today, the process is even simpler by just "@"-ing another project and prompting directly what should be used. In practice, that means we can stand up a new event by duplicating an existing configuration, changing a few XML‑like fields, and letting the system do the rest.

Conceptually, each LiveOp starts as a structured prompt:

“Create a 10‑step ‘Path to Rewards’ LiveOp, with early steps free or cheap, mid steps priced in in‑game coins, final steps purchasable in USD, using a carnival theme background and spotlighting golden coins as the hero currency.”

Backend translates that intent into NocoDB data; the mini‑app sends it as INIT_DATA; the Lovable frontend transforms and renders it as a fully playable event with pillars, connectors, inventory bar, and countdown timer.

NocoDB UI with LiveOp configurations + Lovable Game Draft

2. Vibecoding LiveOps in Lovable (designing the front end like a game)

With the data layer in place, Lovable became my vibecoding workspace to shape LiveOps like small mobile games rather than static promos. I describe the feel I want (“winding path with 3D pillars, confetti, parallax background”), and Lovable generates React/TypeScript/Tailwind components that we iterate on directly from my phone preview.

Original Base file by Backend

Final Project in Lovable (broken graphics are what is filled by NocoDB on prod)

The Pathway UI is a pure frontend: it only renders whatever INIT_DATA the mini‑app sends, and sends back actions via postMessage. That let me focus entirely on layout, hierarchy, and game feel—PathwayGrid for the zig‑zag path, StepCard for 3D pillars and states, InventoryBar and timers for clarity—without touching core game logic. I treat each LiveOp as a structured “event document” (XML‑style in spirit): change the steps, costs, and cosmetics in NocoDB, then tweak spacing, animations, and effects in Lovable until it feels like a finished mini‑game.

3. Generative AI as an art collaborator (Dropee V2 LoRA)

On the visual side, I use generative AI not as a one‑shot asset generator, but as a long‑term collaborator tied to Dropee’s visual identity. I trained a dedicated Dropee V2 LoRA on Scenario AI, based on our evolving art direction, so that every new asset—no matter the theme—still “reads” as Dropee. That LoRA is now the backbone of all LiveOps art production.

For each theme—Valentine’s Day, Carnival, St Patrick’s Day, Chinese New Year, and others—I define a small design kit: icon shapes, background composition, badge frame style, and motion hints. Then I prompt Scenario with event‑level intent (“Dropee coin carnival banner, purple‑orange lights, confetti, glossy mobile‑game UI”), generate a batch of candidates, and curate them into a cohesive set: game icons for the main wheel, background art for LiveOps pathways, and badge designs for completion and milestones. I then pull those into Figma, align them with our component system (buttons, pillars, cards), and adjust color, contrast, and layer depth so they work inside the product, not just as standalone illustrations.

Because the pipeline is so fast, I can prototype whole event looks in a day:

Generate a theme pack in Scenario with the Dropee V2 LoRA.
Drop assets into Figma and Lovable to skin a new LiveOp.
Wire the event via NocoDB and test it live on my phone.

This loop lets us ship “games within the game” that don’t just tweak numbers—they arrive with their own iconography, backgrounds, and badges, while still feeling like Dropee. It also sets up an interesting future: the same structure that lets me prompt and configure events could one day be opened to community creators, who could design their own LiveOps using shared templates and the same LoRA‑powered art system, safely constrained by the underlying economy and UX patterns.

Economy and TGE‑ready UX

Keeping the crypto layer optional but present

For many players, Dropee is “just a game” they open between messages; for others, it is also a way to earn and interact with real tokens. I treated the crypto surface as an optional depth layer: clearly signposted paths for connecting a wallet, joining airdrops, and understanding $DROPEE, all kept out of the way of players who only want to tap and play. This keeps onboarding ultra‑clean while laying UX foundations for the token generation event, where long‑term play and LiveOps participation can translate into more meaningful ownership.

From a UX point of view, I designed the presale launchpad and the airdrop claiming + staking dApp as one continuous “ownership journey.” The presale flow lives in a single main card that answers three questions—what’s my price, how long until it changes, and how much should I deposit—combining whitelist detection, countdown, amount input, and two primary CTAs into a mobile‑first layout, with alternative payment and geo‑blocking pushed into secondary modals. The vesting and staking views then pick up the same language of cards, progress bars, and celebratory states: vesting appears as one clear allocation bar with Claim vs Claim & Stake options, while staking is framed as four lock “plans” with multipliers and a live Dropee Points counter, all wrapped in the same dark, glassy look, gradients, 3D buttons, and confetti players already recognise from the game.

More broadly, I shaped the whole $DROPEE layer as a set of adjacent experiences that feel like extensions of Dropee rather than separate DeFi products. Inside the Telegram mini‑app, players see only light‑touch prompts—airdrop teasers, simple token explainers, and a single primary action—so the core loop stays playful and tap‑first. When they choose to go deeper, the presale and vesting flows reuse familiar visuals and interaction patterns (progress, rewards, minimal form fields), so connecting a wallet, depositing, claiming, or staking all read as “managing my progress in this game world,” not as navigating a financial dashboard.

OUTCOMES

What changed for players

and the product

Dropee has grown into one of Telegram’s most visible tap‑to‑earn games, attracting a broad audience that might never install a standalone crypto app. Engagement data shows strong participation in daily systems and event‑style content, validating the bet on lightweight rituals and continuously refreshed LiveOps. On the product side, the team now has a flexible UX and LiveOps framework that supports both game‑first players and those preparing for the upcoming TGE, without forcing a heavy Web3 journey on anyone.

Reflection

Designing for “easy in, evolving vibe”

Dropee reinforced that chat‑native games win when they are frictionless at the surface but opinionated in how they evolve. By obsessing over the first 10 seconds of play, then layering optional depth through LiveOps, token features, and AI‑augmented visuals, we built a game that can keep surprising players without ever feeling heavy. Designing inside Telegram and on top of no‑code tools pushed me to treat every pixel, prompt, and event as part of a larger conversation with the player—a conversation that can now change week by week as new vibes go live.

The Shift

Market changed; NFT sentiment shifted

Leadership decision: broader loyalty model

Keep Web3-native (NFTs, tokens) but expand to broader marketing use case, so incl. web 2

After (2023–2025)

SaaS loyalty platform for ongoing programs
Brands run ongoing quests + rewards for communities
Self-serve builder, measurable engagement, analytics

Before (2021–2023)

NFT utility campaigns (one-off, event-driven)
"Own this NFT? Get a concert ticket in NYC"
Great for hype moments, hard to show recurring value

Enable self-serve, no-code program creation —

Marketers should launch programs without engineering bottlenecks (vs. custom one-offs in the old model)

Drive repeat engagement & retention ——

The SaaS model depends on recurring participation, not one-time hype campaigns.

Reduce friction

in program setup ———

Complex rules, task types, and audience targeting had to feel simple and repeatable, not risky.

Double Tension/s

The core tension was this: we had marketers who were used to running one-off NFT campaigns, suddenly expected to build recurring loyalty programs. They were overwhelmed by all the builder options—task types, audience rules, caps, and scheduling. They feared misconfiguring something live. And they couldn't see what fans would actually experience. On the fan side, participants were used to 'claim a one-time reward and leave.' Now we wanted them to engage repeatedly. But tasks weren't scannable, progress wasn't obvious, and especially with Web3 elements like wallets, claiming felt risky or unclear. So the UX had to do two things: calm down the creator experience, and make the participant flow feel safe and rewarding.

Creators (Marketers)

Background: used to running one-off campaigns, not ongoing programs.

Problems

Overwhelmed by (double) builder complexity (too many options, unclear what impacts what)
Fear of misconfiguring or braking a live program (rules, caps, audience segments)
No imagination/visibility into what members actually see when they interact, so, previews?

Participants (Communities)

Background: members accustomed to claim-and-move-on, not recurring engagement.

Problems

Scope of tasks wasn't clear; unclear what the goal or reward was
Hard to track progress across quests; points felt abstract
Claiming rewards felt risky or unclear (especially with Web3 wallet interactions)

Design Strategy

Given those users and constraints, we needed principles that would scale. Web3 brings wallet and on‑chain complexity, but the UX had to feel like a normal SaaS tool. Creators needed to launch and iterate quickly, while we still supported both simple and multi‑week programs. That led to four principles you see here: first, a calm, familiar layout for the builder; second, progressive disclosure of advanced settings so the basics stay simple; third, a real‑time preview of what participants will see; and fourth, templates and presets so marketers can start from proven loyalty patterns rather than a blank canvas.

1. Calm, familiar layout

2. Progressive disclosure & safe settings

3. Real-time preview of participant view

4. Templates & presets for quick starts

Participants: Simple,

Scannable, Rewarding

On the participant side, we focused on making everything scannable and rewarding. The quest list uses clear typography and grouping so fans immediately understand what to do. Progress is always visible—points, entries, and completion status are all tracked in one place, which encourages repeat engagement. And the claim flow is simple and mirrors what creators previewed, so fans know exactly what they’re claiming and what happens next. That consistency between builder and participant views was key for trust.

Scannable quest list –

Clear typography and grouping; participants immediately understand tasks

Simple claim flow ––

Mirrors the creator preview; fans know exactly what they're claiming and what happens next

Progress visibility –––

Points, badges, and quest completion status tracked in one glance

Outcomes

2,400 loyalty programs shipped (proof of self-serve scale)

+305% claim completion rate (participants understood and trusted the experience)

+84% repeat participation rate (fans came back; the loyalty model worked)

Key Learnings: From

Web3 to Product Design

Design that shifts business models –

company pivots from 1-off campaigns to recurring engagement = UX has to support that intentionally
design transforms business further & opens new avenues

Self-serve + complex systems –

make technical, powerful tools feel simple through progressive disclosure
real-time preview, and templates
non-technical users don't fear complexity

Two-sided coherence –

creators build and members experience => both sides must feel like one system
creators don't see the participant view => misconfiguration and user frustration follow

⚒️ Builder UX

Clear and intuitive interface: Ensure that your builder's interface is easy to understand and navigate, using a clean and simple design. Use familiar design elements and patterns to help users feel comfortable interacting with the platform.
Contextual guidance and help: Provide tooltips, hints, or step-by-step guidance within the builder to help users understand the purpose and functionality of each option. Offer a searchable help center or in-app support for users who need additional assistance.
Progressive disclosure: Reveal more advanced features and customization options only when they're relevant or when users express interest in them. This prevents information overload and keeps the interface as simple as possible for new users.
Drag-and-drop functionality: Allow users to quickly and easily rearrange elements within the builder using a drag-and-drop interface. This offers a more intuitive and efficient way to organize and customize content.
Visual feedback and real-time preview: Offer real-time previews of how changes will look, so users can see the impact of their customizations immediately. Visual feedback helps users understand the consequences of their actions and reduces the need for trial and error.
Undo/redo functionality: Provide an easy way for users to undo or redo their actions, allowing them to correct mistakes and experiment with different options without fear of irreversible changes.
Responsive design: Ensure that the builder works seamlessly on various devices and screen sizes, offering a consistent and enjoyable user experience.
Templates and presets: Offer pre-built templates or presets to help users get started quickly and inspire their designs. This can save time and provide a foundation for customization.
Save and autosave features: Allow users to save their work at any point and provide an autosave feature to prevent data loss in case of an unexpected issue, such as a browser crash or power outage.
Comprehensive documentation: Offer clear and thorough documentation on how to use the builder and its features, as well as any best practices or recommendations for creating and customizing content.

⚒️ Builder UX

competitor analyses

⚒️ Builder UX for Web3

User-friendly interfaces: Like other successful builders, Web3 builders aim to provide intuitive interfaces that simplify the process of creating and managing blockchain-based products. They often use drag-and-drop functionality and visual editing tools to make the experience more accessible for users without deep technical knowledge.
Integration with blockchain networks: Web3 builders are designed to seamlessly integrate with popular blockchain networks, such as Ethereum, Binance Smart Chain, or Solana, allowing users to create and deploy their products on the desired network easily.
Smart contract templates: Web3 builders often include pre-built smart contract templates for various use cases, such as NFT creation, token sales, or decentralized finance (DeFi) applications. These templates can be customized to fit the users' specific needs, significantly reducing the complexity of writing smart contracts from scratch.
NFT creation and management: Web3 builders focusing on NFTs enable users to design, mint, and manage their NFT collections. They often provide a range of customization options, allowing users to create unique digital assets with various attributes, metadata, and utility functions.
Wallet integration: Web3 builders typically integrate with popular cryptocurrency wallets, such as MetaMask or Trust Wallet, to facilitate secure transactions and interactions with blockchain networks.
Decentralized storage solutions: To ensure the decentralized nature of their products, Web3 builders often incorporate decentralized storage solutions, like IPFS or Filecoin, for hosting digital assets and metadata.
Interoperability: As the blockchain space evolves, Web3 builders are increasingly focusing on interoperability between different networks and platforms, allowing users to create products that can interact seamlessly with various blockchain ecosystems.

Flow/ Main creation

asset_AmSSgNWzp2V7uHFd8x9xkp99_background-removal_1769246140.png