The producer of Highcore Games, Alexander Valkovich, shared in a column for App2Top what distinguishes an MVP from a prototype, where efforts should be focused during pre-production, and why the rule "one or two iterations and closure" saves not only the budget but also common sense.
Roadside Empire — one of Alexander's projects
This text was prepared based on the "MVP That Made It" roundtable at the “Game Industry 2026” conference in Minsk.
Alexander Valkovich
What is MVP?
Let's start with the concept itself. What is an MVP, and where is the boundary of "minimum but viable"?
For me, an MVP is not a prototype or a raw build. It is a commitment to kill or confirm a product within limited money and time.
We create a prototype to feel it out, how it plays. MVP is the next step: it's about understanding if the entire venture has commercial potential. This needs to be understood as cheaply as possible. The cost is measured in money or time.
How is the work on MVP structured for us?
We know how metrics behave in this or that genre. For example, if we achieve a day one retention (hereafter D1) of around 40%, we're likely to see a D7 of around 10%. If we see 15 ad views on the first day, by the seventh day we'll gather more or less — 30. If the CPI is half a dollar, that's a signal of real player interest.
Finding benchmarks for each genre is not a problem; plus, we already know how a more or less successful project looks from the inside. My task in pre-prod: identify the metrics I must achieve to move forward and do only the work necessary to achieve them. If the plan is to get 40% in D1, then I make content for 1-2 days. Creating content "just in case" is no longer MVP.
With MVP, there are two classic extremes. The first is doing it too raw, so it's unclear whether it's a game or a prototype of mechanics. The second is prolonging development with faith in eternal continuation. I support neither approach.
How important is R&D before MVP?
The quality of pre-production determines everything.
Let's recall how most beginner companies launch prototypes into work.
- Option 1: a leader played a new game in the evening, spammed everyone in Slack "it's cool, let's make it" — and by the morning, everyone is working on it. Programmers transfer logic, artists create art, and so on.
- Option 2: the whole team brainstorms, calls, argues, and in the end, no decisions are made. For every argument, there are ten counterarguments. Meanwhile, the team is still wrapping up the previous game because they need something to do. Fatigue and lack of a unified opinion on what to do next constantly provoke conflicts.
There could be a dozen more examples, but for me, it's all about one thing: a lack of understanding that the pre-prod process and MVP development is a separate stage with its own rules. The saddest part is that decisions at this stage determine everything: whether the game will be released or not, whether there will be commercial success or not. Yet somehow, pre-production often gets less time than an ordinary task already in development.
From everything I've tried, four things have maximum effect.
1. One person responsible for pre-prod. The producer or head of game design. No dailies, no tasks for other teams, no feedback loops. If artists and programmers sit for two weeks without tasks — that's not a problem. They will work without a normal plan, and at this stage, their effectiveness is questionable.
2. Marketing analysis of the setting before game design. It’s crucial to find a trending or growing setting rather than going blindly. For example, the capacity of themes like "food" or "cars" is practically endless. A trending setting will put you a step ahead and give you permission to make mistakes. Use any means necessary at this step to make the right decision: research, networking, analysis — it all helps.
3. Play competitors’ games with spending. Not just one evening with a hookah, but specifically, rigorously, with real spending. Teams that ignore this principle will never mature to hybrid development.
4. A metrics table with weights even before development starts. 5-10 main metrics, each with their weights. After testing, fill it out and see: if achieved — move forward, if significantly missed — immediate rejection.
And on top of everything — serious work on game design, which removes the main risks in advance and answers questions like:
- how to scale content;
- how to introduce monetization;
- how to add PvP.
I've seen situations where a team gets into large-scale development, only to realize later that PvP doesn't fit this setting in any form, or that the process of assembling a large number of levels is simply impossible to organize due to production complexities or simple setting limitations. All of this could have been thought through in advance to avoid problems.
On what data should decisions be based?
On the metrics table you composed before the development started.
The mechanism is simple: clearly describe what you want to achieve. For example:
- day one retention no less than 36%;
- first day playtime no less than 10 minutes;
- first day ads no less than 10 views;
- CPI no more than a dollar.
Add weights and honestly look at the results. The weights help identify the more critical metrics and spot potential. Of course, it all depends on the genre, but in the Idle Tycoon genre, I stick to these starting indicators.
Two situations are simple. If achieved — move on. If significantly missed — close it down.
The third situation is the most dangerous: borderline values. You wanted retention at 36%, got 33–34%. It seems like there's potential, and you’re close to achieving it. I've seen this scenario dozens of times. A nightmare of a year's development with a profit of 5 thousand dollars a month.
Therefore, I have a simple rule: a maximum of one or two iterations for revision. If the metrics haven't moved after that — close it. Don’t fear setting high plan values. When a game has real potential, you won’t get 36%, but 40–45% on day one in CPI tests.
Cases
My Aquapark and Roadside Empire — success. Two weeks of pre-prod with marketing insights. A month and a half of development in dictator mode. The result: 40 minutes of quality gameplay with a loop, narrative, and sound. Retention, CPI, and base monetization — above planned. All constraints lifted, moved into full development.
One of our recent idle arcades — closure. It hit borderline metrics on the MVP. It was just a bit short. We dragged it for a year, iterating, believing we’d reach it soon. Finally, metrics stalled at minimally passing levels, and the project was closed. Now it barely covers the UA manager's salary. It's better not to recall the development costs.
The main lesson: borderline metrics are a one-year trap. The "one or two iterations and closure" rule would have saved this project — essentially, not letting it start.
Conclusion
Pre-prod that evolves into MVP is not a formality or a checkbox on the roadmap. It is arguably the most crucial moment in the entire life of the product when the game is still uncovered — not by meta, not by collections, not by events.
That's why you shouldn't rush to build add-ons until you've answered the main question: what is the game about? How does it feel? Do you want to return to it (not for the rewards, but for the process)?
All the meta, collections, PvP, and monetization only work when there's a living core underneath them. If at MVP the player didn’t feel the world and didn’t believe there’s something interesting here, or didn’t want to know what happens next, no overlay on top will fix it.
Focus on pre-prod, responsible approach to benchmarks, and honesty with yourself at the start — this isn't caution or process overload, but a real, proven way to quickly get that very "MVP That Made It."
I wish everyone metrics in the green zone. And if they’re not there yet — may the one or two iteration rule save you years of life.