← Back

On designing tools for mobile game
economy management

B2B Platform Adapted DS

Context

Expanding the platform

I worked on expanding our internal B2B platform with a game economy management module. The goal was to let studios configure in-game economies, run experiments, and adjust monetization without shipping code for each change. The capabilities were adopted by titles such as Mob Control, Block Jam, and Monster Survivor, contributing to stronger revenue performance.

Product needs were changing

Our portfolio was shifting from primarily hypercasual titles toward more complex hybrid casual games. That changed the design problem: teams needed tooling for sustained engagement, longer-term economy tuning, and more nuanced monetization models.

The system had to support more variation

New studios were joining with different content structures, monetization strategies, and operating habits. The challenge was not only adding features, but defining a system flexible enough to support variation without becoming fragile or overwhelming.

Illustration showing evolution from hypercasual to hybrid casual games

Global process

We started with a broad benchmark across both game systems and adjacent SaaS tools to understand expected capabilities, interaction patterns, and where a more opinionated platform could add value.

From there, we moved into feature framing using affinity mapping and a method I developed called Cartesian mapping, where desired capabilities were plotted against benchmarked tools. That made tradeoffs easier to discuss, helped surface differentiation, and gave us a clearer sequence for implementation.

We then tested the model through both Figma prototypes and production-ready builds. Validating across design and implementation helped expose where ideas that looked sound in prototype broke down under real operational constraints.

Benchmark examples Game economy pack examples SaaS tools benchmarking Complexity mapping User flow diagram

After the fact

Positive

  • Commercial impact: around 5% revenue uplift was tied to new offer types and items created through the tool, effectively paying back the project.
  • System quality: the work also created space to refactor components and tighten interaction patterns, making complex tasks clearer for studio teams.
  • Operating model: closer collaboration with stakeholders led to a more grounded backlog and better decisions about what the platform should support next.

Negative

  • Architecture constraints: the service sat between the game back office and the client, which limited direct control over some behaviors and restricted available data.
  • Capacity planning: early feature sizing reflected how many entities teams had at launch, not the scale they would create over time. That required post-launch redesign and engineering work.
  • Adoption timing: many games do not need a mature economy tool early on, so finding the right adoption moment, and designing for earlier-stage teams, remains a challenge.

Next time: support structured CSV ingestion from day one, design version one for higher entity volume, and plan adoption paths that fit teams before they reach full economy complexity.