DEV Community

Cover image for I Built an EPL Match Prediction Service Solo with Claude Code (and I'm Not Really a Frontend Dev)
chic.alors93
chic.alors93

Posted on

I Built an EPL Match Prediction Service Solo with Claude Code (and I'm Not Really a Frontend Dev)

I'm a backend-leaning developer working at an ed-tech company in Korea. I wanted to build something on the side — a football prediction service for the English Premier League. The problem? I hate writing CSS. I'm slow at React. And I had maybe 2–3 hours a week to work on it.

So I leaned fully into vibe coding with Claude Code. Here's what happened.


What I Built

XKick is an AI-powered EPL match prediction service. Every matchday, it:

  • Pulls live match data from the API-Football / AllFootball APIs
  • Runs a prediction model based on recent form, lineup data, player grades, and historical stats
  • Generates match insights and predicted lineups
  • Shows win probabilities for each fixture

The stack: FastAPI + PostgreSQL on the backend, Next.js on the frontend. Deployed on a VPS. Built almost entirely through Claude Code sessions.


My Workflow

I run everything inside cmux (a terminal multiplexer) with tmux panes. One pane for Claude Code, one for the dev server, one for logs.

My typical session looks like this:

  1. Open Claude Code in a tmux pane
  2. Describe what I want: "Add a data pipeline that syncs player grades after each matchday and stores them in the lineup_predictions table"
  3. Claude writes the code, runs tests, fixes errors
  4. I review the diff and either approve or tweak the prompt

That's basically it. I'm not writing code from scratch — I'm directing.


The Part That Surprised Me

The biggest win wasn't speed. It was data integrity.

At one point I had a nasty bug: mixed fixture IDs from two different data sources (FD and AF) were colliding in my matches table. Predictions were running against the wrong matches. Six thousand rows of bad data.

I described the problem to Claude Code. It:

  • Diagnosed the root cause (ID namespace collision)
  • Wrote a full reset pipeline (full_reset_af.py) — 11 steps covering schema reset, team/match import, player sync, events, lineups, grades, simulation, insights, translation, prediction evaluation, params rebuild, and lineup prediction backfill
  • Ran the whole thing and verified row counts at each step

That would have taken me a full weekend alone. With Claude Code, it took one session.


What Claude Code Is (and Isn't)

It's not magic. You still need to:

  • Understand the architecture well enough to describe what you want
  • Review every diff — Claude makes mistakes, especially with complex joins or multi-step transactions
  • Know when something is overcomplicated and push back

What it removes: the friction of translating intent into boilerplate. The "I know what this should do but I don't want to write the migration" problem. That's gone.


The Honest Numbers

  • Time to MVP: ~3 weeks of evenings and weekends
  • Lines of code written by hand: maybe 5%
  • Bugs introduced by Claude: yes, several — but it also fixed most of them
  • Would I do it again: absolutely

Try It

If you're into EPL, check out xkick.app before the next matchday. Predictions go up a day before kickoff.

And if you're a developer curious about vibe coding as a real workflow (not just a demo), happy to answer questions in the comments.


Tags: claudecode, ai, sideproject, webdev, football


P.S. This article was also written by Claude. Vibe coding goes all the way down.

Top comments (0)