Tech Race: Why business and engineering need to plan together

Ahead of the Tech Race Summit 2026, SOFTSWISS Chief Technology Officer Sergey Kastsukevich shares insights on the critical balance between business growth and engineering scalability in the gaming industry.

Opinion.- Every operator wants to launch faster, enter new markets quickly, and release new features before competitors do.

Engineering teams want exactly the same. The difference is that they are also responsible for making sure the platform still works six months later.

That difference in perspective creates one of the biggest tensions inside technology companies. Business naturally focuses on growth and speed. Engineering has to consider scalability, reliability, and what happens after launch.

Ahead of Tech Race Summit 2026, Sergey Kastsukevich, Chief Technology Officer at SOFTSWISS, shares five things operators and providers consistently miss when planning the work of their technology teams.

1. Fast launches often create slow platforms

“Business always wants things fast, high-quality, and cheap. But you can only pick two out of the three.”

A common assumption in product development is that the first version only needs to work. The rest can always be added later. The logic seems reasonable enough: release a first version now, the second has just a few changes.

From an engineering perspective, it rarely works that way. A feature that looks like a small update on a roadmap can turn into an expensive redesign, requiring a rebuild from scratch.

This tension is not a failure of planning. It is the core negotiation every CTO manages. In a startup, accepting a 30 per cent risk that the system will break tomorrow is a rational trade-off. In a mature platform handling real money across regulated markets, it is not. The earlier that distinction is made explicit and agreed upon, the less it costs later.

2. Scalability starts long before the first customer arrives

“Launching for five players per hour is easy. Launching for thousands across multiple markets is where engineering discipline matters.”

“Why can’t you just handle a million users?” is a question engineering teams hear more often than they should. The assumption behind it is that scale is a setting – something you turn up when needed.

For engineers, the better question is much earlier: “Did we know we would eventually need one million users?”

Scalability is an architectural decision made early. If it is overlooked, problems arise when new requirements keep appearing one after another. More markets. More payment methods. More integrations. More traffic. Each one carries load implications that never appear in the brief.

Technology teams need to manage these expectations without waiting to be asked. When a client or internal stakeholder describes what they want to build, the engineering question – “what does this system need to handle, at what scale, under what conditions?” – has to be part of the same conversation.

If the need for scalability emerges after development is complete, it happens at the worst possible time.

3. Technical debt eventually becomes business debt

“Business and technology often optimise for different things.”

Technical debt is often treated as an engineering issue, though it is actually a business decision.

This decision is hard to make in the moment. Nothing is visibly broken, and the system is running. The argument for investing engineering time in something that does not change the product’s functionality rarely wins in a roadmap conversation.

What changes that calculation is timing. A shortcut taken to hit a launch date or a patch applied under deadline pressure look manageable on their own. In reality, they are just postponed costs.

Suddenly, releases slow down. Bugs become harder to fix. Every new change depends on something old and fragile underneath it. As a result, a straightforward feature request takes three months instead of three weeks.

Eventually, the business has to approve a major rebuilding project that could have been avoided through steady investment over time.

Technical debt never disappears. It simply waits.

4. Outdated technology is a risk, not just an inconvenience

“Tools evolve every few months, and people need to be comfortable abandoning what they’ve just built and switching to better solutions without friction.”

“If it works, why change it?” is a reasonable question with an unreasonable answer.

Legacy systems work – until they do not. The problem is not that they fail suddenly. It is that they become progressively harder to maintain. Fewer engineers know how to work with them, which slows down security updates and complicates integration.

One of the hardest conversations engineering leaders have with business is explaining why technology needs investment, even when nothing appears broken.

The business questions do make sense: “Will this make the platform faster?”, or “Will it increase revenue?”

Sometimes the honest answer is no. But the real benefit is reducing future risk. Old technology limits what new technology can connect to. It creates dependencies that block product decisions.

The way to make this argument to business is to reframe it from technical improvement to risk management. Then the question changes from “what do we gain?” to “what do we avoid?”

5. Great products need time for research

“The bottleneck is no longer how to build something, but what exactly to build.”

Large technology companies invest heavily in research. Google maintains dedicated labs exploring ideas that may never reach users. OpenAI spent over 5 years on foundational research before ChatGPT became a global product.

Experiments that work tend to define entire product lines years later.

Smaller companies look at that model and assume it does not apply to them. Research departments feel like a luxury, something for companies with resources to spare. The result is that engineering teams spend most of their time on delivery and little on exploration.

The teams that experiment learn faster and spot opportunities earlier. And when a new technology shifts from interesting to essential – as AI has in the past two years – they are already prepared.

Research time is time spent protecting the business from standing still. Technology teams build more than software. They build the company’s ability to adapt.

Want to explore these questions with the people solving them? Tech Race Summit 2026 takes place on 10 September in Warsaw. The programme includes 30+ speakers from AWS, Google, Oracle, Cloudflare, and beyond. Get tickets at techracesummit.com.