Why Flexus doesn't set hard development deadlines

Semyon Kozyura is the founder at Flexus.

Our stance on deadlines comes down to how we believe games should feel. When you’re building something the market hasn’t seen before, there are no close references or proven marketing numbers to lean on - so traditional estimates fly out the window. All you really have is product sense and game design expertise.

That “creative first” approach makes us happy and helps our games grab players’ attention. If a game is truly one of a kind, its retention will almost always be higher - because it's the first to meet a specific need for its audience.

Working closely with our publisher, Azur Games, we’ve seen how this focus on originality pays off, as they’ve supported us in bringing unique titles to a global market. The 10th action idle game on the market, even if it’s slightly better polished than the original, won’t hold players nearly as well if it doesn’t bring anything new to the table.

Games like this are also much harder to clone. A competitor first has to figure out the rules of a genre we invented. For example, after we released Dye Hard, clones started popping up almost immediately. Some even had more content.

However, their CPI ended up 2.5 times higher, and their retention rate was half of ours. Because polish matters. And not just by 10 - 20%, as some people like to think.

In short, we see three big advantages in doing things this way:

1. A chance to break above-average metrics.
2. Strong protection against clones - because the genre itself needs to be decoded, and we’re the ones who came up with those rules.
3. And, frankly, we just love doing it.

Sure, this workflow isn’t for everyone - most studios should probably take a more conventional, market-driven route - but we hope our experience is at least useful (or interesting) to someone.

Standard pre-production usually starts by hunting for similar titles. Take our own Train Miner. 

Before launch, there were plenty of train games, but none of them did what we do: the train mines resources, the track grows in a random direction, and there’s a merge layer where players add and attach cars to each other for more “power.”

Yes, some games let you loop around a map clearing terrain, but in the look and feel, controls, and goals, they’re completely different projects. With a truly unique concept, you have nothing solid to reference - so before development begins, you’ve got almost no data to cling to.

That leads to the key quirk of our workflow: forecasting is nearly impossible. We move by intuition and rapid experimentation, even if we aren’t 100% sure what the end result should look like or if there’s going to be an end result at all. How can you predict time and budget in that scenario? The industry loves guarantees, neat schedules, and tidy spreadsheets - we simply can’t provide them.

Picture this: you polish a concept for weeks, realise it’s “off,” pivot hard, redo half the work, and keep iterating until it finally clicks. On a macro level, nobody can say when that game will start earning money.

It’s also not clear what metrics the game will succeed on. Take Dye Hard, for example. We expected to see a modest CPI and unremarkable retention rates. Visually, the game was gorgeous, but the gameplay itself was half-baked.

The last game we launched at the time leaned heavily on visuals as well - CPI was rock-bottom, but retention was equally low. We expected the same story here, yet Dye Hard ended up posting really solid retention on a perfectly normal CPI.

If we had run tests at that point, we would’ve seen poor CPI results and likely dropped the project. But we didn’t. Instead, we kept refining it for 7.5 months to hit a baseline level of quality. Eventually, Dye Hard passed 100 million downloads and brought in serious profits.

Another strong example is Train Miner. We introduced an experimental mechanic with uneven road expansion, which led to a slight dip in metrics during testing. But we didn’t walk away from it - because we knew that if we gave it up now, we’d be closing the door on far bigger opportunities down the line. We were willing to take a short-term hit to the metrics in exchange for the long-term potential it unlocked.

The release version of Train Miner had just 20 minutes of gameplay - a single looped level. That’s it. But players loved the controls so much they’d replay that level three times in a row.

There’s another, often overlooked side to all this - what we’d call ideological scaling issues. Let’s say you launch a unique game, and it takes off. Cool. But then you try to expand it with new mechanics, and suddenly, nothing fits your core gameplay. So, anything you might want to implement has to go through meticulous tailoring first.

That’s what happened with the first version of Train Miner. There was no wagon merge back then. We used a different system: each resource had its own consumable required for mining - axes for wood, pickaxes for iron, drills for crystals. Each car had HP that drained as it mined.

After playtesting it ourselves, we realised the mechanic felt flat, and the chances of us turning it into something satisfying or addicting were slim to none. Everyone sensed we needed another train upgrade system. So we reworked it. Over and over. Until we landed on the merge mechanic, we use today. 

And that brings us to the reality of working like this: there are no references, no clear cost predictions, no guaranteed monetisation levers. Imagine walking into a publisher pitch with that.

Either you’ve earned a level of trust that lets your track record speak for itself - or you do it alone. And doing it solo? That always comes with a high price tag.

The Flexus pipeline

Everything starts with an idea. At this point, we usually skip the formalities - no documentation, no pitch decks. Someone brings a concept to the table, we discuss it, poke at the weak spots, and sometimes someone even builds a quick proof of concept to see if it clicks.

Take Train Miner as an example. The very first version didn’t even feature track expansion. Initially, we imagined the train just running in a loop, kind of like in Loop Hero. But after tossing ideas around internally, we pivoted toward the free-form track-building system the game has today.

Next comes the research phase. This is when we start to understand how unique the game really is. Ironically, the less information you find, the better - it means you're heading into uncharted territory. Still, research is essential. You dig up anything that could help you build smarter. When we were working on Dye Hard, for instance, we looked into how locations were painted in Splatoon on consoles.

Besides the general quality benchmark, that gave us a vision of how paint could look in an action game, and we adapted that technology for mobile, where no one had done anything like it, especially not in hypercasual. In some regards, it actually turned out even better than on console - though I spent weeks polishing the tech until 4am every night. Honestly, I didn’t mind. I kind of enjoyed it.

Then, we enter the experimental phase - the most critical stage, where the real magic happens. And that’s exactly why setting hard deadlines here just doesn’t work. This part of the process depends heavily on the people involved.

There’s a certain kind of person we love working with: an unconventional thinker, wildly creative, an artistic geek, if you will. These folks may struggle with routine tasks, but give them freedom, and they’ll come back with something unexpected - like, “Hey, I made 10,000 units controllable in multiplayer mode”. They might not thrive under rigid planning, but in a more open, exploratory environment, they shine.

Push too hard during this stage, and you'll likely kill the thing you're trying to grow. If the early tests show weak numbers, the typical response is to scrap the project or switch direction entirely. But that approach ignores a crucial question: how good could the original vision have been if you’d just given it more time?

This is one of the biggest challenges we see today - especially in hypercasual, where speed often trumps quality. But if you’re racing to finish something in two weeks, how are you supposed to learn animation deeply, refine feedback loops, or make interactions actually feel good?

Our approach is simple: if the game improves during polish, we keep going. If it doesn’t, we switch direction. If that doesn’t help either, we might pause the project until we figure out how to break through.

Things to keep in mind with an experimental approach

Even when it feels like you’ve nailed the tech and know exactly how everything works, unexpected challenges can still show up in later stages- often tied to that very same tech. You may suddenly realise that pushing the idea forward is either extremely costly or flat-out unfeasible.

That’s what happened to us with Dye Hard. The paint tech was stable and polished, and we were excited to build a battle royale mode around it. But as soon as we started, we hit a major wall: our system wasn’t designed for implementing more than four colours for different teams at once, which was essential for that mode. We ended up burning almost two months on a detour we didn’t see coming.

That’s why my advice here is simple: if the next iteration is too risky and you can’t afford it - just don’t. Stick with something adjacent to your current tech, but don’t go too deep unless you have the resources to support that kind of gamble.

And while we talk a lot about going against the grain, that doesn’t mean you should ignore the market entirely. To build truly original games and still win, your game design and product expertise has to be sharper than average - way sharper.

Which brings us to one more critical factor: your team. When you're building something around unique tech, it becomes closely tied to the people behind it. They’re not just using tools - they’re mastering them.

That kind of personal expertise is hard to replace. If someone like that leaves, you don’t just lose a teammate - you lose a chunk of the project’s DNA. That’s why a hire-and-replace approach just doesn’t work for us. What does work is building long-term relationships and truly listening to your people. 

What it all adds up to

Speed isn’t our superpower. Flexus focuses on conceiving something distinctive and refining it until it plays brilliantly. The more original the project, the more it stands out.

In a little over five years, we cranked out fewer than 30 prototypes. We shelved roughly half of them on sight - no tests, just cut our losses when they hit a dead end. Of the 15 we did send to testing, four made it to launch, and together, they’ve pulled in north of 250 million installs.

That path is painful for anyone who relies on rigid forecasts and milestones. Unlike most studios, we don’t lose sleep over middling test numbers and refuse to judge a half-baked game. Until a feature hits our quality bar, any metrics are noise. And polishing can help you reach way higher than a 10% to 20% difference.

Our mantra: perfect the details first, launch a fully-fledged game, add monetisation, then see how the market responds. After that, you can plug the game into whatever traditional live ops pipeline your company already trusts - and let the numbers tell their own story.