MyTourneyTime — Building a World Cup Product with AI

MyTourneyTime started with a simple problem.

A few months before the 2026 World Cup, a colleague and I were trying to work out when England might play in the knockout stages depending on where they finished in their group.

I thought there should be a simple tool that answered that question.

At the time, I had virtually no development experience. I had followed one beginner coding tutorial in VS Code, but concepts such as Next.js, APIs, deployment and GitHub were all largely unfamiliar.

The original plan was modest: build a tool called Route ’26, and use it as a way to learn how far I could get with AI-assisted development.

It eventually became a much larger project.

Learning by building something real

My early workflow was fairly naive.

I would discuss an idea with an LLM, work towards a large implementation prompt, have another model critique it, and then give the resulting task to the Abacus AI Deep Agent.

Nothing really wrong with any of that.

But initially, I was asking the agent to solve far too much at once.

Route ’26 looked promising quite quickly, but as I tested it more closely I kept finding problems: incorrect dates, missing routes, mistakes in tournament progression and inconsistencies in the underlying data.

I spent time manually fixing individual issues before realising that I was patching a bad foundation.

That became one of the most important lessons of the project.

Instead of continuing to prompt around the errors, I stepped backwards and created a structured World Cup source of truth covering fixtures, venues, kickoff times and progression through the tournament.

The expanded 48-team format made third-place qualification particularly complicated, so I manually mapped the possible routes those teams could take through the knockout rounds.

Solving problems rather than endlessly prompting

There were plenty of smaller lessons too.

At one stage an agent attempted to recreate country flags itself using images it found online. I burned through a large number of tokens before discovering that a flag CDN already solved the problem cleanly.

Timezone handling caused another set of headaches, particularly matches around midnight appearing against the wrong date. I eventually simplified the system by using a consistent reference timezone and converting from there.

Those experiences changed how I approached AI-assisted development.

Rather than assuming a better prompt would solve everything, I became more likely to ask:

• Is the underlying data correct?
• Is this task too large?
• Is there already a library or established solution?
• Can I simplify the problem first?
• What context does the agent need before it starts?

The cost of getting this wrong was sometimes literal. During one month of the early build I spent around £120 on additional AI credits, largely because I was allowing a heavyweight agent to tackle poorly scoped jobs and repeatedly correct its own mistakes.

That made efficient task design much less theoretical.

From Route ’26 to MyTourneyTime

Route ’26 took roughly three months of spare-time work, anywhere from 5 to 20 hours per week! (Which is madness for how big it is! But in my defence, it was a fairly complex route calculator that also reflected your timezone. I bit off a little too much tbf!)

By the time it was live, I had, bizzarely enough, enjoyed the process enough that I wanted to keep building.

The project grew into MyTourneyTime, a wider World Cup platform containing tournament tools, editorial content and interactive features.

I moved from Abacus AI to a workflow centred on ChatGPT and Codex, and my way of working became much more structured. That's not a criticism of the abacus agent, it was really good, but I'd learnt a lot from that initial build.

Repository context and Markdown guidance became increasingly important. Instead of expecting a coding agent to rediscover the project every time, I started documenting how the site worked, which areas were fragile, (i.e. "Don't you dare touch the fixture database!"), and how new work should fit into the existing product.

I also became much more deliberate about design.

An early version of the quiz tool looked functional but generic and overly AI-generated. Later features started with much clearer visual direction. I would work through the intended experience first, generate reference imagery where useful, add those assets to the repository and give the coding agent both the visual target and the written context.

As the site matured, existing components also became useful references. New tools could reuse established navigation, layout and interaction patterns rather than starting from scratch each time.

Later features

The Tournament Predictor was one of the more ambitious additions, combining tournament logic with animated progression through the competition.

A feature piece I was happy with technically was an interactive climate-routes article.

It compared the climate demands of different possible knockout routes and included numerous interactive visualisation rather than presenting the subject as a conventional article. The analysis highlighted how favourable Spain's possible route could be from a climate perspective — Spain subsequently won the tournament.

My favourite example of how much my workflow had improved, though, was the World Cup Sweepstake Tracker.

It was the final tool I made for the site and included a scoring engine, team pairings, leaderboard, results handling and a polished responsive interface.

I built the complete feature in roughly 12 hours.

That contrasted sharply with the months required for Route ’26.

A real audience

I also wanted MyTourneyTime to teach me what happened after something was deployed.

I set up Google Analytics, Search Console, metadata, sitemap generation, indexing, keyword-focused content and internal linking, learning the basics of SEO as I went.

I never seriously promoted the site through social media.

Despite that, between 1 June and 1 July 2026, MyTourneyTime recorded approximately:

Traffic came from users around the world.

In the grand scheme of things it's nothing special, but for a first attempt I was happy with it.

One of the more interesting discoveries was that the Sweepstake Tracker became particularly useful for organic discovery. Major football publishers naturally dominated broad World Cup searches, but office sweepstakes were a more specific problem with less competition.

A tool I had originally built partly because I wanted one myself for the work sweepstake, ended up bringing people into the wider site.

What I learned

The commercial return on the project was not the point.

The World Cup gave the product a natural lifespan, and I deliberately chose not to invest heavily in promotion knowing that the subject itself had an expiry date.

The value was what happened between starting and finishing.

I began with almost no coding experience and little understanding of Git, deployment, repositories or modern web development.

The biggest lesson was not a particular framework or programming language.

It was learning how to work with AI without simply handing responsibility over to it.

Better results came from better data, smaller problems, clearer context, more deliberate design and careful testing.

And the thing I'm proudest of is probably persistence.

There were many points during the original Route ’26 build where it would have been easy to decide that the errors, tournament logic or tooling were simply beyond me.

Getting that first tool live changed my confidence in what I could build.

Everything that followed came from continuing to ask how I could do the next version better.