The Mini Apps Competition community is growing, and the earlier you’re in, the more time you have to find your idea, test it, and show up on July 6 ready to build and ship. Curious where everyone is at right now. Vote below!

I am building a PvP game based on Rock-Paper-Scissors mechanics. Instead of making it a simple luck-based game, I'm designing it to be more skill-based through strategy, prediction, weapon passives, and ultimate abilities. Progress Update ⚔️ The core combat system is now implemented with 4 unique weapons, each featuring its own Passive Ability and Ultimate Skill to create different playstyles and strategies. Weapons currently available: ⚔️ Sword – Momentum stacking & Blade Rush 🪓 Axe – Critical strikes & Berserk mode 🔱 Spear – Prediction-based counter gameplay 🧙 Staff – Healing, sustain, and buff removal Combat is based on a Rock-Paper-Scissors style system: 🛡 Guard beats Slash ⚔️ Slash beats Counter ⚡ Counter beats Guard Counter victories deal higher base damage, while weapon passives and ultimates can dramatically change the outcome of each round. Next step: polishing battle flow, matchmaking, and Nimiq Mini App integration. ---wish me luck, im just using claude lol ;v

The most creative reply gets a follow back from the official Mini Apps Competition X account. Make sure you’re following us. 👀 🔗 https://x.com/miniappscomp

I just finished my first full implementation pass. Nothing polished to show yet, but I went through the whole cycle: gameplay, game logic, and Nimiq Mini App support. The biggest thing I learned is probably worth sharing, especially for people like me who are new to Android/iPhone-style app development. I started by building the game idea on desktop with Codex/GPT. That felt natural: browser, mouse, keyboard, local dev server. Mini App support was the last step in my plan because I treated it mostly as a competition requirement. After implementing it, I think I would reverse that order next time. The Nimiq Pay Mini App path is not just a checkbox at the end. It defines the real competition runtime: your web app runs inside the Nimiq Pay mobile app/WebView. That means the critical path is phone-first: touch controls, small screen layout, safe readable text, mobile viewport behavior, local-network testing, and Nimiq Pay’s connection/approval flow. The app can still be a normal web app on desktop, but if the competition target is Mini Apps, then the Mini App runtime should probably be tested early, not late. For a beginner, the trap is easy: you build a game on desktop using mouse and keyboard, everything feels fine, and then a few days before the deadline you realize the actual judged experience is a touchscreen phone flow. That could turn into a lot of unexpected high-intensity work. My takeaway: Start with the Nimiq Pay Mini App integration early. Then build the gameplay inside those constraints. P.S. actually codex warned me about this quite early. Its exact words when I started to make the implementation planning "Even a tiny placeholder scene is enough. The important thing is to verify the runtime, input model, and Nimiq Pay flow before the game becomes complex."

We are building NimHub, an AI payment system that allows you to speak and chat with your money. In times where AI models are used for all sorts of utility. NimHub decided it will be your assistant to help you send NIM, convert NIM to local currency, pay bills, send gift cards to loved ones, and buy airtime/mobile data. This is the tip of the iceberg; this is your crypto bank and advisor in real time.