Process

From 2.0 to 2.1: How We Rewrote Two Years of Work Without Losing the Client

Written by
Bohdan Kononets
Andrei Zolotukhin
Category:
Process
24 March 2026
12 min read

This article is part of the Flatstudio × Stavka.tv case study. Written for product teams and founders who care not just about what the final product looks like, but about what happens when things go wrong — and how to work through it. Main article in the series — here

--------

There's a moment in long projects that everyone dreads but almost nobody talks about openly.

You've been designing for two years. Figma has started to lag — the same way Sketch used to lag under the weight of a complex project. Every screen has been thought through to the component state. You know the system from the first to the last interaction state. And then, at some point, it becomes clear: this cannot be launched.

Not because it's bad work. Because there's too much of it.

Stavka 2.0: When Ambition Became the Problem

Before 2020, Stavka had a working product but no system. In 2020, alongside the rebrand, we started designing a fundamentally new version. The ambition was real: turn a predictions platform into a full social-analytical ecosystem for the betting audience.

We designed for two years. And in those two years, we drew a lot.

  • A ranking system with divisions — modeled after FIFA 20, which we were actively playing with the client at the time. Leagues, divisions, promotion between tiers, a complex points system. Andrei Zolotukhin, our UX Desig Lead, did thorough research into how FIFA's progression was structured: the mechanics of moving between divisions, the balance of difficulty and motivation, the logic of ranking points. Viktor believed in this deeply and pushed hard for exactly this approach. I liked the complexity of the idea — nothing like it existed in the industry yet, and that alone felt like an argument. Andrei was excited about it early on too, but the deeper he got into the details — how to make it understandable for users without being overwhelming for the dev team — the more often he started saying that maybe we were going in the wrong direction. As tends to happen with ideas people are fixated on, we didn't hear him. Nobody did.
  • An achievement system with progression — dozens of badges organized by category and division. Each achievement had unlock conditions, tiers, and animations.
  • A social layer — direct messages between users, an activity feed, subscriptions to tipsters and pros, user-generated stories, a notification system.
  • Match and league analytics — deep statistics for both team and individual sports, transfer market data, trend analysis.
  • Bookmaker integration — so a user could connect their real bookmaker account, analyze their actual bets, and practice with virtual predictions on the same platform.
  • User-created tournaments — so anyone could run their own predictions contest.

While we were building all of this, the tool caught up with us. Figma started slowing down. At the time, there was a popular opinion in the design community that Figma doesn't lag — unlike Sketch — and that this was one of its biggest advantages. Andrei and I used to read those posts and laugh: those people just hadn't designed interfaces at this scale. We split the project into separate files — design system and component library in one, everything match-related in another, the profile in its own — but the lag happened anyway.

To speed up interface review, Andrei  and I built our own Figma plugin. With one click, it replaced placeholder team logos, athlete avatars, and names with real data. At the time, it was common practice in the design community to test interfaces with Lorem Ipsum. To us, that felt wrong: a rankings interface with real tipster names and actual odds behaves completely differently than the same screen with dummy content.

Each of these ideas made sense on its own. The problem was that they were all tightly coupled. Remove one feature, and the logic of three others fell apart. Launch everything at once, and you were looking at another two to three years just for backend and frontend development.

[→ 🎆 Key screens from 2.0: the conceptual complexity in one frame]

We were genuinely enjoying what we were building. Learning how to design complex products, feeling like we were making something serious. But we didn't have the experience to see what it all actually cost. The design took two years to draw — how long would the backend and frontend have taken, in that era, without AI assistance?

That experience changed how we approach every major redesign since. Now, before any design work begins, we run a Product Audit & Discovery — several weeks of analyzing what already exists: what to keep, what to cut, what to build first and in what order. Plus competitor research and a prioritized roadmap. Then, and only then, design. Exactly what we were missing before 2.0.

The Decision the Client Made

The pivot decision was entirely Viktor's. Not ours.

We understood the project had grown very large. But we were still enjoying the process and not in a hurry to stop. It was Viktor who looked at the situation clearly: the product couldn't be launched in parts, and launching everything at once wasn't realistic. The answer was to take the best and simplest pieces, break them into a roadmap, and move in stages.

I'm genuinely glad we didn't argue or try to defend every screen. We could have. Two years of work is a compelling argument for your own decisions. But it would have been the wrong move.

We tried to understand the client's reasoning, agreed, and went back to figure out what actually needed to exist at launch.

What We Cut and What We Kept

This is where the real work begins. Not "redo the design," but make concrete decisions about each feature.

Removed entirely:

  • Direct messages between users
  • User-created tournaments and contests
  • User-generated story format
  • "Pro" accounts as a separate user type
  • Division-based achievement system
  • Division-based filtering of predictions by sport and tournament — the FIFA logic that seemed obvious to us but actually required learning to understand

That last one was an important cut. We had designed a user division page with statistics and standings relative to other players, with filtering by sport and tournament. In FIFA 20, this felt natural — and Andrei had real data supporting the approach. But FIFA is a game you sit down with deliberately to learn. A predictions platform isn't. Good research doesn't save you from a wrong analogy. An interface that requires use to be understood is a bad interface, regardless of how much work went into it.

[→ 🎆 comparison: division page concept from 2.0 vs. simplified profile in 2.1]

Simplified and kept:

  • Achievement system: kept, but removed the division layer and simplified the unlock rules
  • Tipster rankings: kept the divisions and points system, but removed the navigational complexity

The baseline for launching 2.1: Matches with filters. Match page with all tabs and statistics. Predictions feed. Prediction page. Profile with full statistics and simplified rankings. Achievements and basic gamification came shortly after launch — once the core was stable.

[→ 🎆 matches page with sport filters and sorting]

What Got Better — Not Just Smaller

2.1 isn't a trimmed-down version of 2.0. In many areas, we went further than what was originally planned.

The match page got five tabs. Nothing like this existed in 2.0. Each tab handles a distinct analytical task.

  • Preview — editorial text analysis of the match from the Stavka team.
  • Predictions — user predictions with filtering by odds, tipster, and sport. Each prediction immediately shows: virtual stake size, character count, reactions, comments, and a follow button for the author.

[→ 🎆 predictions feed with metadata and filters]

  • Statistics — head-to-head history, tournament averages, detailed breakdown: goals, corners, fouls, offsides by team and half.

[→ 🎆 match statistics page]

  • Trends — automatically generated patterns with odds attached: "this team has played 8 of their last 10 matches with total corners over 4.5." Not editorial analysis — structured signal from data.

[→ 🎆 match trends page]

  • Discussion — comments in a chat format, distinct from formalized predictions. A place to simply talk about the match.
  • Bookmaker pages were rewritten for both SEO and the user at the same time. We added real player reviews — actual feedback from players. Improved the "I play here" feature — a toggle showing how many people are currently active with that bookmaker. The left sidebar in 2.0 was more promotional; in 2.1 it adapts to the context of each page.

[→ 🎆 bookmaker page with reviews and "I play here" feature]

  • The user profile is one of the most important pages on the platform. It shows not just an overall ranking, but deep tactical analytics: performance by market (total, handicap, match result), by odds range (where someone consistently wins), and by sport — across their full history.

[→ 🎆 user profile: statistics and performance by market, odds, and sport]

We Redesigned Ourselves

Something important happened at the visual level, and it deserves its own mention.

The data in 2.1 is often the same as in 2.0. But the design is entirely different. We didn't "adapt" — we rethought every screen from scratch. It's like doing a redesign on your own previous work. Harder than a new project, because you know every decision in the old version and you know exactly where it was a compromise.

At the same time, we built a much stronger component and token system. And we did one thing nobody asked us to: we prepared the entire design for dark mode.

Dark mode was just starting to become a trend. We decided — if the token system is built correctly, switching to a dark theme should cost nothing. And it didn't: we only needed to add the dark color values, and the entire interface was ready to switch. That's not a bonus feature. It's proof that the system was built right.

[→ 🎆 light and dark theme comparison — key screens]

How Users Responded

Everyone was satisfied. The Stavka team and the audience alike.

One piece of user feedback stayed with us and became an internal benchmark for whether we're doing something right:

"I've never liked left-side navigation. Still don't — except on Stavka. It's the best interface I use. I'm 38."

That's not about left navigation. It's about good UX changing someone's prior experience. If your product makes a person reconsider their assumptions about an entire class of design decisions — you've done something that matters.

The Main Lesson

The hardest part of a major redesign isn't drawing new screens. It's deciding what not to draw.

An interface that requires use to be understood is a bad interface. It doesn't matter how well it's designed internally. FIFA logic doesn't work in a media product, because people don't come there to learn — they come to do something immediately.

One more lesson, about process: when someone on the team starts asking uncomfortable questions, it's worth listening sooner rather than later. Andrei saw the problem first. We only heard him once Viktor made the pivot decision. It's hard to say whether that's a plus or minus — but moments like that are clearer in hindsight, and they're worth building better processes around going forward.

Two years on 2.0 weren't wasted. They gave us an understanding of the product that can't be gained any other way. Some of the features from 2.0 are alive in the current version — achievements, deep statistics, performance by market. They just got there at the right time, not all at once.

--------

If your product is already live and you need to evolve it — without stopping, without rewriting everything from scratch, in stages — that's exactly how we work now through Post-MVP Evolution. What we went through with Stavka 2.1 became the foundation of that approach.

--------

If you're facing a major redesign and want to avoid our 2.0 mistake — start with a Product Audit & Discovery. Understand what exists, what to cut, and what to build first — before you start designing.

← Back to the main article in the series: "Sports Predictions Platform: An 8-Year Case Study with 3M Monthly Visits"

Other articles in the series:

→ Rebranding a Sports Platform: How We Built a Brand System Across 10+ Touchpoints

→ Promo for Bookmakers: Why Headers Convert at Zero and Popups Actually Work

→ Design Systems for Complex Products: Why It's an Investment, Not an Expense

→ How to Measure Redesign Success: Real Metrics After the Migration

Need a similar design?
Contact us
Authors
Bohdan Kononets
CEO and Design Director
Andrei Zolotukhin
UX Design Lead
FAQ

Frequently Asked Questions

Who are these solutions best suited for?

We design around complex, high-stakes products rather than simple marketing sites. Our solutions are best suited for B2B and B2C SaaS, fintech, sports tech and iGaming teams dealing with high-load dashboards, internal tools, betting platforms or multi-platform ecosystems. Most of our clients are startups and scale-ups that need a consistent design and engineering partner instead of a one-off creative studio.

What's the difference between a fixed‑price sprint and a long‑term retainer?

Fixed‑price sprints (like Fundraising Concept or Product Audit & Discovery) have a clearly defined scope, timeline and deliverables — for example, a 4‑week concept sprint or a 2–3 week audit. They are ideal when you need a sharp, focused outcome. Long‑term retainers (like Post‑MVP Evolution or Dedicated Product Units) are built for continuous evolution: we join your roadmap, work in sprints, and adjust priorities as your product and metrics change. You get a predictable monthly budget and an embedded team instead of re‑negotiating every feature.

How do I choose between Pitch Deck & Product Concept, Post‑MVP Evolution, Product Audit & Discovery, and Product Rebuild & Redesign?

Pitch Deck & Product Concept is for 0→1 founders who need to raise capital before writing production code – we turn your vision into an investable narrative and clickable concept. Post‑MVP Evolution is for Seed / Series A teams with a live product that needs faster iteration, stronger UX and a real design system. Product Audit & Discovery is for products facing churn, stagnation or negative feedback – we diagnose UX and tech friction and give you a prioritised roadmap. Product Rebuild & Redesign is for mature or legacy platforms that have hit a growth ceiling – we modernise brand, UX and code without breaking the business logic that already works. If you’re unsure, we start with a short discovery call and map your current stage to the right model.

How is "Engineering Design" different from a regular creative agency?

Regular agencies optimise for “wow” moments and campaigns. We optimise for systems and product performance. We treat design like code: modular, scalable and logic‑driven. Instead of drawing standalone screens, we build design systems, patterns and documentation that your developers can implement without guessing. That’s why our solutions always combine product & interface design, brand identity, web app engineering and marketing assets into one coherent system.

Do you work with startups or only established companies?

Both. Our clients range from early-stage founders raising their first round to enterprise teams scaling complex platforms with millions of users.

What do clients value most about working with Flatstudio?

Clients consistently highlight three things: deep industry knowledge, logical and scalable design systems, and honest communication. We challenge weak decisions early rather than executing them blindly.