NextSport.io

A match starts as a score. A few minutes later, you want the stream, the story behind a roster change, or an explanation of what just happened. NextSport brings those moments into one sports and esports product: live matches, editorial coverage, in-site viewing, discussion, and a contextual AI assistant.

I designed and built almost the entire project myself: product direction, UX/UI, frontend, backend, integrations, AI tooling, analytics, and production delivery. From January to June 2026, I connected the experience people see to the editorial and operational systems behind it.

One match, several reasons to stay

The central product question was what happens after the first answer. A visitor checking a result may be finished in seconds. Someone arriving through a news story may never discover the match center. Meanwhile, the editor works on a different side of the same experience, deciding what appears, when it appears, and how it connects to the rest of the site.

I organized the product around that continuity. Match listings lead into a detail view. The detail view separates the overview, watching, analysis, history, and conversation. Team, player, and competition pages supply the surrounding context. News, articles, short-form media, and wiki content offer different depths of coverage, while the shared navigation keeps matches and streams within reach.

The match card became the smallest expression of the idea. It gives a reader enough information to decide whether to stop, open the match, or keep scanning.

A small card with a lot of responsibility

The card has three competing jobs: identify the event, communicate its state, and remain readable in a dense list. Team marks and names establish identity. The center carries the score and map progress. A quieter line holds the competition and series format. The live marker has its own visual priority, so an active match does not depend on someone noticing a tiny change in the score.

Those roles stay recognizable across disciplines. The data underneath them does not. A scheduled match, a live series, and a finished result cannot all be treated as the same row with a different badge.

External feeds can arrive late or with missing details. In those moments, the card keeps the available team, competition, and match information readable. Missing data does not become a fake score or an empty card. Readers can still identify the event and decide whether to open it.

Let the imagery change; protect what must be read

A sports product inherits visual material it does not control. Team logos can be dark, transparent, unusually wide, or almost invisible on a dark surface. Different disciplines bring different colors and imagery. Applying one attractive background to every card would ignore those conditions.

I separated the expressive background from the information layer. Each discipline brings its own artwork and colors; their intensity adapts to the theme. A Dota card can feel different from a CS2 card while the score, teams, and live state remain in familiar places.

Automatic contrast support protects team logos. The component compares the logo with its background and adds a light backing when a dark mark would disappear. That lets a black team logo stay recognizable on a dark card without changing the team's identity or requiring a manual fix for each new image.

The background establishes the discipline. Contrast treatment protects the mark. The text hierarchy carries the result. Keeping those responsibilities separate made it possible to change the atmosphere without rebuilding the information layer.

Protect the mark

Change the atmosphere

When the reader wants to understand the game

A score tells you who is ahead. Game Intel serves someone asking a different question: what is strong in the game, and how does that change at my level?

For Dota 2, the interface turns hero statistics into a field of recognizable portraits. Pick rate and win rate become the two axes, with rank filters changing the context. A familiar face on the chart is a quicker entry into the subject than a long list of hero names. The design preserves the distinction between popularity and success: a frequently picked hero is not automatically the strongest performer.

This is a different visual mode from the match list. Here, the reader is comparing relationships across a field of data. The larger plotting area, rank segmentation, and recognizable game assets earn their space by supporting that comparison. The surrounding product still provides a route back to matches, news, and discussion.

The detail goes beyond the chart. Counter-picks help players compare opposing heroes, while item-build timelines show how a build develops through a game. CS2 has its own combination of world rankings, live matches, top players, and Twitch coverage. Each game gets the information its audience actually uses.

Watching belongs inside the match experience

Scores explain the state of a game. A stream shows the event itself. I brought Twitch and Kick viewing into NextSport, with stream selection and chat alongside the match. On mobile, the player and conversation have their own tabs, so neither gets squeezed into a tiny desktop column.

I treated watching as a continuation of browsing. A reader should be able to move from discovering a match to watching or discussing it without the site losing its own navigation and context. The match detail keeps the immediate result near the top and uses distinct sections for deeper information, instead of asking every visitor to read the same long page.

NextSport controls the page and player container, while availability comes from the streaming provider. That made the surrounding context useful even when a feed was offline: the result, match history, and conversation still had a place.

An assistant that knows which match you mean

The AI chat is connected to the product context. A question can arrive while someone is looking at a match, a team, a player, a news item, or a competition. Passing that context into the conversation gives the assistant a starting point more useful than an empty chat box.

Match pages also contain a prediction surface. I kept the design distinction between recorded facts, explanatory conversation, and predictions: a score is a result; an assistant response is generated; a forecast is uncertain. Showing them near each other makes the distinction more necessary.

Behind the chat, administrators can choose the model and its instructions. The same administration also supports editorial AI tools, with separate settings for the different jobs.

Reading deserves its own product design

Someone settling into an article has a different pace from someone scanning live scores. I built a shared reader for news, articles, and Wiki guides, giving long-form content its own hierarchy without losing the connection to the rest of the product.

Headings create the table of contents. A progress indicator shows how far through the piece the reader has moved. Markdown supports tables, captioned images, embedded media, and game-specific details such as inline Dota hero references. Those capabilities let editors work with structured content while the public page controls its presentation consistently.

There is also a speed-reading mode. It presents words sequentially at an adjustable pace, pauses around punctuation, and supports keyboard controls. The conventional article remains the main reading experience; the alternate mode gives a reader another way to consume the same material.

Ratings, related stories, and live comments make the end of an article a meaningful decision point. The reader can respond, continue with a related piece, or return to the wider sports context. Wiki guides reuse the same reading foundation, so reference material does not feel like a different product pasted into the site.

Articles are available in Russian and English, with search-friendly pages and a Markdown version for readers and tools that need the content itself.

The other half of the product is the newsroom

Every public content module depends on someone being able to maintain it. The Smart News Editor brings writing, translation, AI-assisted rewriting, metadata, and publishing controls into one workspace. An editor can work in Russian and English, manage the title and body, select a discipline and author, set the publication date, and decide whether a piece appears as an article, a wiki entry, or both.

That last choice connects timely coverage with durable reference material. It also makes the editor a product surface: the person preparing a story is deciding where and how it will be discovered.

Translation and rewriting sit next to the article, so an editor can check the result immediately and keep working. The same workspace holds the cover, category, tags, search description, and publication time. Preparing a story includes deciding how readers will find it and what they will see first.

The wider administration extends beyond news: matches, predictions, media intake, community, and infrastructure all have their own controls. I also connected automated publishing workflows, alongside manual editing, so content operations could continue without every item being assembled by hand. The administration remained the place to review and manage the resulting material.

Media Hydratizer helps with an earlier editorial job: finding material worth developing. It brings in candidates from outside sources, analyzes them, and keeps source excerpts attached. An editor can see what a draft is based on before turning it into a story.

Imported material enters as an unpublished draft, with duplicate checks to avoid bringing in the same item repeatedly. Review, translation, rewriting, and publication then happen in the newsroom.

AI needs controls, not just a generate button

NextSport uses AI for editorial rewriting, translation, moderation, media analysis, and the public assistant. Those jobs ask different things of a model: preserve a writer's meaning, assess incoming material, or explain a match to a reader.

I organized the administration around those tasks. An editor can choose a model and instructions for translation without changing the public assistant. The settings stay close to the job they affect, making the AI tools understandable to the person using them.

Each task has its own controls

The configuration surface

For example, translation needs to preserve the article being edited. Match assistance needs the event, teams, and current context. Giving them separate instructions keeps those purposes clear even when they use the same provider.

Give the assistant something useful to retrieve

The knowledge base searches both by words and by meaning. A reader can name a team directly or describe what they are looking for in their own words. Administrators choose which content goes into that knowledge base and when to update it, connecting the assistant to the material maintained in the product.

A conversation needs a place

A live result produces questions and opinions as well as clicks. I gave the product both immediate conversation and a more durable forum: global and contextual chat for the moment, categories for discussions someone could return to. CS2, Dota 2, match predictions, news, and general discussion each had a recognizable home.

That distinction matters when the event is over. A chat moves quickly; a forum topic can hold a longer exchange. A dedicated feedback route gives product questions their own destination instead of mixing every kind of conversation into one feed.

War Room: turn a prediction into a game

War Room turns that motivation into a game. One card, one prediction, one swipe. A match becomes a question—will this team win?—with the two sides of the decision visible on the card. Swiping gives the choice a physical direction. The departing card tilts out of the stack, a decision label appears, and the next match takes its place.

Right means yes; left means no. The same choices are available through buttons, and a failed submission brings the card back so the player can try again. The artwork gives each card its character, while the teams, matchup, and competition keep the decision tied to a real event. The percentages come from the odds for that match.

The first interaction does not require an account. Guests can try three unsaved predictions before the registration prompt appears. That gives the gesture a chance to explain the game; creating an account then has a concrete purpose—keeping the player's progress.

A reason to come back tomorrow

The swipe is only the entry point. War Room has a season profile, quests, achievements, energy, and daily streak rewards. The headquarters makes that progress visible: claim a daily bonus, finish a quest, unlock an achievement, then return to play. A quest to read three news stories connects the game back to the editorial product.

The personal header brings rank and progression back into view when a player returns, while daily, weekly, and monthly quests give different rhythms to the same activity.

The season gives progress a finish line

Season, yearly, and archived leaderboards let players compare progress within a defined period. History supplies the personal side of that competition: which prediction won or lost, which match it belonged to, and how the balance changed. Win rate is calculated from decided bets, so an unresolved match does not masquerade as a result.

After a match resolves, the player can follow the outcome into their history and balance. Wins, losses, and refunds use virtual coins, giving each prediction a consequence that carries into the next session.

Rewards that change the next session

The store gives earned currency a use beyond a counter in the header. Coin and XP boosters accelerate progression, while energy packs let a player continue. The catalog also includes shield items. Each item needs a clear description, duration or quantity, and stacking rule; otherwise the reward is just attractive artwork with an unexplained number attached.

Energy recovers gradually while the game is active. Players can wait, spend coins on another energy pack, or choose a booster. The store explains how long an effect lasts and whether it extends or replaces an existing boost before the player spends their coins.

These purchases use in-game coins. I designed the reward economy as part of the continuing activity: play, resolve a prediction, earn, choose how to spend, and return with a changed state.

Make the change of mode visible

The illustrated onboarding introduces this change of mode with a comic treatment and a direct invitation to choose a match. The visual language becomes louder than the match center because the job has changed: the user is entering an activity, rather than scanning a list of information.

The match prediction connects progression to an event someone may already be following; the reading quest brings them back to the coverage. Those connections give the return loop a subject beyond collecting rewards for their own sake.

Mobile changes the order of attention

The desktop product can show navigation, a main content column, and supporting live or community modules at once. A phone cannot give every one of those elements the same presence. The mobile work therefore included navigation, match states, reading, and the relationship between the player and chat.

The underlying hierarchy stays stable: identify the match, read its state, then choose the next action. Secondary context needs a deliberate place to go. Stream and chat tabs are one example of letting the user choose the active task instead of compressing two desktop panels into an unreadable pair.

This also affected the component system. Team names and logos vary. Scores change width. A future fixture may have less data than a live one. Designing around those variations is more durable than tuning a card around one ideal screenshot.

After launch

I brought GA4 and PostHog into the administration so audience and product behavior could be read in the same place as the rest of the operation. The reports cover acquisition, reading, viewing, return visits, and War Room activity.

The useful questions are concrete. Did someone arrive on a story and open a match? Did a visitor use the viewing controls? Did a player return to a quest or make another prediction? The reporting connects those actions into journeys that can be followed over time.

In one month in 2026 after launch, the product reached 1,300 monthly visitors, with 23% reported retention for the same month. Visitors used the match center and viewing controls, moving from discovering an event to following it. That gave the project a real audience for the experience I had built.

NextSport now spans 33,000+ public pages: match histories, team and player profiles, competitions, and editorial coverage. That includes 24,462 match pages, 4,081 player profiles, and 1,930 team profiles. The shared design system gives this growing catalog a consistent structure without requiring every page to be assembled by hand.

The platform underneath the screens

Building both the interface and the backend made the integration boundaries part of my design work. Match feeds, streaming providers, editorial content, AI tasks, and analytics have different owners and update cycles. The product needs to bring them together without making a reader understand those differences.

I built the API alongside the website, making matches, editorial content, teams, Wiki, streams, and search available to other clients and integrations. The same product information can support another interface without being copied into a separate content system.

The administration also shows data sources and synchronization activity. When a match or story stops updating, there is a place to trace its source and manage the process behind it.

I designed partner placements, bookmaker information, and bonus surfaces into the relevant match and editorial context, alongside the core browsing and viewing experience.

The delivered system

The work ran from January to June 2026. I took the project from product direction and interface design through frontend, backend, integrations, and public release, including the tools needed to keep it running and publishing afterward. I handed the released product over for ongoing support.

Building the project myself meant owning the connections between those responsibilities. The match card is a good example: its appearance depends on discipline assets and contrast handling; its usefulness depends on data quality and freshness; its next action depends on the detail page, stream, and conversation; its surrounding coverage depends on the newsroom.

NextSport became a sports product people can browse, read, watch, and participate in, backed by tools for the people maintaining it. The design work holds those experiences together at the level of both the individual component and the running service.