Telegram-native Tap-to-Earn Game

Dropee is a Telegram-native tap-to-earn game designed for fast, repeatable play inside chat. Players tap, complete daily mini-challenges, and return for LiveOps events that keep the experience fresh without adding friction. As Lead Product Designer, I shaped the core loop, reusable LiveOps system, and TGE-ready UX across the product.

2024 – 2026

View Product

Telegram-native
Tap-to-Earn Game

500K+

monthly users

15M

total users

3M

connected wallets

#1

DappRadar on TON

5B+

main-wheel spins

Context / Opportunity

Designing games for Telegram, not app stores

Dropee wasn’t designed for app stores. It was designed for Telegram: a chat-native environment where discovery happens through links, forwards, screenshots, and bot messages, and where players expect instant entry with almost no setup. That changed the product challenge. We had to make the game fast to start, light enough to revisit in short sessions, and easy to share—while still deep enough, through progression, economy, and LiveOps, to keep players engaged beyond the first curiosity tap.

The game opens inside Telegram

Entry happens through bot messages

Role & RESPONSIBILITIES

Owning the game

experience end to end

As Lead Product Designer, I owned Dropee’s end-to-end game experience across the Telegram mini-app: core loop, UX flows, LiveOps surfaces, and event visual language. I worked with product and engineering to turn goals like retention, virality, and TGE-readiness into concrete mechanics such as Daily Combo, Question of the Day, and repeatable event surfaces designed for Telegram’s constraints. Beyond core gameplay, I led the design of the LiveOps system and the reusable component language behind it—from high-level interaction patterns down to production-ready UI details.

Owned

Core loop and UX flows
LiveOps surfaces and repeatable event patterns
Telegram-native interaction design
Event visual language and reusable UI components

Partnered with

Product strategy, retention, and feature framing
Engineering implementation and system constraints

Reusable UI system across gameplay and LiveOps

Shared buttons, navigation, feedback states, and event patterns across Dropee’s core surfaces

How the system shipped across the product

Splash

Home

LiveOp event surface

Utility modal

Selected product surfaces

Splash

Home

LiveOp event surface

Utility modal

CORE GAMEPLAY LOOP & DAILY SYSTEMS

Design strategy:

short sessions, long arcs

Dropee’s core loop was deliberately simple: tap to earn coins, spend them on upgrades or milestones, and see progress respond instantly. As Lead Product Designer, I shaped the 30–60 second session around a few clear actions—open the bot, tap, claim, maybe make one upgrade—then layered in lightweight daily systems like Daily Quests, Daily Combo, and Question of the Day to add direction, novelty, and reward pacing without turning the experience into a grind. The goal was to make short sessions feel rewarding on their own, while still feeding longer progression arcs over time.

Daily systems added direction, novelty, and reward pacing without extending the core session

LIVEOPS & VIBECODING

Designing LiveOps as

games within a game

1. Turning LiveOps into a configurable product system

To keep LiveOps fresh without rebuilding them from scratch, I treated them as a configurable product system rather than a series of one-off features. Together with our backend team, I defined a NocoDB schema that describes each event in the same way—steps, costs, rewards, cosmetics, and timing—so a “Pathway” LiveOp becomes data the game can read and render. Over time, I pushed that into an XML-style prompt framework where we can duplicate an event, change a handful of variables, and generate a new LiveOp from the same building blocks.

---
package: Badge Room — Trophy Cabinet
type: Reusable LiveOp package
surface: mobile-first iframe widget
authoring knobs: theme / thresholds / reward mix / pacing
---

<runtime_contract>
parent → widget: INIT_DATA / PROGRESS_UPDATE / PAYMENT_RESULT widget → parent: READY / CLAIM / CLOSE / HAPTIC raw payloads are normalized into a clean internal model
</runtime_contract>

<playable_logic>
players earn event currency and unlock badges sequentially claimable = next threshold reached with enough balance claimed badges update cabinet state and trigger celebration all-complete state opens final reward overlay
</playable_logic>

<experience_rules>
skeuomorphic 3D cabinet with glass shelves, jewel lights, pedestals mobile-first layout (~375px), HSL-only system, fixed CTA dimensions same package can be reused by changing theme, thresholds, and rewards
</experience_rules>

… plus visual direction, motion, contraints, and implementation layers

Package Metadata

Runtime Contract

Experience Rules

Authoring spec → Parent config →

LiveOp package → Player experience

Spec → Config → Package → Experience

A reusable LiveOps package defining logic, communication, and experience rules

I designed this prompt framework so LiveOps could be authored more like reusable packages than one-off features. Each package defines the event’s runtime contract, progression logic, and experience rules, while backend translates the spec into config and the frontend renders it as a playable event. That made it possible to iterate at the speed of design decisions, keep the UX consistent across different themes, and create a foundation for future community-authored events without breaking the game’s economy or structure.

Each package defines

event metadata
runtime communication
progression logic
reusable experience rules

Reusable package in NocoDB

LiveOp draft in Lovable

Shaped in Lovable, then structured in NocoDB as reusable LiveOp packages

Design → Structure

2. Turning base mechanics into finished LiveOps

With the data layer in place, I use Lovable as my vibecoding workspace to turn base mechanics into polished LiveOp packages. We’ve built multiple families—Pathway, Chance, Lucky Draw, Special Wheel, Progressive Lane—where each family defines the core mechanic, and I shape the package layer on top: layout, narrative, hierarchy, and visual identity.

My role here is to build and iterate on each package end-to-end in Lovable. Starting from a base family file, I create new layouts, refine hierarchy, and design the UI states, cards, progress, buttons, and micro-interactions until the LiveOp feels like a finished mini-game on mobile. I then connect it to NocoDB, test it inside Dropee’s Telegram flow, and tune spacing, readability, and feedback so one family can support multiple packages and themes without extra engineering work.

Base family file from backend

LiveOp package designed in Lovable

Production assets and content are filled through NocoDB

2. Turning base mechanics into finished LiveOps

Base family file from backend

LiveOp package designed in Lovable

Production assets and content are filled through NocoDB

Visual System & AI Art Direction

Building a reusable visual system with GenAI

On the visual side, I design all LiveOps graphics myself and use generative AI as a long‑term collaborator tied to Dropee’s visual identity. I trained a dedicated Dropee V2 LoRA in Scenario and complemented it with Weavy, so every icon, background, and badge—no matter the event or Family—still “reads” as Dropee and plugs cleanly into our UI system.

For each theme—Valentine’s Day, Carnival, St. Patrick’s Day, Chinese New Year, and beyond—I define a compact design kit: icon shapes, background composition, badge framing, and motion hints. I then use Scenario/Weavy to generate event-level assets and curate them into cohesive packs for our LiveOps: wheel icons, pathway backgrounds, Plinko boards, progressive lanes, and completion badges. From there, I pull them into Figma and Lovable, align them with the UI system, and tune contrast, color, and depth so they work as production interface assets, not standalone illustrations.

Style rules + generation workflow

Assets prepared for LiveOps

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 let us ship “games within the game” with distinct iconography, backgrounds, and badges while preserving one coherent Dropee visual language.

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.

Assets prepared for LiveOps

This let us ship “games within the game” with distinct iconography, backgrounds, and badges while preserving one coherent Dropee visual language.

CX, Economy and TGE‑ready UX

Keeping the crypto layer optional but present

For many players, Dropee was “just a game” they opened between messages; for others, it was also a path into real token participation. I designed the crypto layer as optional but present: clearly signposted paths for learning about $DROPEE, joining airdrops, and connecting a wallet, all kept out of the way of players who only wanted to tap and play. The goal was to keep onboarding ultra-clean while making token depth feel like a natural continuation of the game rather than a hard mode-switch.

More broadly, I shaped the $DROPEE layer as a set of adjacent experiences that felt like extensions of Dropee rather than separate DeFi products. Inside the Telegram mini-app, players saw light-touch prompts—airdrop teasers, simple token explainers, and one primary next step. When they chose to go deeper, the presale launchpad and the airdrop claiming + staking dApp reused familiar game patterns like progress, rewards, and minimal forms, so connecting a wallet, depositing, claiming, or staking still read as managing progress in the Dropee world, not navigating a financial dashboard.

In-game token layer

From lightweight in-game prompts to deeper wallet flows, the token layer was designed as one continuous ownership journey.

Airdrop claiming + staking dApp

Presales launchpad

OUTCOMES & REFLECTION

What changed for players, the product, and my design approach

Dropee evolved from a simple tap-to-earn loop into one of Telegram’s most visible game ecosystems, with Daily Combo, Question of the Day, LiveOps events, and TGE-ready UX becoming part of how players understood “playing Dropee,” not just collecting a one-off reward. Season 2 proved that we could layer in airdrops, seasonal events, badges, and deeper progression systems while keeping the core loop lightweight, legible, and easy to return to.

More importantly, the project proved that a live game could grow across seasons and business milestones without forcing players to relearn the interface. As Lead Product Designer, I helped turn Dropee from a single game loop into a repeatable product system: one that could support new event structures, visual refreshes, token participation, and broader LiveOps ambitions while preserving trust in the core experience.

Core loop established

Daily systems and LiveOps layered in

A more deliberate multi-season system

It also changed how I think about design leadership. The challenge was not just shipping features, but building a system that could evolve without losing clarity. Dropee taught me how to balance stability and change at the same time: protecting the core loop, while creating room for new mechanics, business layers, and seasonal identity to emerge around it.