DEV Community: Mark

Encoding FIFA’s 495 third-place scenarios for the 2026 World Cup

Mark — Wed, 27 May 2026 08:04:24 +0000

I expected the 2026 World Cup bracket to be a sorting problem.

It turned out to be a sorting problem plus a lookup table.

I recently worked on a small World Cup 2026 bracket project, and the strangest part was not building the knockout bracket itself. It was handling the third-placed teams.

The new format has:

48 teams
12 groups
24 teams qualifying as group winners and runners-up
8 more teams qualifying as the best third-placed teams
a new Round of 32

At first, this sounded straightforward.

Rank the third-placed teams, take the best 8, then put them into the knockout bracket.

But the last step is where it gets weird.

Ranking third-placed teams is the easy part

Once every group has a table, each group gives you one third-placed team.

That gives you 12 third-placed teams.

From there, the basic ranking can be represented as a normal sorting problem:

type GroupId =
  | "A" | "B" | "C" | "D"
  | "E" | "F" | "G" | "H"
  | "I" | "J" | "K" | "L";

type TeamStanding = {
  teamId: string;
  group: GroupId;
  position: number;
  points: number;
  goalDifference: number;
  goalsFor: number;
  fairPlayPoints: number;
};

A simplified ranking function might look like this:

function rankThirdPlacedTeams(teams: TeamStanding[]) {
  return [...teams].sort((a, b) =>
    b.points - a.points ||
    b.goalDifference - a.goalDifference ||
    b.goalsFor - a.goalsFor ||
    a.fairPlayPoints - b.fairPlayPoints
  );
}

This is not the complete official tie-breaker system, but it shows the shape of the problem.

You filter the third-placed teams:

const thirdPlacedTeams = groupTables
  .map(group => group.standings.find(team => team.position === 3))
  .filter(Boolean);

Then you take the top 8:

const qualifiedThirds = rankThirdPlacedTeams(thirdPlacedTeams).slice(0, 8);

So far, this still feels like a normal algorithm problem.

But then comes the awkward part.

The bracket position is not simply “best third-place team goes here”

My first assumption was that the best third-placed team would go into one slot, the second-best into another slot, and so on.

That is not how it works.

The Round of 32 matchup depends on which groups the qualifying third-placed teams came from.

For example, if the qualifying third-placed teams come from groups:

["C", "D", "E", "F", "G", "I", "K", "L"]

that combination maps to one specific set of Round of 32 positions.

If the qualifying groups are:

["B", "D", "E", "F", "G", "I", "K", "L"]

that maps differently.

So the key is not only ranking the third-placed teams.

The key is identifying the set of groups they came from.

With 12 groups and 8 third-placed teams qualifying, the number of possible group combinations is:

C(12, 8) = 495

That means there are 495 possible sets of qualifying third-placed groups.

This is where the implementation stops being a clean formula and becomes a data problem.

Turning the qualified groups into a key

The simplest way I found to model this was to turn the list of qualifying third-place groups into a stable key.

function getThirdPlaceCombinationKey(teams: TeamStanding[]) {
  return teams
    .map(team => team.group)
    .sort()
    .join("");
}

So if the qualified third-placed teams came from groups C, D, E, F, G, I, K, and L, the key becomes:

"CDEFGIKL"

This key can then be used to look up the official mapping for the Round of 32.

const qualifiedThirds = rankThirdPlacedTeams(thirdPlacedTeams).slice(0, 8);

const combinationKey = getThirdPlaceCombinationKey(qualifiedThirds);

Now we can use that key to answer the real question:

Where does each third-placed team go in the bracket?

Representing the mapping as data

Instead of trying to derive the Round of 32 slots every time, I treated the official scenarios as a lookup table.

A simplified version looks like this:

type RoundOf32Slot =
  | "1A" | "1B" | "1D" | "1E"
  | "1G" | "1I" | "1K" | "1L";

type ThirdPlaceSource = `3${GroupId}`;

type ThirdPlaceMapping = Record<RoundOf32Slot, ThirdPlaceSource>;

const thirdPlaceSlotMap: Record<string, ThirdPlaceMapping> = {
  CDEFGIKL: {
    "1A": "3E",
    "1B": "3G",
    "1D": "3I",
    "1E": "3D",
    "1G": "3F",
    "1I": "3C",
    "1K": "3L",
    "1L": "3K",
  },

  BDEFGIKL: {
    "1A": "3E",
    "1B": "3G",
    "1D": "3I",
    "1E": "3D",
    "1G": "3F",
    "1I": "3B",
    "1K": "3L",
    "1L": "3K",
  },

  // ...493 more combinations
};

The exact values need to come from the official table, but the structure is the important part.

The code is not trying to be clever.

It is just making the official tournament rules usable inside an app.

Filling the actual teams into the bracket

Once the mapping is known, the rest is more mechanical.

For each Round of 32 slot, find the third-placed team from the mapped group.

function getThirdPlacedTeamFromGroup(
  qualifiedThirds: TeamStanding[],
  source: ThirdPlaceSource
) {
  const group = source.replace("3", "") as GroupId;

  return qualifiedThirds.find(team => team.group === group);
}

Then apply the mapping:

function resolveThirdPlaceSlots(
  qualifiedThirds: TeamStanding[],
  mapping: ThirdPlaceMapping
) {
  return Object.entries(mapping).map(([slot, source]) => {
    return {
      slot,
      source,
      team: getThirdPlacedTeamFromGroup(qualifiedThirds, source),
    };
  });
}

And the full flow becomes:

const qualifiedThirds = rankThirdPlacedTeams(thirdPlacedTeams).slice(0, 8);

const combinationKey = getThirdPlaceCombinationKey(qualifiedThirds);

const mapping = thirdPlaceSlotMap[combinationKey];

const resolvedSlots = resolveThirdPlaceSlots(qualifiedThirds, mapping);

At this point, the app can place the correct third-placed teams into the Round of 32.

What made this interesting

I usually prefer deriving things from rules instead of hardcoding large tables.

But this was a case where the table itself is part of the rule.

The bracket is not just:

sort teams → seed teams → generate matches

It is closer to:

sort teams → identify qualified groups → use official mapping → generate matches

That small difference changes the architecture.

The app needs both:

normal ranking logic
a predefined scenario table

That is what made this more interesting than a standard tournament bracket.

Why I did not want to hide all of this

From the user’s point of view, none of this should feel complicated.

They should be able to fill out groups, move into the knockout rounds, and understand what happened.

But from the developer’s point of view, the Round of 32 is doing quite a lot behind the scenes.

That also creates a UX question:

How much of this logic should be visible?

If you expose every rule, the page starts to feel like documentation.

If you hide everything, the bracket can feel random.

That balance was one of the harder parts of the project.

The working version

I used this logic in a small bracket predictor here:

https://bracket2026.com

The main goal was to make the new 48-team format easier to play with, especially the Round of 32.

Building it reminded me that some “simple” sports tools are not simple because the UI is complex.

They are complex because the real-world rules are strange.

And sometimes the cleanest code is not the cleverest algorithm.

Sometimes it is a boring lookup table that faithfully represents the rules.

References

Building a shift schedule generator taught me that scheduling is harder than it looks

Mark — Sat, 09 May 2026 14:15:20 +0000

I recently built a small tool called Shift Schedule Maker.

At first, I thought shift scheduling would be a fairly straightforward problem.

You have employees.
You have shifts.
You assign people to shifts.

That sounds like a simple table.

But once I started building it, I realized scheduling is less like filling out a calendar and more like solving a constraint problem.

A valid schedule is not necessarily a good schedule.

For example, the system has to think about things like:

Does every shift have enough people?
Is anyone assigned to two overlapping shifts?
Is someone working too many days in a row?
Are night shifts distributed fairly?
Are weekends always falling on the same person?
What happens when one person is unavailable?
Can the schedule still work if the team size is small?

The tricky part is that these rules often conflict with each other.

You might want perfect fairness, but still need full coverage.
You might want to respect everyone’s availability, but only have a limited number of people.
You might want a simple repeating pattern, but real-life exceptions break the pattern very quickly.

That made me think about scheduling differently.

Instead of treating it as a calendar UI problem, I started treating it as a constraint-solving problem.

Each shift becomes a slot that needs to be filled.
Each employee has limits, availability, and workload history.
Each rule adds pressure to the system.

Some rules are hard constraints:

A person cannot work two shifts at the same time.
A shift cannot be left uncovered.
An unavailable employee should not be assigned.

Other rules are softer:

Try to balance total working hours.
Try to distribute unpopular shifts.
Try to avoid too many consecutive workdays.
Try to keep the result understandable for a human manager.

That last part is easy to underestimate.

A schedule can be mathematically valid and still feel wrong.

For example, if one person gets all the night shifts, the algorithm might still satisfy coverage. But from a team perspective, the result is bad. So the goal is not just “generate something that works.” The goal is to generate something that feels reasonable.

Another challenge was templates.

Many industries already use known rotation patterns, like 12-hour shifts, 4-on/2-off, Pitman-style schedules, or 2-2-3 rotations. These patterns are useful because they give structure. But once you add employee availability or custom rules, the template becomes only the starting point.

So the product became a mix of two ideas:

Start with common scheduling patterns.
Adjust the actual result based on constraints and fairness rules.

I’m still improving the logic, especially around edge cases where the input is technically possible but very tight.

For example, if there are too few employees for too many required shifts, the system should not simply fail. It should explain what is making the schedule difficult.

That is probably the most interesting part of the project so far: not just generating the schedule, but helping people understand why a schedule is hard to generate.

I made the tool public here:

https://shiftschedulemaker.net/

It is still evolving, but building it has made me appreciate how much hidden complexity exists behind something as ordinary as a weekly shift calendar.

Curious if anyone here has worked on scheduling, constraint solving, workforce planning, or optimization problems.

How would you approach fairness in a scheduling system?

I built a World Cup 2026 bracket predictor for the new 48-team format

Mark — Thu, 07 May 2026 13:14:25 +0000

I built a World Cup 2026 bracket predictor for the new 48-team format

The 2026 FIFA World Cup format is surprisingly complicated.

Instead of the old 32-team structure, the tournament now has:

48 teams
12 groups
a new Round of 32
third-place qualification rules

I realized that most existing bracket tools were still based on the old format and felt awkward once you tried modeling the new tournament structure.

So I built this:

https://bracket2026.com

The idea was simple:

predict all group-stage standings
automatically generate the Round of 32
continue predicting all knockout rounds
share or export the completed bracket

One interesting challenge was handling the knockout path generation.

With 12 groups and third-place advancement, the Round of 32 is no longer fixed in a straightforward way. The bracket depends on which third-place teams qualify, so the UI and logic both become more dynamic compared to previous World Cups.

I also tried to keep the experience lightweight:

no signup
mobile friendly
fast interactions
easy sharing

It was a fun side project to build, especially because sports tournament structures are basically a weird mix of UI design, state management, and combinatorics.

Would love feedback from other developers or football fans — especially around the UX and whether the new format feels understandable.