Raccoon's Cup Pool

O Fox Cup Pool is an application developed for the Fox community on Discord.

The project was born with a clear goal: to use the World Cup to create a collective experience that increases community participation and keeps people connected throughout the competition.

More than just recording scores, the product needed to turn each match into a new interaction.

Predictions, ranking changes, placement forecasts, and banter among participants should all be part of the same experience.

Project Information

Type: Web application
Context: Fox community
Scope: Product, rule definition, UI, visual direction, frontend, backend, and infrastructure
Objective: Community engagement
Platform: Responsive web
Year: 2026

The Context

Pools usually start simply.

A spreadsheet, a few group messages, and someone responsible for calculating results.

This works while the dynamic is small. When the number of games, participants, and rules increases, the fun begins to depend on a difficult manual operation to sustain.

For the Fox community, the intention was not just to organize predictions.

It was to create a unique event.

The application needed to carry the community's identity, establish understandable rules, and give participants a reason to return throughout the Cup.

The Challenge

The biggest challenge was building an intuitive experience on a system that, by nature, has many rules.

A World Cup pool involves more than just picking a match score.

There are also predictions for the group stage, best third-placed teams, knockout qualifiers, champion, tiebreaker criteria, and different point weights.

Each new possibility increased the depth of the competition, but also added complexity to the interface.

The product challenge was precisely this balance:

create a complete competition without forcing the participant to understand the entire structure before starting.

The Strategy

The experience was organized around three main actions:

join, predict, and follow.

The participant accesses the pool using their Discord username, which automatically identifies the member by the community code. Then they can register or edit results until the start of each match.

When the game starts, the prediction is locked and becomes part of the official competition history.

This structure reduced the number of decisions needed at each stage and made the system’s behavior predictable.

The user does not need to manage the pool.

They only need to participate.

Defining the product rules

An important part of the work took place before the interface.

It was necessary to translate the competition rules into clear system behaviors.

Scoring takes into account different levels of accuracy:

• exact score;

• winner or draw;

• correct number of goals for each team;

• team positions in the groups;

• qualification for each knockout stage;

• champion and runner‑up.

The exact score carries the highest weight among a match’s results, while partial correct predictions still earn points.

This decision avoids a binary competition where only those who get everything right advance in the ranking. Even a partially correct prediction still yields progress and keeps the participant engaged.

In subsequent stages, the value of correct predictions increases gradually. The more difficult and far‑off the forecast, the greater its impact on the final score.

Making complexity visible

A broad score only works when the participant can understand where their points came from.

Therefore, the ranking shows more than just a total number.

The interface separates contributions from matches, groups, and knockouts, and highlights exact scores and winner predictions.

This decomposition turns the ranking into more than a position table.

It tells the story of each player’s participation.

Someone may be well placed by correctly predicting many winners. Another may advance by better forecasting rankings. Another may recover positions during the knockout stage.

The final result remains simple, but its origin stays accessible.

Integrated community experience

The visual direction was not treated as a layer applied after the product.

It was born alongside the experience.

The interface language uses elements such as touch, mission, ranking, and rewards to bring the product closer to the Guaxinil community universe.

Instead of a generic sports platform, the pool behaves like an event created within that group.

The identity also appears in messages, application states, participant titles, and prize presentations.

This consistency helps the product appear as part of the community, not just an external tool used by it.

An interface ready for the pace of the Cup

Most interactions occur near the start of the games.

This means the user can access the application with little available time, often on a phone, just to review or submit a prediction.

The experience was designed to reduce friction at those moments.

Matches need to be recognized quickly. The state of each prediction must be evident. Save and edit actions cannot create doubt. And the lock after the game starts must happen predictably.

The priority was not to display the maximum amount of information possible.

It was to allow each person to understand the next step without having to learn the interface.

End-to-end construction

My role covered the entire project cycle.

I participated in product definition, structured scoring rules, designed the experience, led visual direction, and developed the complete application, including frontend, backend, and infrastructure.

This integrated role allowed technical and product decisions to be treated as parts of the same problem.

A scoring rule did not affect only the database.

It altered the ranking, interface feedback, tie-breaking criteria, and how the participant understood their performance.

Similarly, a visual choice could not exist solely for aesthetics.

It needed to help the user identify states, priorities, and actions.

Result

The result was a platform unique to the community to follow the entire competition in one place.

Participants can submit predictions, review their choices, track the leaderboard, understand how points are calculated, and compare their performance with other members.

The operation that once relied on spreadsheets, manual calculations, and scattered messages now takes place within a single seamless experience.

Beyond automating a pool, the product introduced a new layer of interaction for the community.

Learning

The most significant advancement of the project was not implementing a specific rule.

It was hiding the complexity without removing depth.

Behind a simple action like submitting a prediction there are time restrictions, different calculations, tie-breaking criteria, progression between stages, and leaderboard updates.

The user does not need to carry that burden.

They need to trust that the product knows what to do.

In the end, an intuitive experience is not one with few rules.

It is one that organizes the rules without transferring their complexity to the user.