How I Built a Multi-Game Tier List Site Without Hardcoding Every Ranking

Tier lists looked deceptively simple when I started building TierListBase.

Put a few characters, classes, or weapons into S, A, and B tiers, add some explanations, and ship the page.

That works surprisingly well — until you add another game.

I started with a ranking experience built around one game. Once I began expanding the site, some of the assumptions I had baked into the first implementation stopped making sense.

The terminology was different.

The things being ranked were different.

The available evidence was different.

Even the questions players cared about were different.

At that point I realized I wasn't really building a tier board anymore.

I was building a small publishing system for rankings.

Hardcoding works until it doesn't

A very simple tier list can be represented like this:

Character A → S
Character B → A
Character C → B

You can put that directly into a React component and be done with it.

The problem starts when rankings change.

Now you need to update the tier, the explanation, maybe the supporting data, and make sure everything still agrees.

Do that for several games and the page components slowly become part content, part database, and part ranking logic.

That was the direction I wanted to avoid.

The first important change was separating the ranking data from the UI.

Instead of asking a page component to know how a game works, the page receives a normalized representation of the result.

Conceptually, something like:

{
  "entity": "Example Character",
  "tier": "S",
  "role": "DPS",
  "summary": "Strong overall performance",
  "evidence": []
}

The actual model is more detailed, but the important idea is simple:

the frontend shouldn't need to understand how the ranking was produced.

Different games should stay different

One mistake I almost made was trying to create one universal ranking system for every game.

That sounds elegant until you actually try it.

A WoW-style ranking may depend heavily on roles, performance data, and specific content types.

Another game may rank characters or weapons using completely different inputs.

Trying to force both into the same ranking logic would make the shared system more complicated, not less.

So I ended up separating the product into two layers.

The shared layer handles things such as:

• navigation
• tier presentation
• filters
• entity cards
• methodology
• sources and evidence
• common page structure

The game-specific layer handles:

• what is being ranked
• roles and categories
• game terminology
• ranking inputs
• source logic
• game-specific interpretation

That boundary turned out to matter much more than the tier board itself.

The board is just presentation.

The difficult part is deciding what should be shared and what should remain specific to each game.

I also wanted rankings to explain themselves

Another thing that bothered me about many tier list sites is how often the ranking itself is the entire argument.

Something is S Tier because the page says it is S Tier.

That may be enough for someone who only wants a quick answer, but it becomes difficult to maintain once the ranking changes.

I wanted the pages to be able to answer a few basic questions:

• Why is this ranked here?
• What evidence was used?
• What changed?
• Is this based on data, editorial judgment, or both?

That doesn't make a tier list completely objective.

I don't think that's realistic.

But there is a meaningful difference between publishing an opinion and publishing an opinion with visible evidence and methodology behind it.

It also makes updates easier.

If a ranking changes, I can look at the reason for the old position instead of just replacing one letter with another.

Adding the second game was the real architecture test

The first game didn't really prove the architecture.

Almost any system can look well designed when it only has to support one use case.

The useful test came when I started adding another game.

That exposed assumptions that had accidentally become part of the shared product.

Things I thought were generic were actually game-specific.

Some filters didn't make sense anymore.

Some terminology didn't travel well.

Some ranking fields existed because the first game needed them, not because a tier list product needed them.

That process forced me to simplify the shared layer.

If a concept only existed because one game needed it, it usually belonged in that game's module.

If multiple games needed the same behavior, then it had a better chance of belonging in the shared product.

That sounds obvious in retrospect, but it was much easier to see after the second implementation existed.

The same separation helped with SEO

There was an unexpected benefit to this structure.

Tier list sites naturally end up with many search-driven pages.

Games, characters, weapons, classes, builds, and other entities can all have different search intent.

If every page is built independently, things like titles, headings, internal navigation, methodology sections, and page structure quickly drift apart.

Having a shared page model made that easier to control.

It doesn't mean generating thousands of near-identical pages.

I'm actually trying to avoid that.

It means that when I add a page, I don't also have to reinvent the site's information architecture.

The game-specific content can change while the underlying product structure remains predictable.

What I ended up building

I originally thought I was building a tier board.

What I actually ended up building was a small system for publishing and maintaining rankings across different games.

The flow is now closer to:

Game-specific evidence
        ↓
Game-specific ranking logic
        ↓
Normalized result
        ↓
Shared presentation
        ↓
Explanation and evidence

The useful part of this architecture is not that every game becomes identical.

It's that they don't have to.

The differences stay where they belong, while the rest of the product can remain stable.

I'm still refining that boundary as I add more games, but so far it has been much easier to work with than treating every tier list as a separate static page.

For anyone building ranking, comparison, benchmark, or other data-heavy content sites, I'm curious where you draw the line between structured data and editorial judgment.