Roman Balashov on Scaling BETON: How We Turned Startup Energy into Systemic Corporate Results

Every technology company starts with the energy of a handful of people who carry everything on their shoulders, from key decisions to daily processes. This model delivers speed early on, but past a certain point it turns into a constraint. Over the past year and a half, CITYCODE LLC (the BETON brand) has moved from ad hoc management to a divisional structure with clearly separated domains of responsibility. Here's what that transformation looked like from the inside.

When Manual Mode Hits Its Limit

While the team is small, ad hoc management works well — decisions get made quickly, and everyone holds the context in their head without any formal procedures. The difficulty starts once the volume of tasks outgrows what a handful of people can keep track of at once. At that point, legal risks start getting handled hastily, case by case. Every development team makes its own architectural calls, and over time their approaches drift apart. Meanwhile, checks stay manual and only kick in after something has already happened.

We reached that limit and began a systematic overhaul. It unfolded on three levels at once. First, new functional areas appeared that hadn't existed as separate units in day-to-day work before — Revenue, PMO, Technical, DWH, and Product Platform. Next, specialization took hold within existing areas. Instead of general-purpose teams, dedicated units formed within HR and Marketing. Development moved to a stream-based model. Product streams emerged, each with its own accountability: Billing Stream, Casino & Core Stream, and Sport Stream.

Two Moments That Set the Course

Formally, the transformation began in the summer of 2025 and is still ongoing. Within that wave, I'd single out two moments as defining.

The first came in July 2025, when we launched Revenue as a standalone functional area, bringing together CRM & Retention, Data Analytics, and Customer Operations. It was our first major unit of a new kind. Customer-centricity became a function in its own right for the first time, instead of staying scattered across different teams with no single owner.

The second moment came in April 2026, when the company stopped extending its old structure and started building new areas from scratch, following a new logic. The difference here is fundamental. We used to adapt the existing model to new needs; now we design each unit around a systematic approach from the start.

How Day-to-Day Work Has Changed

These changes are clearest in the specific functions that outgrew manual mode. I'll start with the Financial Monitoring unit, which covers compliance and AML control. Until recently, we dealt with legal and compliance risks on a case-by-case basis; now they are handled by a standing function with its own scope of responsibility that works proactively.

Analytics followed a similar path — the arrival of Business Analytics and DWH let us move to data-driven decisions, with the team now relying on structured analysis where it used to lean on intuitive judgment. The same shift is visible in how we handle the sports vertical, where Anti-Fraud within Sport Stream became a full-fledged, dedicated function, whereas checks used to run manually and only as needed.

The need for consistency led us to introduce the Software Architect role in the Technical division, responsible for technical coherence across development teams. Until recently, every team made its own architectural calls, and over time those approaches diverged. Now there's a layer that holds the shared logic together. The PMO rounded out this overhaul, giving us formalized project management where tasks used to be assigned as things came up.

The Benefits of a Divisional Structure

A divisional structure makes a company predictable to itself. When every domain has its own clear scope of responsibility, the company no longer depends on one particular employee holding the full context. A function starts to live independently of the person who launched it, and keeps working regardless of how stretched leadership is in any given week.

We apply the same principle to how we roll out technology. At BETON, we implement AI systematically, prioritizing real-world impact. We follow the same path here as in the structural overhaul — first figuring out exactly what function the technology serves, and only then building it into our processes.

In a transition like this, startup energy takes on a form that allows it to scale. Alongside this, speed and a willingness to experiment stay with us the whole way through — only now there's a structure behind them that can carry a larger volume of work. That's what turning startup energy into systemic corporate results is all about.