Krenno
All projectsCase study
Mobile AppGaming2025iOSAndroidWeb

Jack Black

A casino-grade blackjack table that still feels like a modern mobile product.

Live multiplayer blackjack with timed prize pools and a server-authoritative table.

Client

Krenno Labs

Engagement

first party

Krenno roleProduct strategyGame designMobile engineeringBackend and cloud architecture+3 more
Positioning

Why this product exists

Jack Black turns blackjack into a live competitive product: authentic hit, stand, double, and split play; wallet-backed pool entry; real-time table state; and a ranked contest layer that rewards consistent play across a timed event. Krenno designed the product as a complete system — identity, economy, rules engine, live UI, and operator pool controls — so a gaming brand can launch a credible table game without stitching those pieces together later.

Jack Black shows that Krenno can take a familiar game and turn it into a full commercial product: authenticated users, a wallet, timed contests, a server-side rules engine, and a polished mobile table that stays in sync with the cloud. It is evidence we can design both the player experience and the systems that make that experience trustworthy. For a client, that means we can deliver a launch-ready game product, not a screen that still needs a backend.

Built for

  • Competitive mobile card players who want tournaments, not only practice hands
  • Social-casino and skill-contest operators looking for a branded blackjack title
  • Consumer gaming brands that need a cross-platform table game with a real backend
  • Product teams that want proof Krenno can ship real-time, economy-backed games
The story

Challenge, approach, solution

01

The Challenge

Most mobile blackjack apps either play entirely on the device, which players do not trust once money or ranking is involved, or they feel like a casino floor squeezed onto a phone. The opportunity was to build a product that feels like sitting down at a live table while still behaving like a modern consumer app: fast onboarding, clear stakes, fair resolution, and a reason to come back after a single hand. That required a contest model, a wallet, and a rules engine that lives off the device — plus a table UI that makes those systems feel immediate rather than administrative.

02

Our Approach

We treated Jack Black as a product system, not a single gameplay screen. Identity, pool discovery, table play, profile, and settings each have their own surface, but they share one information architecture and one cloud backend. Game logic — shuffling, dealing, split hands, ace valuation, dealer draw-to-17, and token settlement — runs in Cloud Functions so the client is a presentation and input layer. Firestore holds users, pools, subscriptions, and hand history, and the table listens to the player's pool document so every card and chip update arrives as live state. The visual language is casino-forward: deep purple felt, gold borders, Montserrat type, chip stacks, and cinematic card motion.

03

The Solution

Jack Black is a live competitive blackjack platform. A player verifies with a mobile number, enters a timed pool with a wallet stake, receives a token bank for that event, and plays as many hands as the clock and bankroll allow. Each finished hand updates tokens and the pool leaderboard. The table supports the moves players expect — hit, stand, double, and split — with dealer hole-card concealment until the hand resolves. Operators can schedule pools with entry fees, token grants, and windows. The same Flutter codebase ships the experience to iOS, Android, and web.

Experience

The Experience

The session starts with mobile verification. After OTP confirmation, the player lands on game-mode selection and opens the live pool lobby, where each contest shows prize framing, entry fee, and an end time. Opening a pool reveals how many people are playing, the player's token bank, and match statistics. Join deducts the entry from the wallet and seats the player in that contest. Play deals a new hand: chips go down first, then cards animate onto the felt. Controls enable or disable themselves according to the legal moves for that state. A hidden dealer card flips when the hand ends, and a win, loss, or push overlay closes the beat before the next deal. From the profile, the player can see wallet balance, add funds, adjust audio, change language, and sign out. The whole path is built to feel like a night at a table that happens to live in a phone.

Product

What we built into the product

Server-Authoritative Blackjack Engine

Every shuffle, deal, hit, stand, double, split, bust, and payout is resolved on the server. Soft aces, dealer draw-to-17, split-hand sequencing, and token settlement are encoded as a state machine so the table the player sees is a projection of trusted game state, not a local simulation.

Timed Contest Pools

Players enter scheduled events with a wallet stake, receive a token bank for the window, and compete until the pool closes. Each pool carries its own entry fee, token grant, subscriber count, start and end times, and leaderboard so operators can run many contests in parallel.

Live Table Presentation

The felt updates from a Firestore snapshot of the player's current pool document. Cards deal in sequence with Rive loading states, hole-card concealment, split-hand layout, running totals, and delayed result overlays so the table reads as a performance, not a form submit.

Chip Betting and Table Controls

Players assemble a wager from chip denominations, confirm the bet, then use hit, stand, double, and split. Illegal actions are disabled from server play options, so the UI never offers a move the engine will refuse.

Wallet-Backed Economy

A persistent wallet funds pool entry, and each contest isolates play inside a token bank granted at join. Wins return tokens to that bank, losses deduct the wager, and pushes restore the stake. Profile surfaces balance and an add-funds path so economy and identity stay in one place.

Competitive Leaderboards

Finished hands write a ranked snapshot of remaining tokens into the pool leaderboard inside a Firestore transaction. Insertion uses an ordered search so rank stays consistent as many players settle hands at once.

Multi-Path Identity

Phone OTP is the primary path for the Indian market, with Google, Facebook, and email available for linking or alternate sign-in. Every gameplay request carries a Firebase ID token that Cloud Functions verify before a move is accepted.

Also included

Player Profile and Career Stats

The profile presents identity, achievements, wallet, and account actions. Pool detail shows matches played, won, and lost for the current contest so players can read their own form before they sit again.

Operator Pool Controls

Authorized operators can create new pools with entry amount, token grant, and schedule. The lobby reads live pool documents, so a new event appears to players without a client release.

Cross-Platform Delivery

One Flutter codebase ships iOS, Android, and web with a shared router, theme, and game module structure. Players keep a consistent table and lobby whether they arrive from a store listing or a browser.

Cinematic Audio and Motion

Background music, polyphonic sound effects, chip art, card animation, confetti, and Rive loaders give the table a physical rhythm. Audio respects app lifecycle and player settings so music yields when the app backgrounds.

Player Preferences and Accessibility of Sound

Settings persist music, sound effects, language, and display name locally so the table returns to the player's last comfortable state. Help and account controls sit beside those preferences.

Monetization and Store Integration

The product supports Google Mobile Ads, a paid ad-free purchase, store purchase restore, and Game Center / Google Play Games hooks for achievements and platform leaderboards alongside in-product ranks.

Reliability and Crash Insight

Firebase Crashlytics and structured client logging give the team a production signal when a deal, auth, or purchase path fails, which is required for any game that holds a wallet and a live contest.

Gallery

Product surfaces

Visual placeholders mark where final screens and captures will live. Drop assets at the paths shown on each tile.

Engineering

How it's built

A player action starts on the Flutter client, which already holds a Firebase Auth session. The client posts to a Cloud Function in asia-south1 with the ID token, pool id, and the intended action — register, join, start hand, bet, or move. The function verifies the token, loads the user and the pool, confirms the pool is still live, and runs the relevant domain service. The blackjack service mutates a UserGamepoolHistory document: the shuffled shoe, dealer and player hands, split hand, play options, token bank, and settlement. That document is written under users/{uid}/subscribedPools/{poolId}. The table already listens to that path, so the next snapshot drives card animation, chip totals, and enabled controls. When a hand finishes, a transactional leaderboard update reorders the pool document by remaining tokens. Pool metadata — fees, grants, windows, subscriber counts — lives in pools/{poolId} and is what the lobby queries. The client never writes those collections directly. The Flutter app is modular by scene: login, game mode, pool lobby, pool detail, table, profile, and settings, with shared design components and a single GoRouter graph.

API-drivenserver-authoritative game enginereal-time document syncmodular scene architecturecross-platformsecure token-gated mutations

Decision

Keep the entire blackjack state machine on the server.

Any client-side deal can be patched. Once a pool has an entry fee and a public rank, the shoe has to be generated and consumed where the player cannot see or replace it.

Players and operators can trust results, and the same engine can later support more variants without teaching a new client to cheat less.

Decision

Use Firestore both as the database and as the table's live channel.

A hand is a document. Listening to that document is a simpler real-time model than a custom socket protocol for this product shape, and it keeps replayable history next to the live state.

The felt stays in sync without a second transport, and every finished hand is already stored for stats and dispute review.

Decision

Isolate contest tokens from the cash wallet.

Entry is a wallet event. Play inside the pool is a token event. Mixing them would make refunds, ranking, and responsible limits harder to reason about.

A player can have many concurrent contests with clean banks, and operators can change grant sizes without rewriting wallet math.

Stack

Jack Black is a Flutter client in front of a Firebase backend hosted in asia-south1. The client owns presentation, routing, animation, and input. Cloud Functions own identity checks, the blackjack rules engine, wallet mutation, pool membership, and leaderboard writes. Firestore is the system of record and the live channel the table subscribes to. The split is deliberate: a game with stakes cannot let the device decide the cards, and a mobile table cannot wait on a full page reload to show the next card.

FlutterDartRiverpod, Provider, and BLoCGoRouterRive and playing_cardsaudioplayersFirebase Cloud FunctionsTypeScript and Node.jsFirebase Admin SDKCloud FirestoreFirebase (asia-south1)Firebase Hosting and Cloud StorageFirebase AuthenticationServer-side ID token verificationLeast-privilege Firestore and Storage rulesFirebase CrashlyticsGoogle Sign-In and Facebook LoginGoogle Mobile Ads and in-app purchases
Process

From brief to shipped product

  1. 01Discovery

    We mapped the real job of a mobile blackjack product: get a player from phone number to a trusted first hand without making them learn casino software. That produced a small set of surfaces — verify, choose a mode, pick a live pool, join, play, review, return — and a short list of moves the engine had to support on day one.

  2. 02Design

    The visual system is built as a night-table: purple felt, gold rules, deep red pool cards, Montserrat for stakes and ranks, chip denominations, and motion that sells the deal. Screens were designed as a sequence, not a pile of widgets, so lobby, detail, and table share the same chrome language.

  3. 03Development

    Client scenes and Cloud Functions were built against the same domain models. The engine landed first so the table could be a subscriber. Auth, wallet join, live snapshots, and leaderboard transactions were wired as separate services so a change to split logic does not rewrite onboarding.

  4. 04Testing

    Rules were exercised as isolated move functions — hit, stand, double, split, ace reduction, dealer 17, bust, and push — then through the HTTPS handlers with verified tokens. The Flutter client was run across phone and web targets with Crashlytics-ready error boundaries around the table stream.

  5. 05Launch

    The product ships as a store-ready Flutter application talking to a regional Firebase project, with hosting for the web surface, locked storage, and functions for every economic write. Operator pool creation is available on the same API the lobby already reads.

Challenges

Hard problems, clear outcomes

A table that players will trust with a stake

Problem

Blackjack on a phone is easy to fake. If the device shuffles, the product cannot host contests or a wallet without looking like a toy.

Approach

We moved the shoe, the legal-move matrix, and settlement into Cloud Functions. The client sends intent; the server returns state. Firestore rules deny direct writes so the only path to a new card is a verified function call.

Outcome

The felt is a live view of server state. That is the foundation for pools, ranks, and any later real-money or operator deployment.

Split hands without breaking the state machine

Problem

Split blackjack is not two independent games. Bust, 21, and dealer resolution have to consider both rows, and the UI has to deal into the correct row at the correct time.

Approach

The engine tracks main and split decks, per-deck bust flags, and a pointer through the shoe. Hit prefers the active row; stand still draws the dealer to 17; the client mirrors both rows and both totals.

Outcome

Players get a complete table game, and the same model can accept further variants without a rewrite of the hand object.

Leaderboards under concurrent settlement

Problem

Many players finish hands in the same second. A naive read-modify-write on the pool document would drop ranks.

Approach

Leaderboard updates run in a Firestore transaction. The writer removes the player's previous row and inserts the new token total at the rank found by an ordered search over the current list.

Outcome

Pool standings stay coherent as the room fills, which is the difference between a contest and a score that flickers.

Making server state feel like cards hitting felt

Problem

A correct JSON hand is not a table. If every card appears at once, the product feels like a spreadsheet with suits.

Approach

The client diffs incoming snapshots, queues new cards, animates them with a beat, hides the dealer hole card until the winner is known, then waits before showing win, loss, or push.

Outcome

The authority of the server and the theatre of the table occupy the same moment, which is what a commercial card product has to do.

An economy that can host many contests at once

Problem

A single balance used for both entry and in-hand bets makes ranking and refunds ambiguous when a player sits in more than one pool.

Approach

Wallet pays the entry. The pool grants a private token bank stored on the subscription document. Hands spend and return those tokens. Rank is tokens left, not lifetime wallet.

Outcome

Operators can run overlapping events with different fees and grants, and a player's form in one room cannot drain another.

Proof

What this work proves

Jack Black is a finished competitive blackjack product with a real information architecture, a trusted rules engine, and a table that stays live with the cloud. It gives Krenno a reference for any client that needs a consumer game with identity, an in-product economy, real-time state, and operator-controlled events. The work shows we can design for a specific market — phone-first, India-region, contest-led — without trapping the architecture in that market.

Product design for consumer gamesCross-platform Flutter engineeringServer-authoritative game systemsReal-time multiplayer architectureAuthentication and session designWallet and in-product economyTournament and contest operationsCloud-native Firebase deliveryGame UX, motion, and audioStore monetization and platform servicesSecurity for untrusted clients

What's next

In-hand strategy coach

Add an optional advisor that reads the current totals, dealer up-card, and remaining-token pressure and suggests a play, so newer players learn the table without leaving the felt.

Private tables and friend seats

Extend the pool model with invite-only rooms and shareable codes so groups can run their own contests on the same engine operators already use for public events.

Operator command center

Give partners a web console for scheduling pools, configuring prize ladders, watching live seats, and exporting settlement reports without calling an engineer.

Have something in mind?

Tell us about your product and we'll help you ship something worth putting on this page.

→Start a project

Next project

Khatabook

The digital khata for businesses that still run on trust.

View case study