Viktor Cherkas: “Don’t Turn Every Request Into a Product Priority”

Viktor Cherkas, CEO of Kanggiten, went from running an operator business to building the platform behind it. He explains where flexibility gets costly, how he weighs operator and player needs, and why migration is no answer to weak execution.

Clast: Viktor, you worked as an operator for years before developing technology. Looking back, which aspects of the operator’s role seemed simple at the time, but turned out to be much harder once you were responsible for building the platform?

Viktor: I underestimated how hard it is to build flexibility without creating complexity. On the operator side, you look at your own business and think, “We just need this bonus rule or one more setting.” It feels like a small change.

When you build the platform, that change has to work across different brands, player journeys, and existing configurations. You also have to make it clear enough for teams to use without needing a developer every time.

My operator experience helps me understand the request. Building the platform taught me to look beyond it: what problem are we solving, and can we solve it in a way that works for other operators too?

Clast: When the optimal solution for the operator conflicts with the optimal solution for the player, which side should you prioritise? Can you think of a product decision where this trade-off was particularly challenging?

Viktor: I consider the long-term impact. Damaging player trust for a short-term gain is rarely a good business decision.

Bonus rules are a difficult example. Operators need protection from abuse, but too many restrictions frustrate regular players. I’d keep the necessary safeguards, make the terms clear, and rethink any rule that hurts legitimate players more than it prevents abuse.

Clast: Kanggiten now covers a very broad range of areas, including casinos, sportsbooks, payments, CRM, affiliate management, analytics, and game aggregation. How do you strike the balance between useful breadth and unnecessary complexity? Have you deliberately decided not to build anything?

Viktor: Having a broad stack is useful when it makes the operator’s job easier. If they need five people to manage something one person should handle, we’ve added complexity.

I’m careful with features built around one client’s workflow. A request can make sense for that operator and still be the wrong addition to the core platform. Sometimes the answer is an integration, sometimes a simpler solution, and sometimes it’s no. We shouldn’t turn every commercial request into a product priority.

Clast: In one of your interviews, you said that, while operator execution remains equally important, the platform provides the foundation. Once the platform itself is no longer the bottleneck, what usually becomes the next one?

Viktor: Usually, it’s how quickly the operator turns data into action. The tools are there, but campaigns stay the same, player segments are too broad, and teams are slow to test new ideas. A platform can make that work easier, but someone still needs to own it: spot the issue, test a change, measure the result, and follow through. That’s often where the next bottleneck appears.

Clast: When an operator approaches you saying that they need a better CRM system, gamification or a new payment flow, what factors do you consider before accepting this diagnosis? Can you recall a case where the data suggested a different problem?

Viktor: First, I analyse what’s underperforming and where players are dropping off. A request for better CRM or gamification doesn’t necessarily indicate the root of the problem.

With our solution, InTarget, we can usually demonstrate results using the tools already available. Once the operator sees what it can do for their business, questions about alternative solutions tend to disappear. Often, the next step is making better use of what’s already there.

Clast: You use the term “platform ceiling” to describe the point at which the platform itself starts to limit how quickly a team can work. Now, let’s turn that around: when would you advise an operator against migration? When would changing the platform be an expensive way of avoiding a problem elsewhere in the business?

Viktor: I’d advise against migration when the operator can’t clearly explain what the current platform prevents them from doing.

If the real issue is weak retention, unclear ownership, or slow execution, those problems will move with them. They’ll spend money and months changing technology, then face the same results.

Migration makes sense when there’s a specific limitation holding the business back and the new platform can remove it. Otherwise, I’d first work on how the team uses what it already has.

Clast: Have you ever had a client insist on a bonus mechanic, product flow or feature that your team was convinced would harm the business? To what extent should a technology partner challenge the client rather than simply building what they ask for?

Viktor: If we believe a request will hurt the business, we should say so and explain why. I’d challenge it with data, show the risks, and suggest a better way to achieve the same goal.

If we still disagree, a limited test can help settle it before a full rollout. The operator owns the business decision, but our job includes giving honest advice. Simply building everything they ask for isn’t much of a partnership.

Clast: Where do you see AI genuinely improving the AML and KYC processes, and where would you still want a human involved?

Viktor: AI can help teams review information faster, spot unusual patterns, and prioritize cases that need attention. That gives people more time to investigate properly.

I’d keep a human involved when the evidence is unclear or a decision could significantly affect the player, such as restricting an account. 

A risk score can support that decision, but the team needs to understand the reason behind it and remain accountable.

Clast: You’ve described Kanggiten’s approach as “launch fast, scale safely.” At what point does the advantage of speed become outweighed by the risk? In which area would you rather lose time than take that risk?

Viktor: Speed is an advantage while the team stays in control of what it’s releasing. When deadlines start driving decisions and important checks get skipped, it becomes a risk.

I’d take more time with payments, especially withdrawals. Players expect access to their money, and any mistake there directly affects trust. That’s an area where I’d move the launch date rather than rush the release.