Mobile games are one of the most competitive software markets on earth, and also one of the most lucrative. The hard truth most studios learn too late is that the game itself is only half the product. The other half is the live-ops backend: the player accounts, the in-game economy, the store, the events, the receipts from Apple and Google. That backend is where retention and revenue actually live, and it is exactly the part most indie and mid-size teams end up renting from a closed Backend-as-a-Service they can never fully control. This is a guide to building that half yourself, on infrastructure you own, using VBWD.

The opportunity: a game you own end to end

Picture a mid-core mobile game — a match-three RPG, an idle tycoon, a competitive card battler — shipping on both the App Store and Google Play. Players sign in, earn and spend a soft currency, buy premium currency with real money, subscribe to a battle pass, and come back for weekly events. Every one of those touchpoints is a backend call. If you build them on someone else's platform, your player list, your economy ledger, and your revenue data are their asset, priced per monthly active user and subject to their pricing changes. Build them on VBWD and they are yours: your database, your rules, your direct relationship with the player.

What VBWD gives you out of the box

VBWD is a self-hosted, source-available full-stack SDK: one Python backend core, a Vue/TypeScript web front end, and — critically for games — a native iOS SDK and a native Android SDK, all talking to the same backend. The core is agnostic, and capabilities are plugins that toggle on and off without a restart. For a game, the plugins you would actually wire up are:

• Player accounts + RBAC + multi-tenant — real authenticated identities, roles (player, moderator, admin, VIP), and clean separation if you run more than one title.
• token_payment — a token/credit economy with metered billing. This is your in-game currency: gold, gems, energy. A proper ledger instead of a number you hope nobody edits.
• subscription — tarif plans, subscriptions, add-ons and checkout for battle passes, premium memberships and ad-free tiers.
• shop — products, orders, stock and shipping, for everything from starter packs to real merch.
• Payment providers — Stripe, PayPal, PromptPay, Mercado Pago, Conekta, Toss, YooKassa, TrueMoney, plus provider-agnostic and non-custodial crypto/stablecoin settlement for regions where card coverage is thin.
• cms / cms_ai — live content and event copy you can push without shipping a new app build.
• chat + LLM modules (meinchat + LLM connection) — optional dynamic content, in-game NPC dialogue, or a support channel; and mcp if you want the backend to be agent-callable.
• bot_telegram, discount, referral, withdraw — a community bot, promo codes, invite loops, and payouts for creator or tournament programs.
• An event-driven core with native signed webhooks, so purchase events, level-ups and currency spends can fan out to your analytics and anti-fraud tooling.

This is not theory. Real vertical products already run on VBWD — a tarot app, a pharmacy shop, and bdv, a dice-market game — which is the proof the plugin system flexes to genuine game logic, not just storefronts.

The honest boundary: VBWD is not a game engine

Be clear-eyed about this. VBWD is not a rendering, physics, or gameplay engine. It does not draw a frame, simulate a collision, run a shader, or animate a sprite. It has no scene graph and no game loop. For the actual game you bring your own engine — Unity, Unreal, or Godot — and that is where all your rendering, input, physics and gameplay code lives.

What VBWD is, is the self-hosted backend and live-ops layer your game talks to through the native iOS and Android SDKs. The division of labour is simple: the engine owns the fun; VBWD owns the accounts, the economy, the purchases, the content and the data. Anyone who tells you a single tool does both the frame rendering and the payment ledger is overselling. Keeping the two concerns separate is the correct architecture anyway.

A rough build outline

The core workflow, concretely:

• 1. Stand up the backend. Clone the public SDK, bring up the Python core, and enable the plugins you need — accounts/RBAC, token_payment, subscription, shop, cms. No restart to toggle a capability.
• 2. Build the game in your engine. Unity, Unreal or Godot handles all gameplay. Treat the backend as an external service the game authenticates against.
• 3. Wire the native SDKs. Drop the VBWD iOS SDK into your Xcode/Unity-iOS build and the Android SDK into your Gradle/Unity-Android build. Authenticate the player, then read and write their token balance, subscription status and inventory.
• 4. Model the economy in token_payment. Define your currencies and let the ledger be the single source of truth for every earn and spend. Server-authoritative balances are your first line against cheating.
• 5. Connect real money. Map Apple/Google in-app purchases and subscriptions onto VBWD's subscription and payment-provider plugins, so a verified purchase credits premium currency or unlocks a tier. Use the signed webhooks to reconcile.
• 6. Run live-ops from cms. Schedule events, rotate store offers, and push seasonal content as data — no new binary, no store review wait for a copy change.

Monetization, and why owning it wins

VBWD does not lock you into one revenue model — it hands you the building blocks for all of them at once. Sell premium currency through token_payment. Run a battle pass or VIP membership on subscription. Open a shop for cosmetic bundles and starter packs. Layer discount codes, a referral program for viral installs, and creator payouts through withdraw. Settle in cards, local rails, or non-custodial crypto depending on where your players are.

The strategic point is ownership. A rented BaaS meters you per active user and holds your player data, your economy ledger and your purchase history on its terms. When your game finally hits scale — the moment you have spent years chasing — that is exactly when the per-MAU bill hurts most and the lock-in bites hardest. Because VBWD is self-hosted and source-available, the player relationship, the economy and the numbers are yours. You can read the source, change behaviour, run it in your own cloud or on-prem, and negotiate with nobody. For a game whose whole value is a loyal, paying community, renting that community back from a platform is the one dependency you do not want.

Get started

Clone the public SDK and bring up your own backend: github.com/VBWD-platform/vbwd-sdk-public. If you would rather have a managed enterprise installation stood up for your studio, get in touch at vbwd.cc/contact.

VBWD is source-available under BSL 1.1 — free for commercial use while annual VBWD-attributable sales stay under the value of 6.7 BTC per year.

Build a business with VBWD — the series:Mobile game (this one) · Travel aggregator · Marketplace · Booking SaaS · AI assistant SaaS