01The product

DogecoinAI is a Telegram Mini App. Users deposit funds, run automated trading sessions, move up through five account tiers and invite friends for referral rewards. Everything happens inside Telegram, so there's no app store download and no separate account to create.

I lead its design and engineering: the interface, the back end, payments, the bot and the landing page. More than 12,400 people have used it since launch, it has handled over $250K in trading volume, and it now processes 500+ trades every day.

Living inside Telegram shapes every decision. The screen is a phone held upright, the user has just tapped in from a chat, and they expect the app to feel as simple as the chat they came from.

02Older users were getting stuck

Soon after launch, the client's admin started passing on the same kind of message: people couldn't get through sign up. Looking at who was writing in, a pattern stood out. Many of them were older users, often new to crypto and not confident with apps.

The first version of onboarding had been designed the way I'd design for myself. It was compact, with small type, several fields on a screen and error messages written for someone who already knew what had gone wrong. For an experienced user it was quick. For someone unsure of every tap, each screen raised a question, and each question became a message to the admin.

The cost was bigger than lost sign ups. Every stuck user became support work for a small team, and people who struggle to get started are slow to trust an app with their money.

03What I changed

I rebuilt the flow around one rule: every screen answers one question and asks for one thing.

• Bolder, larger text. Instructions became readable at a glance, without squinting or zooming.
• One clear call to action per screen. Each step has a single main button that says exactly what it does.
• Fewer fields. I removed every field we didn't need to get someone started.
• Short errors that guide the next step. Instead of a vague "invalid input", each message says what went wrong and how to fix it.

The trade-off was length. Simpler steps meant more screens, and more screens can feel slower to someone who already knows what they're doing. I accepted that. The people dropping out needed clarity more than speed, and a confident user still gets through a simple screen in a second.

Every screen answers one question and asks for one thing.

04The result

After the new onboarding shipped, about 20% more users completed sign up, and help requests to the admin dropped sharply. The same principles now carry through the rest of the app, including a clearer withdrawal screen and the five-tier account system, which I shipped to live users without taking the app offline.

The product has kept growing on that foundation: 12,400+ users since launch, over $250K in trading volume, and 500+ trades a day.

05When a mistake stopped withdrawals

Not every problem lived in the interface. One day withdrawals stopped working. The cause wasn't a bug in the app but a mistake made in the admin panel.

I got withdrawals working again, but undoing the mistake only fixed that day. The real problem was that one wrong step in the admin panel could break the feature users care about most. So I added safeguards in the code that stop the same mistake from breaking withdrawals again.

That changed how I think about admin tools. They're part of the product too, and they need the same protection against mistakes as anything a user touches.

06What I'd do differently

Measure from day one. The 20% lift and the drop in help requests come from the client's own figures, not from tracking I set up. Next time I'd record where people stop during onboarding and count support requests before and after each change, so the result is a number rather than an impression.

Test with older users before launch. The problems they ran into were predictable. A few short sessions with people like them would have caught most of it before anyone got stuck.

01The idea

Cryptic Kaspa is a play-to-earn game hub inside Telegram. Players fund a Kaspa wallet, choose a stake and play head-to-head chess, word scramble or a crypto quotes quiz. Winners are paid in KAS, Kaspa's own coin. I was the lead design engineer, responsible for how the app looked, played and worked.

Kaspa is a fast proof-of-work blockchain with a growing community. When we started, people were mostly holding and trading KAS, and very few apps gave them anything to do with it. We wanted a game that gave the coin a real use: put some on the line, play, and win more.

02No road to build on

On older chains like Ethereum, building a game that takes deposits and pays out winnings is well-trodden ground, with libraries, documentation and plenty of examples. Kaspa had none of that for what we wanted to do. There was no public tooling for funding wallets, holding bets and paying winners from an app like ours, and no earlier project to learn from.

That left two poor options. We could build our own low-level connection to the chain, which would be slow and risky with players' real money involved. Or we could wait for public tools that might take months to arrive.

03Working with the Kaspa core team

We took a third route and went to the people building Kaspa itself. We explained what we were making and why it mattered for the ecosystem: a working consumer app would show what KAS could actually be used for.

The core team agreed. Because no one had built this kind of app on Kaspa before, they gave us access to their internal SDK, the toolkit they used themselves. That gave us a reliable, supported way to handle wallet funding, bets and payouts instead of guessing.

Building this early meant learning alongside them. When something didn't behave as we expected, there was nothing to search for. We asked the core team directly, and those conversations shaped how the game was built.

When the tools don't exist yet, the fastest route is often a direct conversation with the people building the platform.

04Designing for real stakes

Players were putting real money on every game. That gave the design one job: make every step clear enough that nobody places a bet they didn't mean to, or wonders where their money went.

• Balance first, then the stake. The home screen leads with the player's wallet balance and fixed stakes from 50 to 300 KAS. Players pick an amount, pick a game and press Start Game. Home, Store and Wallet tabs keep the money one tap away.
• Clear terms before every match. Before chess starts, players see the current bet, their wallet balance and a choice of 3, 5 or 10 minute games. Nothing begins until they confirm.
• A contest you can see. In chess, both players and both clocks stay on screen, so a match feels like a fair game against a real person, not a black box.
• The result is the reward. Win screens state the payout plainly, like "You've won 7.50 KASPA coins!", with one button to play again.

05Why it mattered

Cryptic Kaspa was one of the first consumer apps where people put real KAS on the line and got paid out in it. It showed that kind of product could work on Kaspa at a time when there was no public way to build one.

It also changed how I approach new platforms. I no longer treat missing documentation as a wall. The people behind a young platform usually want builders to succeed, and asking them early saves weeks.

06What I'd do differently

Write down what we learned as we went. We worked out how to build on Kaspa before most people had, but that knowledge stayed in our team and our chats. Publishing it, even as short notes, would have helped the next builders and shown our work more clearly.

Plan for what happens after launch. Getting the game working on a brand new chain took most of our energy. I'd now set aside time early for what keeps players coming back once the novelty wears off.