Native Mobile Companion for a Gaming Marketplace

Native mobile engineering for a marketplace whose app-store presence had to coexist with a regulated web platform — without architectural drift.

Europe

50,000+

Installs in the first two months (on track for 200K EOY)

30%

Reduction in infrastructure overhead (architectural simplification)

99.9%

Push notification delivery success rate

60+ FPS

UI responsiveness across iOS and Android (native, declarative frameworks)

Client name withheld under NDA. Metrics verified through joint post-launch review.

Smartphone screen displaying a game interface for the current case 'Electric Dreams' with a progress bar, buttons labeled 'Get This Case' and 'Discover More Cases', and images of virtual weapon skins.

#Mobile

#iOS

#Android

#Native

#Kotlin

#Swift

#Anti-Fraud

#Architecture

Summary

A competitive gaming marketplace operating in Europe needed a mobile companion to its web platform. The brief looked routine on the surface — iOS and Android apps for an existing product — but three constraints made the engagement architecturally interesting. The mobile experience had to comply with App Store and Google Play policies for its product category, which preclude direct transactional functionality in the marketplace vertical. The platform had reached a point where an existing message-broker choice (Kafka) was adding operational overhead the MVP didn't need. And the reward-driven mechanics that engage users on the mobile side made the platform a target for automated abuse — which couldn't be solved by a generic anti-fraud SaaS without compromising legitimate users. We built the mobile platform on native frameworks (Swift, Kotlin) with a re-architected backend that traded Kafka for BullMQ + Redis, paired with a multi-layer anti-abuse system designed for the actual threat model. The platform launched in February 2026 and crossed 50K installs in its first eight weeks.

Request

The objective was a mobile ecosystem (iOS + Android) that would:

Comply fully with App Store and Google Play platform policies for the digital marketplace category

Provide a high-engagement mobile experience without direct monetary transactions on-device

Collect granular signal on user preferences to inform personalisation on the regulated web platform

Integrate identity verification into the mobile reward flow, reducing friction in the web-side onboarding

Behind these product requirements sat the engineering brief that defined the engagement: a stack that could ship to MVP fast, run cheaply at MVP volume, and scale cleanly to the targeted Year-1 install base without re-architecting.

Challenge

Three engineering constraints shaped the architecture.

Platform policy compliance.

Both App Store and Google Play apply specific rules to apps operating in the digital marketplace category — direct in-app purchases and deposits are not permitted. The compliant pattern is a companion-app architecture: the mobile experience focuses on engagement, preference collection, and account management, while transactional flows live on the web platform. Engineering this cleanly — without the friction users expect from "the app that can't do anything" — required careful interaction design and a clear contract between the mobile and web layers.

Architectural overspecification.

The platform had inherited a Kafka-based message broker from earlier architectural plans. For the MVP's session-based logic and projected MVP volume, Kafka was overspecified — adding operational overhead, latency, and infrastructure cost without commensurate value. The right architectural move was simplification, not addition. We replaced Kafka with BullMQ on Redis, retaining the queueing semantics the workload actually needed at a fraction of the operational footprint.

Anti-abuse threat model.

Any reward-driven mobile platform is a target for automated botting and multi-accounting. Off-the-shelf fraud-detection SaaS handles this poorly in this category: it either over-blocks legitimate users (catastrophic for product growth) or under-blocks sophisticated abuse (catastrophic for unit economics). The defence had to be designed against the specific threat model of this product, layered, and tunable.

Feature scope

The engagement was structured around three workstreams, each addressing one of the constraints above.

1. Mobile companion architecture

The mobile experience focuses on user engagement, preference signal collection, and account-tier progression — none of which require on-device transactions. Mobile rewards and progression are synchronised in real time with the user's web-platform account, so identity verification or transactional flows on the web side reflect immediately in the mobile state.

2. Architectural simplification (Kafka → BullMQ)

The platform inherited Kafka from earlier architectural plans, but the MVP's actual workload didn't justify it. Kafka shines when you have multiple consumer groups, long retention requirements, or stream-processing workloads. The mobile MVP had none of these — it had session-based task synchronisation, reward distribution, and notification fan-out. BullMQ on Redis covers that workload at a fraction of the operational and infrastructure cost. Reducing the broker stack reduced infrastructure overhead by an estimated 30% while preserving every behavioural property the system actually used.

This is the kind of decision that's easy to miss in a typical "scale-up" architecture review, where the default is to add infrastructure rather than remove it. The right call was the unfashionable one.

3. Multi-layer anti-abuse architecture

The final epic addressed the transition of users from the mobile engagement environment back to the revenue-generating web platform. This required a high-reliability notification system and a gamified approach to account linking. Key features included:

Anti-abuse for a reward-driven platform requires three layers, not one:

Behavioural signature monitoring — pattern recognition on user actions over time, identifying interaction profiles inconsistent with human use

Device attestation — hardware-level signals (via Play Integrity API and DeviceCheck) that distinguish genuine devices from emulators and modified runtimes

Proof-of-activity gates — friction surfaces that cost very little for a legitimate user but compound expensively for an automation script

Each layer is independently tunable, so the team can respond to evolving abuse patterns without redeploying the architecture.

Tech stack

Mobile:

Native iOS (Swift, SwiftUI + UIKit interop), Native Android (Kotlin, Jetpack Compose). Declarative frameworks accelerate development without sacrificing the 60+ FPS responsiveness this product class requires.

Backend:

Node.js with Nest.js, BullMQ on Redis for task queueing and orchestration

Database:

PostgreSQL

Infrastructure:

GitLab + GitOps, AWS Secrets Manager, Bitrise for iOS and Android build automation

CRM and analytics:

Amplitude (behavioural analytics), OneSignal and CustomerIO (push notification delivery)

QA:

Manual QA on isolated staging and production smokes, BrowserStack and physical device testing, Postman and Swagger for API tests, Grafana for logs and monitoring

Why native, and why declarative

For a project class that depends on UI responsiveness and reliable background-task behaviour, the cross-platform / native trade-off is usually decided by the upper bound of what the UI has to do. Cross-platform frameworks (Flutter, React Native) handle standard form-based and content-driven apps well — but hit a performance ceiling on high-fidelity animations, real-time UI updates, and 120Hz refresh rates. PWAs are cost-effective but lack the deep hardware integration and reliable background-task delivery a companion app of this class needs.

For this engagement, the requirement of 60+ FPS responsiveness across interactive surfaces — plus the need for reliable push delivery, secure local state, and device-attestation signals — made native the right choice. SwiftUI on iOS and Jetpack Compose on Android let us hit that performance bar while keeping development velocity close to what a cross-platform team would expect.

Multiplier Mini-Games:

Crash, Mines, and Upgrade modules where users can multiply their points

Two smartphones showing game screens; left displays an explosion with text 'CRASH' and message about lost points, right shows a Mines game board with revealed mine and several multipliers.

Key Features

Boost games: UPgrade

To maintain Daily Active Usage (DAU) without direct gambling, we engineered a suite of "Boost" games: Crash, Mines, and Upgrade.

Users earn soft currency through daily check-ins and use these games to multiply their points. This replicates the thrill of the primary platform in a non-monetary environment, building the dopamine loops necessary for high retention.

Two smartphones displaying a game upgrade screen with circular multipliers of 25, 50, and 100, instructions at the bottom guide picking a higher multiplier with lower odds or hitting green to get a multiplier.

The Preference Engine (Skin Tinder)

To drive the 10% LTV goal, the app features a high-frequency swipe interface where users choose between digital assets. This is not just a game; it is a data collection tool that maps user intent. This data is fed directly into Amplitude, allowing the primary platform to offer hyper-personalized "deals" that users are statistically more likely to accept.

Tiered Fortune Wheels

A dual-tier reward system where the Standard Wheel provides consistent engagement, while the Premium Wheel—containing high-value bonuses—is unlocked only after the user synchronizes and verifies their primary account.

Two mobile screens showing a risky spin game with a wheel featuring multipliers and bomb icons, displaying a score of 5,000 points with a 10x multiplier.

Timeline

The project followed a strategic development cycle from May 2025 to the February 2026 launch

Discovery

May 2025

Stakeholder interviews, requirements scoping, definition of the mobile / web contract.

Architecture and design

June – July 2025

Architectural pivot from Kafka to Redis + BullMQ; UI/UX wireframes for the mobile surfaces.

Core Development

August – December 2025

Node.js backend, native iOS and Android frontends, anti-abuse layer, Amplitude and CRM integrations.

January 2026

Functional testing, security audits, cross-device verification.

Launch

February 2026

Global rollout on App Store and Google Play.

Results

Summary

The platform-policy strategy held — both store reviews passed without escalation, and the companion-app architecture proved durable to subsequent product iteration.

Results in Numbers (Targets)

50,000+

installs in the first eight weeks; on track for the 200K Year-1 target

~30%

reduction in infrastructure overhead through the Kafka → BullMQ + Redis simplification, with no loss of behavioural guarantees

99.9%

push notification delivery success rate through a tiered OneSignal + CustomerIO strategy

60+

FPS UI responsiveness sustained across iOS and Android

Multi-layer

anti-abuse defence running in production, tunable per layer without code redeployment

Next steps

Deep-session diagnostics. Integrating LogRocket for high-fidelity replay of friction points and crash reproduction.

Automated abuse forensics. Scaling the behavioural-signature layer to handle more sophisticated automation patterns as they emerge.

Iterative product expansion based on Year-1 usage data.

F. A. Q.

What is included in the development scope?

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

How do you estimate timelines?

Timelines are based on the approved scope, project complexity, dependencies, and the client’s feedback speed. Estimates assume timely input and approvals from the client side.Delays in feedback, changing priorities, or new requirements may directly impact delivery dates and are handled transparently.

How many revisions are included?

Who is responsible for communication and approvals?

What happens after delivery?

F. A. Q.

Why native rather than cross-platform for this app?

The decision rested on the performance ceiling. Cross-platform frameworks (Flutter, React Native) are a reasonable choice for many mobile products, and we'd recommend them for content-driven or form-based apps where development velocity matters more than rendering performance. For this engagement, the UI had to sustain 60+ FPS across interactive surfaces, integrate hardware-level device attestation, and deliver reliable background tasks — three requirements that lean toward native. SwiftUI and Jetpack Compose, both declarative, let us reach the performance bar without sacrificing the development velocity that usually justifies going cross-platform in the first place.

Why did you replace Kafka instead of optimising around it?

Because Kafka was solving a problem the MVP didn't have. Kafka's strengths — multiple consumer groups, long-retention durable logs, stream-processing workloads — weren't being used. The actual workload was session-based task queueing and notification fan-out, which BullMQ on Redis handles cleanly at a much lower operational cost. The right architectural call was simplification, not optimisation. Adding infrastructure feels like progress in a review; removing it is often the better engineering decision.

How do you protect a reward-driven mobile app from automated abuse?

A multi-layered defence: behavioural signature monitoring (pattern recognition over time), device-attestation signals (via Play Integrity API and DeviceCheck) that distinguish real devices from emulators or modified runtimes, and proof-of-activity gates that impose negligible friction on legitimate users but compound expensively against automation scripts. Each layer is independently tunable, so the team can respond to evolving abuse patterns without redeploying the architecture. Generic anti-fraud SaaS rarely fits this category well — the tuning has to be specific to the product's actual threat model.

How do you ship a mobile app for a digital marketplace category that has strict store policies?

The compliant pattern is a companion-app architecture: the mobile experience focuses on engagement, preferences, and account management, while transactional flows stay on the web platform that is licensed for them. Done well, this isn't a limitation on the mobile experience — it's a clearer split of responsibilities between the two surfaces. The mobile and web sides need a well-designed contract for state synchronisation, identity, and notifications. That contract is most of the architectural work.

How do you build the right mobile tech stack for a high-load consumer app?

Focus on three things: concurrency model (Node.js + Redis + BullMQ handles thousands of simultaneous tasks at low latency), CI/CD discipline (Bitrise or similar for automated cross-device testing — frequent updates can't introduce regressions), and observability tuned to mobile-specific failure modes (push delivery rates, crash-free sessions, regional latency). The stack choices follow from the workload, not from fashion.

See more cases

Healthcare Compliance Platform

Re-architecting a clinical SaaS for HIPAA and GDPR compliance while expanding product capabilities.

#HealthTech

#Compliance

#HIPAA

#Kubernetes

#GDPR

#Cloud-Native

#Microservices

#AWS

#PostgreSQL

DevSecOps

Skin.Club CS2 skins guide webpage displaying various weapon skins and knife designs including Doppler, Ultraviolet, Marble Fade, Freehand, and Damascus Steel.

This is some text inside of a div block.

Wiki

A content-first knowledge platform that turned the data fragmentation of a $5B+ market into a global traffic engine.

#AWS

#Esports

#Gaming

#Headless-CMS

#Content-Platform

#Multilingual

#SEO

#Real-Time-Data

This is some text inside of a div block.

Speed Logistics Marine

Scaling a global fleet without scaling the administrative load that usually grows with it.

#Maritime

#ERP

#SaaS

#Mobile

#.NET

#AWS

#PostgreSQL

#Logistics

This is some text inside of a div block.

Building a native mobile companion in a regulated category?

If you're shipping a mobile companion to a regulated web platform, navigating App Store / Google Play policies for your category, and need an architecture that holds up to both — that's the engagement we run.

Start a Capability Blueprint Workshop