A tap-to-earn game built as a configurable system

• 7.5M+peak monthly users
• 13M+total users
• 3M+connected wallets
• #1DappRadar on TON
• 5B+main-wheel spins

These numbers reflect Dropee's total product growth as a small team; my role was end-to-end design across the core loop, LiveOps systems, and token UX, working with product and engineering toward retention, virality, and TGE-readiness goals set by leadership.

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.

CHALLENGES

What made this hard

The hard problems weren't visual — they were structural. With no app store to lean on, the game had to earn its own distribution by being worth sharing.

LiveOps were being built as one-off features, which couldn't survive the team's shipping pace — I made the case for treating events as configurable data instead, building the NocoDB schema alongside the first event rather than "systematizing later." Each new season raised the same tension between novelty and familiarity, so I argued for targeted redesigns of only the surfaces players touch most — visible change where it signals freshness, stability in the core loop that carries retention.

The token layer had to serve two audiences in one interface: casual tappers who just wanted to play, and crypto-native players heading toward airdrops and staking. Keeping $DROPEE optional but present let us support TGE-readiness without taxing day-one retention.

ROLE & RESPONSIBILITIES

Owning the game experience end to end

I owned Dropee’s end-to-end game experience across the Telegram mini-app, including the 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 that underpins it—from high-level interaction patterns 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

Influence

The LiveOps package system started as a design-side proposal. Events were being built as one-off features; I made the case for treating them as configurable data instead — building the NocoDB layer alongside the first LiveOps rather than systematizing "later" — and prototyped the first package on Lovable. That model became the team's standard way of authoring events. I also shaped how Dropee evolved between seasons: when the lean option was to carry the same look forward season after season, I argued that targeted redesigns of the surfaces players touch most would keep the game feeling alive — visible change where it signals novelty, stability in the core loop that carries retention. That became the seasonal pattern, and it's why players never had to relearn the game as it grew.

Design System

Selected product surfaces

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. 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.

MONETIZATION SURFACES

Designing the offer, not just the shop

As the sole product designer, I owned every monetization surface across two Dropee seasons, Beetz and Stakerz—including shops, boosters, welcome packages, contextual offers, seasonal promotions and Telegram Stars purchase flows. I defined the interactions, produced the final artwork, and worked with product and engineering to ship them inside the live games.

Matching the offer to player intent

Sessions lasted 30–60 seconds, so an interruption could cost us the session before it created a purchase. I designed two versions of the spin offer around demonstrated intent: Players who entered the wheel without enough spins saw one calm option at one price, and players who actively tapped Spin with an empty balance had already tried to continue, so they saw three packages with a clearer value comparison.

Both versions kept a live countdown showing when three spins would regenerate for free. The timer served two purposes: it reassured players that the wheel remained accessible without paying, while making the cost of waiting concrete. By comparing a visible delay with immediate continuation, the purchase became an accelerator rather than an access fee.

In a Telegram mini-app—with no installation and almost no switching cost—I prioritised this transparent time trade: wait and continue for free, or pay to continue instantly. This followed an established free-to-play pattern, but its effect remained a design hypothesis. Ideally, we would have tested the countdown’s visibility and messaging against purchase conversion, offer dismissal, and return behaviour.

Making value readable at mobile scale

At 375px, every package had to communicate its value almost instantly. Progressive tier names—Warm Up, Push Ahead and Beast Mode—combined with increasingly prominent reward artwork to create a visual progression between the options.

I used one restrained “Best Offer” marker to establish a clear value anchor without turning every card into a competing promotion. Elsewhere in the shop, explicit quantities, availability limits and countdowns replaced vague urgency, while a free Mystery Box introduced the reward format before players encountered the paid tiers.

Guiding the payment decision

Dropee supported Telegram Stars and alternative payment methods with different fee structures. At checkout, I highlighted the commercially preferred option with a visible discount, while keeping every alternative transparently priced and one tap away.

This guided players toward the lower-cost payment route without hiding their choices or adding friction to the purchase flow.

Scaling these monetization surfaces—and the seasonal content around them—required a visual production system that could create variety without losing Dropee’s identity.

VISUAL SYSTEM & AI ART DIRECTION

Scaling art direction with GenAI

To support monetization and seasonal LiveOps at speed, I built a repeatable visual production system for offer artwork, event icons, backgrounds, currencies, and badges. I defined the rules for form, palette, lighting, depth, and composition, then trained a dedicated Dropee V2 LoRA to generate starting points within that visual language.

For each event family—including Valentine’s Day, Carnival, and St. Patrick’s Day—I created a compact design kit covering icon shapes, background composition, badge framing, and screen treatments. Scenario and Weavy accelerated exploration, but I selected and refined the results in Figma, adjusting colour, contrast, hierarchy, and depth so they worked as interface assets rather than standalone illustrations.

Style rules + generation workflow

Preparing assets for live product conditions

The assets were designed for localisation and responsive behaviour. Screen copy remained editable, compositions protected flexible text areas, and focal elements stayed centred so the artwork could withstand different crops. Final exports were compressed to WebP to protect loading performance inside the Telegram mini-app.

This system allowed me to prototype a complete event language—icon, background, badge and screen treatment—within a day, while keeping every theme recognisably Dropee.

Assets prepared for LiveOps

One production system, three event families: style-controlled generation became a consistent set of icons, backgrounds, badges and finished screens.

Testing motion before rollout

I also prototyped animated promotional assets and tested transparent WebM exports inside the Telegram webview. The animation worked in our Android tests but not reliably on iOS, so we stopped before rollout. Testing it early prevented us from committing further production effort to a format we could not support consistently.

Motion prototype tested from generated concept through transparent in-game export.

LIVEOPS & VIBECODING

Reusable package in NocoDB

LiveOp draft in Lovable

From reusable families to finished LiveOps

With the data layer in place, I used Lovable as an implementation-near design workspace to turn reusable families into polished LiveOps packages. Each family defined the core mechanic; my role was to shape the package layer on top—layout, narrative, hierarchy, states, progress, buttons, and feedback—until the LiveOp felt like a finished mini-game inside Dropee rather than a skinned template.

Starting from a base family file, I created new layouts, refined hierarchy, tuned spacing, and adapted states across themes until each package felt production-ready on mobile. I then connected it to NocoDB, tested it inside Dropee’s Telegram flow, and iterated on readability and feedback so one family could support multiple packages without extra engineering work.

→

Production assets and content are filled through NocoDB

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.

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

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. 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.

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.