Skip to content
Built for a client

Pasha 9

A Bangla-first gaming platform: a player site, an operator control centre of 84 screens, a third-party game catalogue settled against our own wallet, and an Android app.

Every player-facing surface has an operator screen behind it, so the client runs the business themselves rather than filing a ticket for a copy change.

Visit Pasha 9 (opens in a new tab)
Explore the Platform
The Pasha 9 homepage rendering in Bangla with its game category rails
The story

From a frontend milestone to a platform in production

The engagement started narrow: one priced milestone for the frontend, so the client could see the product before committing to the rest. It did not stay there. The platform now runs the whole business, and the work was delivered as a sequence of milestones the client approved one at a time.

Two decisions shaped everything after them. The first was that Bangla is the baseline and English is the fallback, resolved on the server before the first byte is sent, so a player in Bangladesh never sees a flash of English. The second was that the operator edits the platform, not the developer: homepage sections, game rails, promotions, payment instructions and the reward catalogue are all database rows with an admin screen behind them.

The platform is live. Some parts are deliberately switched off in production, and the honest version of that is set out below rather than left for a reader to assume.

  1. 01

    Bangla-first player site:Milestone 1: the shell

    The player site, accounts, and the content management behind the homepage.

    Open
  2. 02

    Milestone 2: money and security

    The wallet ledger, the approval pipeline, roles and permissions, delivered in twelve sub-milestones.

  3. 03

    Aggregated game catalogue:Milestone 3: the catalogue

    The aggregator integration and the hardening that had to come with it.

    Open
  4. 04

    Bangla-first player site:Database-driven surfaces

    The public pages become operator-editable rows rather than code.

    Open
  5. 05

    Android shell and push

    A deliberately thin native wrapper over the same site, with a notification layer behind it.

  6. 06

    Operations hardening

    Reconciliation, audit trails and the tooling the desk needs to answer a player.

What this shows

What this demonstrates

The engineering capabilities this engagement demonstrates, beyond the screens.

  • Building a product where the money trail has to be provable, not merely present
  • Server-rendered internationalisation with no flash of the wrong language
  • Designing an operator control centre as a first-class product, not an afterthought admin
  • Integrating a third-party catalogue across an untrusted callback boundary
  • Delivering in priced milestones a client approves one at a time
  • Shipping a native Android shell and a push layer over an existing web platform
Pasha 9 ecosystem

Five player surfaces, and an operator screen behind each one.

  1. The player surface

    Bangla-first player site

    Bangla resolved on the server, before the first byte renders.

    The market is Bangladesh. Treating English as the fallback rather than the baseline is the difference between a product built for its users and one translated at them.

    Core engineering challenge

    Server-rendered internationalisation with no flash of the wrong language, and a homepage whose layout is data rather than markup while still rendering an honest empty state instead of invented placeholder content.

    Open the site(opens in a new tab)

  2. The catalogue

    Aggregated game catalogue

    One aggregator, 1,232 titles across 10 brands, settled against our own wallet.

    The operator wanted a catalogue without commissioning an integration per vendor, and the platform needed a boundary it could defend when an outside system posts a message that moves real money.

    Core engineering challenge

    An unauthenticated endpoint that changes balances. Every failure mode had to be enumerated: replay, a spoofed source, an unmapped account, a partial write.

    Open the catalogue(opens in a new tab)

  3. Sports

    Sportsbook surface

    Fixtures the operator curates from the admin, not from a deploy.

    A sports surface the operator controls day to day, sitting alongside the casino catalogue rather than in a separate system behind a separate login.

    Core engineering challenge

    Presenting a fast-moving, operator-curated surface inside the same Bangla-first rendering and the same session and wallet boundary as everything else.

    Open the sportsbook(opens in a new tab)

  4. Loyalty

    VIP tiers and reward catalogue

    Tiers a player applies to, and a reward catalogue with a claim behind every item.

    Retention features the operator runs as a business process, with a reviewable trail of who applied for what and when, rather than a static marketing page.

    Core engineering challenge

    Loyalty mechanics touch the wallet, so every grant and clawback has to travel through the same ledger as everything else instead of quietly adjusting a balance.

    Open the VIP club(opens in a new tab)

  5. Referrals

    Referral centre

    A three-level chain, with the balance and the claims modelled separately.

    Word of mouth is how this market grows, so the referral chain had to be a real structure the operator can audit, not a number on a page.

    Core engineering challenge

    Modelling a multi-level chain on the account itself while keeping every resulting balance movement inside the same audited wallet ledger as every other kind of money.

    Open the referral centre(opens in a new tab)
Module by module

What we built

  1. 01The player surface

    Bangla-first player site

    The public site: homepage, catalogue, wallet, promotions, support and the legal pages. Language is resolved in the root layout from a cookie, then the Accept-Language header, then a hard default of Bangla, so the html lang attribute and the first dictionary lookup always agree. Paired Bangla and English dictionaries are kept exactly the same length, so a missing translation shows up while building rather than in front of a player.

    • Language resolved server-side, with cookie, header and default precedence
    • Paired Bangla and English dictionaries kept in lockstep
    • Choice persisted to both a cookie and local storage, because a cookie does not always ride the first navigation inside an app webview
    • Homepage sections, featured games, rails, videos and shortcuts are operator-editable rows
    • An empty section renders as empty, never as mock content
    Open the site(opens in a new tab)
    The Pasha 9 homepage rendering in Bangla with its game category rails
  2. 02The catalogue

    Aggregated game catalogue

    A pluggable provider interface with one aggregator implemented behind it. Launching a game encrypts a payload server-side and returns only a launch URL to the browser. The inbound settlement callback is treated as hostile: the provider must be active, the shared secret is compared in constant time, the source address is checked against a whitelist, and the balance change, the transaction row and the provider ledger row commit inside one database transaction with an idempotency check.

    • One adapter interface, so a second aggregator is an implementation rather than a rewrite
    • Constant-time secret comparison and source address whitelisting on the settlement callback
    • Idempotency keyed so the same round cannot settle twice
    • Balance, transaction and provider ledger written in a single transaction
    • Every callback logged with secrets masked, whether it was valid or not
    Open the catalogue(opens in a new tab)
    The Pasha 9 game catalogue showing category rails and provider titles
  3. 03Sports

    Sportsbook surface

    The sports surface, with its own admin counterpart for events. As with the rest of the player site, what appears here is operator-managed data rather than hardcoded content, so the desk changes what is featured without an engineer.

    • Operator-managed events, with an admin screen behind the player surface
    • Shares one account, one wallet and one session with the rest of the platform
    • Rendered through the same server-side language resolution as every other page
    Open the sportsbook(opens in a new tab)
    The Pasha 9 sportsbook surface
  4. 04Loyalty

    VIP tiers and reward catalogue

    A VIP club with tiers and applications, and a separate reward catalogue where each item can be claimed. Both are modelled properly in the database, with tiers, applications, reward items and reward claims as first-class records, and both have operator screens for reviewing what players have asked for.

    • VIP tiers with player applications for the desk to review
    • A reward catalogue with individually claimable items
    • Claims recorded as records, so a decision has a history
    • Operator screens for both, separate from the player-facing pages
    Open the VIP club(opens in a new tab)
    The Pasha 9 VIP club page
  5. 05Referrals

    Referral centre

    Every account carries a unique referral code and a self-referencing link to whoever introduced it, so the chain is a property of the data rather than something a report reconstructs. Referral balance and referral claims are separate records, and the desk reviews claims on its own admin screen.

    • A unique referral code per account and a self-relation recording who introduced whom
    • Referral balance and referral claims held as separate records
    • An operator screen for reviewing claims
    • Any resulting balance movement goes through the wallet ledger like everything else
    Open the referral centre(opens in a new tab)
    The Pasha 9 referral centre
Under the hood

Engineering depth

Making an unrecorded balance change impossible

Balance updates used to be spread across roughly twenty-two call sites, each incrementing on its own. Most also wrote a history row, but nothing enforced it and nothing recorded the balance before and after, so a missing entry was undetectable and a disputed balance had no answer. There is now one function allowed to move a balance. It reads, moves, and writes a ledger row carrying the before and after inside a single transaction, so a movement without a record cannot commit.

Two checks that fail for different reasons

Reconciliation asks the question the ledger exists to answer, twice over. Chain continuity requires each entry's closing balance to equal the next entry's opening balance. The total-sum check requires every recorded amount to add up to the balance on the account. A single corrupt row breaks the first; a missing row breaks the second. Both run on demand from the admin, and a platform-wide sweep finds accounts whose records do not account for their balance.

Authorisation before any bytes are sent

The operator control centre is 84 screens across super admin, admin and limited staff roles with per-section permissions. Those are enforced at the edge, before a page renders, rather than by hiding links in the interface.

An audit trail that reads both ways

Support work needs two questions answered quickly: everything staff have done to one player, and everything one staff member has done across players. Both are searchable, with a per-account wallet audit screen and CSV export, so a complaint is settled in seconds rather than a day of manual investigation.

A deliberately thin native shell

The Android app wraps the same site rather than reimplementing it, so the product does not fork into two codebases that drift apart. The substantial part sits behind it: one notification layer fanning out across several delivery channels, including native and web push.

Supported for customers, not our build stack

The catalogue surfaces titles from a third-party aggregator covering ten game brands. Those brands are content the platform serves to its players through one integration, not ten separate integrations we built. Deposits and withdrawals run as an operator-reviewed pipeline with proof upload rather than an automated gateway.

Built for a client

A full platform build for a Bangladeshi gaming operator, delivered milestone by milestone and now running in production on its own domain.

Every player-facing surface has an operator screen behind it, so the client runs the business themselves rather than filing a ticket for a copy change.

Need a platform your team can actually run?

The valuable part is rarely the front page. It is the control centre behind it, and the trail that proves what happened.

Discuss Your Project
See More Work

Prefer to talk? WhatsApp or Telegram.