How Duo Forge Built and Balanced 70+ Interacting Power-Ups in Coinsweeper

THE GAME

Coinsweeper is a roguelite that combines classic Minesweeper with risk management, deck-building and gambling mechanics. Use numbered diamonds to deduce mine location but, instead of just clearing the board, each safe card you reveal exponentially increases your coin winnings. Decide when to cash out and secure your earnings, or push your luck for massive payouts - hit a mine and lose everything you've earned that round.

THE CHALLENGE

Coinsweeper shipped with more than 70 power-ups spanning four functional categories. Each new mechanic introduced new relationships with every existing mechanic. The challenge of maintaining consistency across that system, while continuing to ship, quickly outgrew what individual tuning could solve.

As Duo Forge puts it, "Maintaining consistency across the entire system, while still shipping a game that feels polished, is the type of scope problem that ends projects quietly."

Duo Forge consists of Kamil and Julian, two brothers based in Germany and working professionally in software development. Coinsweeper was their first ever commercial release, launched in April 2026 to tons of positive reviews. In just the first two months, players were already logging serious play time, with one tester already passing 172 hours.

Its success is in large part due to the team's ability to build a power-up system big enough to feel different every run, and robust enough that two people could maintain it. To do this, they needed to find ways to save time on iteration and debugging to invest more in design and playtesting.

SECTION 1

Designing the Framework, Not 70 Individual Features

How does a small team prevent 70+ mechanics from becoming impossible to maintain?

With infinite power-up interaction combinations, Duo Forge knew that Coinsweeper’s mechanic system was ripe for conflict and errors if they built power-ups one at a time.

To get ahead of this, they defined meta-level categories and interaction rules before they built a single mechanic. The four categories, reveal mechanics (Fortune Teller, Lucky Peak), risk/reward modifiers (High Roller, Golden Touch), economy boosters (Lucky Charm, Coin Magnet), and protective mechanics (Shield, Armor Plating), provided a framework for adding new power-ups and evaluating them against the system.

This meant that adding a new power-up could be a classification question instead of a system-wide compatibility audit. A mechanic that fit in a defined category should follow pre-set interaction rules with other categories. If it didn’t cleanly fit, it was flagged as a design signal long before it became a maintenance liability.

"We categorized everything early and set rules for how categories interact. That gave us a framework instead of just patching problems one by one."

They used Bezi to help evaluate every new power-up against existing product architecture before it was built out. Bezi's ability to look into the project, at actual data files as well as the codebase, allowed it to quickly validate and build out new features that adhered to the category structure. This drastically reduced the time it took to go from idea to implementation, allowing the team to build power-ups fast, without adding more bug fix work in the future. 


SECTION 2

Debugging Hidden System Interactions

How do you efficiently find issues that only emerge when multiple systems overlap?

Still, bugs are unavoidable. With Coinsweeper, the most difficult were hidden in power-up combinations and interaction chains: Duo Forge battled order-of-operations conflicts between mechanics that functioned correctly in isolation but behaved unexpectedly under edge-case conditions.

Finding and diagnosing these was especially challenging because it required holding the full context of multiple, interconnected systems simultaneously. That is expensive for large teams, and nearly impossible for a two-person team that wants to ship on time.

This was the case in the Crystal x Quick Reveal combination interaction. 

Crystal is a permanent Epic-tier power-up that safely reveals a 3x3 grid area on the first click, automatically defusing mines in the zone. Quick Reveal is a consumable utility that manually reveals 5 random cards and defuses any mines it hits. On paper, they do completely different things but, in practice, they share the underlying defuse logic.

This created a conflict; if a player activated Quick Reveal before using Crystal, Crystal stopped working entirely. The 3x3 safe zone simply would not trigger.

The catch was that both power-ups worked perfectly in isolation and all other interactions. It was the situational, emergent bug that can’t be reliably found in playtesting and would have been hugely disruptive for the player. They would have just spent 160,000 coins on an Epic power-up that silently failed. No feedback, no reveal, just a dead ability at the worst possible moment.

It was only discovered when Bezi found and flagged the conflict while polishing Crystal’s implementation. Because Bezi held the full context of all systems simultaneously, it recognized that both power-ups wrote to the same defuse state, and the activation order left Crystal with nothing valid to act on.

“Tracking down why two power-ups were breaking or figuring out why a specific board state was behaving strangely normally means digging through code for hours. Bezi had full context of all the systems and what the desired states were, so it could instantly identify and pinpoint the issues.”

The fix was straightforward: make Crystal’s logic independent of whatever state Quick Reveal left behind, so Crystal always evaluates the board fresh on activation rather than inheriting a broken state. Once resolved, both power-ups worked seamlessly. A player can chain Quick Reveal into Crystal without any loss of functionality.

A bug that may have enacted untold damage on the player experience and taken untold hours to resolve was found and fixed before lunch.

This was only feasible through the system-level context. Every interaction chain added to a game multiplies the number of possible conflict states. Without a tool that can hold and act on all that context simultaneously, you are not debugging systematically, you are getting lucky.

“Without Bezi, development likely would have taken 6+ months longer. That time honestly would’ve been spent on bug hunts, implementation work, and tracing the interactions between systems. The unglamorous stuff. Bezi compressed all of that, so we could spend time on actual game design decisions.”

SECTION 3 

Testing Combinations, Not Components

When dozens of mechanics can appear together, what are you actually balancing?

In a roguelite, players accumulate power-ups across a run. The unit of balance isn't an individual mechanic. It's what that mechanic does inside a live combination; synergy chains, economy loops, information advantages that compound over multiple boards, interactions that only emerge when three or four specific mechanics are active simultaneously. 

Testing each power-up in isolation tells you whether the component works. It doesn't tell you how the system feels.

“We spent a long time on balance before it felt truly polished. Bezi was honestly a game changer for this. It helped us spot which power-up interactions to test and smooth out way faster than we ever could manually. For a two-person team, having that kind of support was huge. We genuinely couldn't have iterated as fast without it.”

Duo Forge said the most significant balancing work happened at the combination level. This was especially true for the middle of a run, where uncalibrated combinations can quietly collapse player pacing. Because no one power-up is responsible, it's impossible to gauge balance without testing how each piece interacts with everything else.

The challenge of this was keeping all the possible combinations in mind while iterating on a new mechanic, without slowing down development. This is where they found Bezi to be a game changer. 

Bezi’s ability to hold deep context on the game architecture and out-of-project information meant it could quickly iterate on a mechanic so it worked with what was in the game already and where development was going. When implementation is fast and serves the broader vision, interaction design judgment becomes the constraint - as it should be.

SECTION 4

Balancing Perceived Strength, Not Just Expected Value 

Why do some power-ups feel stronger than they actually are?

Tuning power-ups based on expected value turned out to be necessary but not sufficient. The team was floored by the consistent gap between how a mechanic performed statistically and how it registered with players. Mechanics that provided players with more agency or clearer outcomes were preferred over statistically better mechanics that worked quietly in the background.

“Our biggest lesson: players aren't rational calculators. How something feels is completely disconnected from what it actually does mathematically. Perception of agency matters as much as actual agency.”

This wasn’t a soft observation; it had concrete design implications. Protective mechanics, economy boosters, and reveal mechanics don't just function differently; they communicate differently. A power-up's perceived value is partly a function of how legible its effects are when it fires. 

Duo Forge understood that these imbalances couldn’t be resolved inside a spreadsheet. They were unique to people and could only be resolved by working with people. So they recruited 10 friends to help playtest, using each feedback round to tune power-ups and interactions based on real player psychology.

This process uncovered a surprising scenario with the Jackpot power-up. It seemed very simple: bonus coins accumulate into a pot each round, and after surviving five rounds, the pot pays out. On paper, it felt like a modest, passive reward that players wouldn’t attach to.

What couldn't be expected was how playtesters immediately gravitated toward Jackpot for the clear and tangible impact it delivered when it was combined with other power-ups. In such cases, its value scaled non-linearly for players and produced a major payout. As a result, players flocked to Jackpot for its clear impact in practice - much higher than the expected value. It became the go-to for synergy builds, and players ignored other options. 

Through the playtester’s feedback and observations, Duo Forge identified an urgent need. They needed to make several tune-ups to Jackpot so it would provide similar value without cannibalizing the other synergy power-ups. And they needed to make them fast. 

"Instead of tuning Jackpot in isolation, we used Bezi's Plan Mode to map out every power-up that could interact with or influence Jackpot, directly or indirectly. This gave us a dependency overview we wouldn't have been able to make by hand. And, more importantly, it let us iterate on it quickly while avoiding the classic trap of updating one thing and silently breaking three others."

Because Duo was able to iterate faster and with fewer downstream breaks, they were able to rework the mechanic before the next playtest session, ensuring plenty of time for players to test the ripple effects and verify it felt right before launch. 

The end-state was a balance point; Jackpot became a meaningful and exciting pick without dominating every synergy build. Players felt the satisfaction of a big payout, the perceived strength was preserved, but the expected value was brought down to match the rest of the power-ups.

Happy accidents could be discovered in a playtest session, iterated on, and retested the next week - not after weeks of implementation work. Faster iteration and implementation shifted the focus to testing, which is where it should be.


TECHNICAL TAKEAWAYS

1.  Build categories before features.

Define how mechanic types interact with each other before implementing individual power-ups. This turns each new addition into a classification question rather than a full compatibility audit.

2.  Balance combinations, not components.

In a system where mechanics stack, the unit of balance is the interaction, not mechanics in isolation. Testing needs to reflect how systems behave together under real run conditions.

3.  Debug chains, not nodes.

Emergent bugs in connected systems rarely originate in a single mechanic. Tracing the full interaction sequence, rather than examining each power-up independently, is what actually surfaces the cause.

4.  Measure perceived agency alongside numerical strength.

Mathematical balance and felt strength diverge regularly. A power-up's effectiveness in practice depends partly on how observable its effect is. Both require active testing, and only one appears in expected-value data without real players in the room.