“Sometimes feelings matter more than metrics”: Flexus's unconventional approach to hybrid projects

- Train Miner initially showed average retention metrics but went on to become a long-term commercial success.
- Instead of overhauling gameplay, the team focused on look & feel.
- Early tests showed 35% Day-1 retention, but polish and expanded content later improved metrics to 50% D1 and 3.6% D30.
During its very first test, Train Miner delivered only average retention metrics. But instead of radically overhauling the gameplay, we spent over six months polishing its look & feel. The result? A one-of-a-kind project built without any clear references, and for almost three years now, it’s been generating hundreds of thousands of dollars in revenue every month, even though the game still hasn’t fully hit its stride (major updates are on the way).
From the start, Train Miner was designed with a polished look & feel in mind. At launch, the game relied solely on ad monetisation, which meant it had to be addictive above all else.
That said, even in our past projects with Azur Games, our signature approach has always been attention to detail: juicy, satisfying visuals, smooth animations and VFX, responsive controls - the kind of elements you can’t just learn to make overnight. That accumulated experience in crafting “feel-good” gameplay became a major advantage for us here, and arguably our biggest USP.
Searching for a concept without references
The idea for Train Miner emerged in 2023 as part of our constant, unsystematic ideation process. We’re always coming up with new concepts, playing console and PC games, tossing around ideas, and critiquing each other. And when one of us says, “Hey, that’s actually a great idea, and there’s nothing quite like it out there,” we start prototyping.
Even now, with several profitable games already live and demanding ongoing support, we still make time to jot down new ideas, discuss them with the team, and jump into production if the niche feels open.
The idea for Train Miner emerged in 2023 as part of our constant, unsystematic ideation process.
Honestly, even if we didn’t have a revenue cushion from previous games, it’s been a long time since I’ve seen a clone perform well enough to reliably support a studio. Cloning just doesn’t work the way it used to, and the rare success stories are exceptions for a reason.
When the concept for Train Miner clicked, we went looking at all the train-themed games on the market. There were plenty, but nothing that felt quite like what we had in mind. Some of our inspiration came from PC titles like Loop Hero, not for its mechanics, but for the hypnotic looped movement.
That’s why in the early versions of Train Miner, the track didn’t expand randomly as it does now; it followed a strict rectangular loop. Still, it had that classic “just one more turn” effect you get in games like Civilisation. After each lap of collecting resources, you just wanted to do another. And another.

Early metrics and 20 minutes of replayable gameplay
In our first test build, the track didn’t expand, it was just one looped level with around 20 minutes of gameplay. First test R1 hovered around 35%, which isn’t much in today’s competitive market. But the feel of the game really resonated, so much so that players replayed that one level over and over again.
Initially, there was no wagon merge. We were experimenting with a different mechanic where each resource type required its own specialised tool - an axe for wood, a pickaxe for ore, a drill for crystals, and so on. Each wagon had an HP bar that depleted as it harvested. But in practice, this approach cluttered the screen and overwhelmed players.
If we hadn’t run that payback test, we might’ve just seen the mediocre metrics and killed the idea right then and there.
The visuals became chaotic, the gameplay hard to follow, and players found the experience more frustrating than fun. Ultimately, we realised all we got was a bunch of nonsense and scrapped the mechanic in favour of something cleaner and more intuitive.
At the same time, global UA didn’t pay off, but in the US, user acquisition paid back threefold. That’s the signal we clung to. Despite the lacklustre metrics, we saw potential growth areas and kept iterating.
If we hadn’t run that payback test, we might’ve just seen the mediocre metrics and killed the idea right then and there. And there was a lot to fix, from balance to core gameplay. But the very first thing we did was completely rewrite the architecture from scratch.
First changes and refactoring
After the first test, we switched developers. And honestly, the build was so full of leftover experiments that rewriting it from scratch was just easier - we cut all the noise and simplified development. It took two months, and it was 100% the right decision.
We had a similar experience with DyeHard, another profitable project of ours. We didn’t rewrite it after its early tests, and refactoring ended up taking a year and a half. So if you’re working on your first game, maybe you can take your time and avoid rewriting everything
But if you’ve already got a portfolio, I think early refactoring is a healthy practice, especially when core gameplay evolves mid-development, new ideas get tacked on, and duct tape solutions start piling up.
If you’re working on your first game, maybe you can take your time and avoid rewriting everything.
Once we’d rewritten the code, we moved on to our favourite part: polishing the details. We didn’t touch the core gameplay, but we immediately started fine-tuning the feel of the controls.
We tested swipe gestures, but the winner was a simple “hold anywhere on screen” control, like pressing a gas pedal.
We polished screen transitions, improved the train’s movement and stop animations. We refined object physics: how the train felt when loaded vs empty, how trees and rocks responded to saw blades. We’ve also put a lot of effort into sound to make sure everything came together - now, even the train’s speed affects how the sound effects are perceived.
We spent six months on this initial tuning phase. And during that time, Train Miner evolved beyond hypercasual. It became a hybrid: part idle game, part transport tycoon, with touches of simulator and puzzle mechanics mixed in.
Key changes
The core design shift was making the track expand organically - when a resource tile is cleared, a new piece of track spawns in its place.
That might sound obvious now, but making it feel natural and satisfying took a lot of iteration. Technically, this created a ton of new challenges: resource tiles now took damage from different wagon types at varying angles, broke apart unevenly, and the animations had to account for all of that.
A lot of teams tried to clone Train Miner, but they couldn’t replicate the level of polish and internal logic, and that’s where years of look & feel experience gave us an edge.
The result was a game that looked significantly deeper and more interesting. We never set out to build a hypercasual title, we just wanted to make a great game, but it was around this point that the project naturally started to feel like a hybrid.
Around the same time, we added a ton of other subtle details: effects when saw blades collide with specific resource types, popups when new wagon types unlock after merging, and refined visuals for things like how the stacked resources behave on the train.

Here’s a funny example: want to instantly drop your Day 7 retention by 10%? Just shrink the height of the resource stack on the train. That’s what we did, and retention plummeted. So we not only reverted the change, we also made the stack even taller, with added wobble animations. And sure enough, we gained back more than we’d lost.
Now we’re even thinking about adding multiple carriages with visible stacks. Little details like that, the ones that enhance look & feel, really matter to players. That’s why we obsess over polish.
Most studios in this segment focus on speed - we focus on feel.
As you’ve probably noticed by now, our studio’s production process is pretty unconventional. Most studios in this segment focus on speed - we focus on feel. And if you’re always rushing the team, it’s nearly impossible to make something that feels this good. That’s our priority.
Usually, when a project shows average metrics, teams immediately pivot or abandon it. But we often double down and start polishing.
In hypercasual and hybrid-casual projects, a premium look & feel can be a game-changer. Micro-interactions, subtle VFX, fluid animations tailored to every action - that’s what can flip your numbers. And we’ve seen it happen.
Increasing retention, adding depth, and moving toward hybrid monetisation
To improve long-term retention, we focused on adding more content. At launch, Train Miner only had five islands - today, there are over twenty, with more in the works. Alongside that, we ran several iterations on game balance to improve early-day metrics.
We experimented with different combinations of resources per level (wood, stone, gold, etc.), made the early levels feel fast-paced and dynamic, and saved difficulty spikes for the later stages. It paid off, retention improved significantly.
Right now, our iOS US metrics show 50% Day 1 retention and 3.6% by Day 30, with average playtime for long-run users exceeding 6 hours.
The game is already over two years old, but it still feels like we’re only getting started. We’re prepping large-scale updates focused on hybrid monetisation. Initially, the project relied entirely on ad revenue, but games with in-app monetisation tend to be more predictable and longer-lived.
We’ve already added items, gems, chests - even animals that chase after the train - but those features haven’t moved the monetisation needle much on their own. Our target audience just isn’t motivated by gear stats or minor percentage boosts.
After many months of polishing, we’re now shifting more attention to the meta, live ops, limited-time events, and offers.
That said, adding items did improve product metrics by a few percentage points simply by making the game feel deeper and more rewarding. Some of those items even unlock visual effects, like lightning striking a chain of resources.
Interestingly, a large number of players don’t even bother upgrading their wagons. They just love the feeling of doing loops - the rhythm, the visuals, the feedback.
But for in-app monetisation to really kick in, we’re building events that amplify the importance of those items.
For now, the project is stable in terms of revenue, and that’s already a good place to be. But we’re confident it still hasn’t reached its full potential. After many months of polishing, we’re now shifting more attention to the meta, live ops, limited-time events, and offers - all to help the game level up once again.
Skip the final thoughts - let’s talk pipeline
Building games around look & feel comes with unique requirements, both in terms of team dynamics and development process. It demands game design expertise that’s well above average, and a team of creative minds, true geeks, really. And it means working for months without any guarantees, often navigating by feel rather than strict documentation.
When someone on the team has an idea, we don’t rush to write up specs. We discuss it, poke holes in it, and close the gaps. Someone might throw together a quick proof of concept; that’s usually enough to get going.
Next comes research. This is where we assess how unique the idea actually is. If we can’t find much out there, that’s a good sign. It means we might really be onto something original. But it also means we won’t have many references to lean on.
If polish doesn’t improve the project, then we change direction. And if that doesn’t help, we might put the game on hold until a new idea clicks.
Then came the experiments. This is where the magic happens - and where you absolutely cannot set hard deadlines. Human factors come into play here.
There’s a special type of dev who might underperform on routine tasks with strict deadlines, but when given the freedom to explore, they’ll blow you away. If you rush people through this phase, chances are you’ll never get the result you’re hoping for.
In most studios, if the first test shows weak numbers, the project gets axed or completely redirected. But if you do that, you’ll never know whether your original path might’ve worked after a bit of polishing. We take a different approach: if polish doesn’t improve the project, then we change direction. And if that doesn’t help, we might put the game on hold until a new idea clicks.
To be honest, we don’t fully trust the classic approach, especially in hyper-casual, where the instinct is to try and quantify absolutely everything. Sure, it’s natural to want to rely on data rather than intuition. But the reality is more nuanced.

On one hand, A/B testing is often the only way to truly understand what’s working and what isn’t. On the other hand, if you try to test every last thing, from marketing SDK updates to the tiniest tweaks, you risk getting stuck in endless two-week test cycles, and the game stops evolving.
Also, I don’t obsess over Day 1 metrics anymore. That mindset worked during the hyper-casual boom, but those days are over. If we had focused only on Train Miner’s initial R1, which was under 40%, we might have dropped the project entirely. But we trusted our experience and game design instincts more than the numbers.
That said, there are times when poor metrics are a red flag. If the team is clinging to a failing project out of stubbornness, hoping that “one more update” will turn it around, it’s worth stepping back. That’s when it’s worth taking a hard look at the situation - is the development going according to plan, or barely holding together? And if it’s the latter, is this the kind of project that’s really worth the headache? Even if you do get it to release, what are you realistically expecting in return?
Also, at that point, it might be a good idea to ask a publisher for feedback. Look into it: if discussions about shutting the game down keep coming up, there’s probably a reason.
I don’t obsess over Day 1 metrics anymore. That mindset worked during the hyper-casual boom, but those days are over.
It’s important to know how you relate to your audience, how connected you feel to the genre and niche you’re building for. If you’ve added a bunch of killer features and the game still won’t take off, maybe the issue is deeper. Both DyeHard and Train Miner pulled players in even when there was very little content, and now we’re building on that.
But for a new studio, it’s often better to go wide - more prototypes, more lessons learned - instead of getting stuck for years on one unproven idea with little to no professional growth.
Today, Train Miner might seem like an obvious concept, but it’s the polish, the visual depth, the attention to progression that make it feel truly unique. Without serious look & feel expertise, it would be almost impossible to replicate.
Sure, this kind of approach stretches development time, and that’s not even counting the time it takes to gain this level of experience. But it also makes it harder for others to compete. Projects like this monetise well and are tough to clone.
And so, Train Miner may be our last “simple” game. These days, we’re building deeper prototypes, even for PC. and moving further into genre-mixing territory.