Sixteen games, one backend, and an economy they can change daily

2minwin came to us with a real-money skill gaming product that lived or died on two things: whether the games felt good enough to keep playing, and whether the economics around them could be changed quickly once real players started behaving in ways nobody predicted. Most studios can build one of those. The second is where products stall.

We built sixteen games in Unity 3D, a Firebase backend behind them, and the surrounding infrastructure that turned a set of games into a business: a marketing site, WhatsApp as a live channel to players, and a payments rail through Zwitch.

Sixteen games, one shared spine

Sixteen titles is not sixteen projects. Built the naive way it becomes sixteen codebases, sixteen release cycles, and sixteen places a bug can hide. We built one shared spine instead: a common match lifecycle, a shared economy layer, a single results and settlement path, and a common analytics surface. Each game plugs into that spine and owns only what makes it different, which is the actual gameplay.

The practical effect is that adding the twelfth game costs a fraction of what the second did, and a change to how a match settles ships to all sixteen at once rather than being reimplemented sixteen times with sixteen chances to get it wrong.

Firebase and Cloud Functions as the authority

In a real-money game the client cannot be trusted. If the Unity build decides who won and how much they get, the product has a fraud problem waiting to be discovered by the first person who looks for it.

We put the authority server side. Firestore holds the state of matches, wallets, and entries. Cloud Functions own every transition that touches value: entry deduction, match resolution, payout calculation, and wallet credit. The Unity client renders and submits, but never decides. Every balance change is a server-written record with an audit trail behind it, which matters both for trust and for the day someone disputes a result.

Changing the economy without shipping a build

This is the part that mattered most to 2minwin and the part most teams get wrong.

Game economics are guesses until real players touch them. The entry fee that seemed right, the coin conversion, the rake, the winning flow, the reward curve: all of it is a hypothesis on day one. If changing any of those requires a Unity rebuild and a store review, the team gets one experiment every two weeks and stops experimenting.

We pulled all of it into remote configuration held in Firestore and read at runtime. Entry tiers, coin values, payout splits, win conditions, reward multipliers, and which games are live at all are data rather than code. The team changes a value in the admin console and it takes effect on the next match, on every device, without a release.

That turned experimentation from a fortnightly event into a daily one. Coin-based play versus direct entry, different winning flows, different reward curves, promotional pricing on specific games: all of it became something the business could try, measure, and reverse the same day.

A marketing site built at conversation speed

2minwin needed a public site and needed it before the games were finished. We built it with an AI-assisted workflow, describing sections and iterating on the output rather than hand-writing every component, which compressed what is normally a multi-week front-end build into a far shorter cycle.

The important caveat is that the speed came from the generation step, not from skipping the rest. The output still went through the same review for performance, accessibility, responsive behaviour, and SEO structure that any site of ours does. Generated code that nobody reviews is technical debt that arrives faster, and that is not what we handed over.

WhatsApp as the channel players actually read

Push notifications on a gaming app are close to worthless. They are disabled, ignored, or buried. WhatsApp is opened.

We integrated WhatsApp so the product could reach players where they already are: match results, wallet events, withdrawal confirmations, and re-engagement for players who stopped mid-session. The integration runs off the same Cloud Functions that own the state transitions, so a message is triggered by the event itself rather than by a separate system that can drift out of sync with what actually happened.

Money in and money out with Zwitch

Deposits are the easy half. Payouts are where real-money products break, because a player who cannot withdraw tells everyone.

We integrated Zwitch to handle the movement of funds in both directions, and built the ledger discipline around it: every credit and debit written as an immutable record, wallet balances derived from that ledger rather than stored as a mutable number, and reconciliation between what the platform believes it owes and what the payment provider has actually moved. Payout state is explicit at every step, so a stuck withdrawal is visible as a stuck withdrawal rather than as silence.

The rest of it

Alongside the headline pieces sat the work that decides whether a product survives contact with real users: an admin console for running the games and the economy without engineering involvement, KYC flow, referral mechanics, leaderboards, analytics instrumentation from the first build rather than bolted on later, and the operational tooling to investigate a specific player's history when support needs to.

Where it stands

2minwin runs sixteen games on a shared backend, changes its economics without shipping a build, reaches players on a channel they read, and moves money in both directions on a reconciled ledger. The client owns the repository, the Firebase project, the payment credentials, and the data.

The build we are proudest of is not any single game. It is that the team can now run an experiment on Tuesday and know the answer by Wednesday.