Building a Web3 skill-gaming platform
I've been heads down building Deskillz Games and figured it's time to start sharing the journey here.
The idea: most "play-to-earn" projects ask you to build a whole new game around a token. I wanted the opposite. Deskillz lets developers take a game they already have Unity, Unreal, or web and plug it into our ecosystem through a cross engine SDK. Players download games from the main app, pay an entry fee in crypto (BNB, USDT, USDC, TRON), and compete in skill-based tournaments. Revenue gets shared with the devs who integrate. The skill part matters: this isn't gambling; it's tournaments where the better player wins.
Where it's at right now:
6 games live (Big 2, Mahjong, Dou Dizhu, 13-Card Poker, plus a couple of arcade titles)
On-chain prize vaults on BNB Chain for tournament custody
Private rooms where any player can host their own tournament and take a cut
One SDK targeting Unity, Unreal, and web, with web games wrappable to APK/iOS/PWA
The part nobody warns you about: I'm a team of one. Backend, frontend, smart contracts, the build pipeline that wraps games into installable apps all vibe coding. The hardest problem wasn't the blockchain side, it was making a single shared SDK behave identically across three totally different runtimes without breaking every time I ship an update.
A few hard-won lessons so far:
Treat your shared SDK files as sacred the moment you patch them per-game, you've created a maintenance hydra. Wholesale-replace through a release pipeline instead.
The DB is the source of truth; the chain is the settlement record. Make on chain calls fire-and-forget so a slow RPC never blocks gameplay.
Your viral loop probably isn't where you think. For me it's the "host your own room and earn" feature, not the games themselves.
Still very much pre-scale and figuring out distribution — which is honestly the scariest part after building all this.
For those who've shipped a developer SDK or a two-sided marketplace: did you focus on getting the supply side (devs) or the demand side (players) first? I keep going back and forth on which to chase.
The detail that stayed with me wasn't the supply-vs-demand question.
It was the assumption that both sides are currently playing the same role in the business.
Reading this, I found myself wondering whether the real challenge is deciding which side the company is actually being built around, and which side exists because it helps the first side succeed.
Those can look like the same marketplace early on while leading to very different decisions later.
The hardest problem wasn't the blockchain" is a sentence 95% of solo founders will recognize. The hard part is keeping 5 workstreams alive in your head at once while also being the only person who can advance any of them.
Genuine question: when you sit down to work each day, how do you decide which one to touch first? Not the "most important" one — the one you'll actually finish something on. The cognitive load of being the only owner of 5 threads is rarely talked about because nobody wants to admit they're spending 40% of their day just figuring out what to do.
Building What Next for exactly this problem on the knowledge-work side so I'm collecting examples. If you've got a current "today I'm doing X because Y" heuristic, I'd genuinely love to hear it.
On supply vs demand: SDKs need both sides to feel real or neither side cares. The trick is finding the one dev who has a game people already want to play, then building the case around them that the supply side can rally to. Otherwise you're selling an empty room.
Built a lot, but this feels like one of those products where distribution and trust become the real product. Players need proof the tournaments are fair and devs need confidence this ecosystem will still matter a year from now. Saw this pattern before, the tech gets finished long before the credibility layer does.