Overview
Nightpixel is a consumer gaming platform — the easiest way to describe it is Nutaku, but non-adult. Players land on a catalog of online games, pick one, and play it directly on the platform, with a single token wallet that follows them from game to game and into the shop. The games themselves come from a range of studios; the platform's job is to make them feel like one coherent product — one login, one balance, one place to discover and play.
I led the engineering and, just as importantly, the launch. That meant building the pieces that let an outside game plug into the platform, wiring up the real-money systems behind the token economy, shipping the clients people actually use, and coordinating the integration work with the game teams — several of them in China — so that everything came together in time to go live.
The product
The platform is a catalog plus an economy. The catalog is the discoverable surface — 50+ games, profiles, favourites, tournaments and community features around them. The economy is what ties it together: a token wallet that players top up once and spend everywhere, whether that's an in-game purchase inside a third-party game or something bought directly in the platform's shop.
The interesting engineering problem sits at the seam between those two halves. A game made by another studio, running on its own servers, has to be able to authenticate a Nightpixel player, read their token balance, and deduct tokens for an in-game purchase — securely, and without ever being trusted with anything it shouldn't have. Getting that seam right, for many different games and teams, was the core of the work.
Integrating third-party games
Games run embedded in the platform, and they talk to it through a Game SDK I built. On the client side the SDK is a small TypeScript library a game drops in: it exposes a GameApi for authentication and user profile, a Wallet for balance queries and token deductions, an event system for game state, and a PostMessageWrapper that brokers all of this over a secure iframe boundary. The game never touches the platform's session directly — it speaks to the parent frame through a controlled message channel, and the platform decides what each request is allowed to do.
Behind that sits the server side. The platform issues scoped game sessions tying a player and a game together, and the sensitive operations — anything that moves tokens — are settled server-to-server rather than trusted from the client. That split is deliberate: the SDK and PostMessage layer make the integration pleasant for a game developer, while the real authority over balances and purchases stays on the platform's own servers where it can be made correct and auditable.
To make all of this adoptable by outside teams, the integration is documented as a first-class product — an SDK reference and integration guides, with an OpenAPI-described API behind it — so a studio can wire up a game against a clear contract instead of reverse-engineering ours.
The payment and token economy
Underneath the wallet is real money. Players buy tokens; tokens are then spent across games and the shop. I built the payment integration as a provider abstraction so the platform isn't married to a single processor: a card payment provider handles hosted, iframe-friendly checkout with one-click rebilling for returning players, and a crypto path (CoinPayments) covers token top-ups in cryptocurrency.
Money is the part of any platform that has to be right every single time, so the flows are built around that. Each checkout is tied to a merchant transaction and order, providers confirm payments back to us through signed postback callbacks rather than trusting the browser redirect, and crediting a wallet is idempotent so a retried or duplicated callback can never double-credit a balance. The same discipline runs through orders, the shop, subscriptions and referrals — the whole revenue surface is designed to settle correctly and stay auditable.
A native app that's also an app store
Alongside the web platform I built the mobile side. The main mobile client is a Capacitor app that wraps the platform in a native shell — native authentication, the mobile wallet, push notifications — so players get an app-store-ready experience on Android and iOS without forking the product.
The more unusual piece is a companion mobile application that works as an app store in its own right: it can download and install native APKs directly, so games and platform builds can be distributed to players outside the constraints of the official stores. For a gaming catalog where store policies are an awkward fit, being able to deliver native installs ourselves was a meaningful piece of the distribution strategy.
Architecture
Everything lives in a single TypeScript monorepo built with Turborepo and pnpm, with shared packages — UI components, API contracts, database types — used across every app so the clients and the backend stay in lockstep. The backend is a NestJS service organised along domain lines (auth, games, payments, shop, orders, subscriptions, referrals, achievements and more), backed by Supabase Postgres through TypeORM, with the usual supporting cast wired in: email, push via Firebase, analytics, and operational tooling.
The web app is a Next.js / React application on Supabase, fully internationalised; the documentation site runs on Fumadocs and publishes the API and SDK references that game teams integrate against. Keeping the web client, the mobile clients, the API, the SDK and the docs in one repo with one type system is what let a small team integrate many games and ship coordinated changes without the whole thing drifting apart.
Leading the launch
The quieter half of the job was getting the platform out the door. As lead engineer I owned the architecture and the integration roadmap, but launching a catalog of games means depending on a lot of moving parts you don't control — each game has to be integrated, tested against the SDK, and signed off. A good deal of that coordination ran through game teams in China: aligning on the integration contract, working across the timezone and language gap, and getting each studio's game talking correctly to our session, wallet and purchase flows before it could go live.
Pulling that together — the SDK and server integration on our side, the studios' games on theirs, the payment providers in the middle, and the web and mobile clients on top — into a single launch is the work I'm proudest of here. The result is a platform where a player sees one catalog, one balance and one smooth experience, and never has to know how many separate systems had to agree for that to be true.