Battle of the Bees - business consulting and prototyping of a mobile game and Telegram Mini App

A team of developers came to us with a technical question: why do investors refuse to put money into the game if its click protection is the best on the market and the people playing it are real rather than bots. The answer to that came quickly, but the next question arrived right behind it: and what then. So we went through the market and the economy and built a prototype of a product.

Industry

Games, Web3

Services

Business consulting, Prototyping, Design, Web3 experience

Period

2024

The question it all started with

They reached us through personal contacts, through a developer who has been on our team for a long time. The question was purely technical, with no regard for the market or for how the person on the other side of the screen makes a decision: our click protection is the best on the market, there is a guarantee that real people are playing rather than click farms, so why do investors walk past.

A wave of tappers was under way: after Hamster Kombat one game after another was appearing in Telegram. A strong engineering team decided not to watch it from the sidelines and built its own technical prototype. The character came from a beaver meme that was everywhere at the time: people quoted it, dropped it into chats and played with it at every turn. The plan rested on exactly that popularity: a recognisable character brings the audience by itself, a crowd gathers, investors follow, and everyone gets their crypto.

The argument itself is fair: after Hamster Kombat, where bots were everywhere, a live opponent is worth more than a click farm, and competing against a person is more interesting than competing against a technology. Only that is a condition, not a reason to install a game, and it is not what an investor counts. Between "people are having fun" and "the product earns" they always choose the second, while knowing that the second does not happen without the first. What they look at is retention and money: how many people come back tomorrow and what they pay for. People come to a game to have a good time, and they pay where waiting is annoying or where they want to pull ahead of everyone faster. The technical question we answered in a single conversation. Everything else had to be worked out.

The market first, the screens after

We went through what people play besides the hamster: which mechanics hold them, where players pay, what brings them back the next day and what falls away after a week. A simple tapper could have been drawn in a couple of weeks and paid for. We proposed something else.

Why bees and not a beaver

A meme gives the first reach but no continuation. With a beaver the game hit its ceiling quickly: beavers live alone, they cannot be gathered into a colony, and so there is no team to build, no shared goal and no reason to invite friends. Everything that could be offered next was the same tap with a new picture.

We needed a species that lives as a community by itself, so that the team part would look natural rather than bolted on. We went through the options and chose the friendliest of them: bees. A hive, a swarm, roles inside it, a shared harvest, all of it familiar to anyone since childhood. No aggression, no predators, no fight for survival, just joint work with a visible result.

This was not a change of picture. Along with the species, the thing the game rests on changed: from a solitary counter to a community.

The tap is the entrance, not the whole game

The tap stays the first action, but development starts after it. A storehouse and a dwelling appear, resources become different things rather than one counter, and squads and alliances follow. At the end of the chain comes the competitive part, where a player meets another player rather than a timer.

The economy before the interface

First the concept, then the basic economy: five resources, energy as a limit on pace and income per hour that accrues without the player. The game loop grew out of the economy, and only after that did we sit down to the screens.

The other way round does not work. Until it is clear what the player owns and what they spend it on, there is nothing to put in the header and nothing to hide deeper. This is exactly where most prototypes stumble: the screens are beautiful, and nobody can explain what happens on them.

Why the player comes back tomorrow

The daily reward is not a list of prizes but work with a habit, and it was built out of several considerations at once.

First: the chain has to feel like something accumulated rather than a gift. So the reward grows non-linearly, and by the end of the week missing a single day costs more than everything the player collected in the first days. What works after that is not greed for the prize but the reluctance to reset what has been done. It is the cheapest and the most honest way to retain: the player loses nothing already received, only the multiplier.

Second: a short feedback loop. The audience of tappers is not uniform in how it holds attention, and a noticeable part of it simply will not play something where the response arrives a minute later. So our actions are short, the result is visible instantly, and the next step is clear without reading the rules. What suits a person with scattered attention turns out to suit everyone else too.

Third: reasons to return of different lengths. The daily reward is once a day. A combo takes several sessions. The timers on the Rich Glade and the Buzzer run out in a couple of hours. A player with any daily routine finds their own rhythm, and none of these reasons requires sitting in the game for long.

What we deliberately did not do: mechanics that punish a missed day by taking away what was earned or rolling back progress. That kind of pressure lifts the first month's numbers and kills the game in the third.

They pay where waiting is annoying

The exact amounts do not matter here, their order does: any purchase in the game costs less than a cup of coffee.

The logic is not about games but about everyday life. Someone who buys coffee every day adds a doughnut for a dollar without thinking. The sum requires no decision, it is not missed and it is not considered. They treat a purchase inside a game exactly the same way if it costs the same: it is not spending, it is small change along the way.

What matters next is what exactly is being paid for. We sold neither access nor victory. What was paid for always removed a routine: it sped up something the game had deliberately made slow, or automated an action that had been designed as a barrier. The barrier itself stays passable for free, it just takes longer.

Such monetisation has two consequences. The balance does not break: whoever does not pay arrives at the same place. And the paying player buys no superiority over others, they buy their own time. This is what we proposed to the client back at the consulting stage, because in a tapper the money comes from here and not from selling an advantage.

A tapper is only the entrance

The daily reward, the combos and the timers gather an audience, but they do not hold it for long. A repeated action runs out of steam in a few weeks, however generous the prize.

A long life for the game was to come from the second half of the loop: team actions and encounters between players. That is where something appears which a solitary tap cannot give. The result depends not only on your persistence, there is someone to share it with and someone to discuss it with.

We built a payout back into that. Part of the money the game earned on premium purchases returns to the players in the next period. Roughly: the game collected a thousand units of currency, half goes into the prize pool and is distributed for team actions, wins and completed goals. The player sees that money moves in both directions, and the team of players gets a reason to gather not for a percentage from invitations but for a shared result.

That was also the answer to the original question about investors. The tap gathers the audience, but it pays and stays for the team part, and that is the economy an investor counts.

A swarm, not a referral link

A referral programme in tappers usually works like a mailing list: hand over a link, get a percentage. It brings traffic once and creates nothing that keeps a person afterwards.

We designed something else. Invited players gather not into a list but into a swarm: it has shared progress and shared benefit, and part of everyone's harvest falls into the common hive. A person invites others not "by link" but to themselves, and afterwards holds on not to the percentage but to those they invited. The nearest clear analogy is a family: a small group where everyone's contribution is visible and where slipping away quietly feels wrong.

Out of this grows the thing the whole exercise was about. A language appears inside the swarm: what members call each other, what they call the actions, which jokes they repeat. Its own language is the main sign of a living community and at the same time what carries the game outwards. People retell it where the game is not, and that works better than any referral link.

This can be steered only up to a point. We designed the occasions: roles inside the swarm, shared goals, states worth showing to others. After that the community takes the game for itself and invents its own. We discussed that boundary with the client separately, because it is the answer to the original question: you cannot go viral on a joke alone, you can only prepare the ground and let go at the right moment.

Airdrop as a funnel

The tasks are tied to outside platforms: invite three friends, subscribe to Telegram, X and Discord, connect a wallet and receive a starter chest. The screen shows both what is done and what opens next, so the list reads as progress rather than as requirements.

The wallet

Connection through Bybit, Binance, MetaMask and others, with the address shown and disconnection in one step.

Six months of iterations

The work itself came to two or three months. On the calendar the project stretched to six: the client approved, thought it over and made changes along the way. That mode was agreed in the contract in advance, so it went without arguments about deadlines and without blind overtime.

During that time partner programmes, the referral scheme, alliances and squads kept appearing in the scope and going back into the backlog. Some resources were added, some disappeared. That is the normal course of work on a game: until the loop adds up, the set of features keeps changing, and it is better to change it on paper than in code.

What we handed over

The agreed number of screens, the concept, the basic economy, the game loop, the art and the documentation - everything needed to hand the product on to development. We wrote no code: at this stage it was not needed, and without answers to the questions about retention and money it would have been written for nothing.

Thank you for reading the FAMOUS.TEAM case on business consulting and prototyping of a mobile game and Telegram Mini App.