Building Watt Fighters

01A fair race between a kid and a parent

Two riders on power meters race on a velodrome. One is a kid with a 120 W threshold power (FTP). The other is a parent at 340 W. Left alone, the stronger rider simply rides away, and the race is decided before it starts.

Watt Fighters adds a handicap that learns each rider. It measures a rider’s threshold and their sprint, and adjusts what their power is worth on the track, so the same race is close for both. The race comes down to who rides it better, not who has the bigger engine.

You only pedal. The game rides the line up and down the banking for you, so nobody has to steer a bike with a trainer and a keyboard at the same time. Racing on a velodrome is a question of power, timing and position, and those are the parts the rider controls.

The rules of the events did not start from a blank page. They started from the browser games my son Leo built about the sport: the match sprint, the elimination and the points race. Those are copied into the project as they are. The write-up on Leo’s site describes his games.

02Track racing, not road racing

Indoor cycling games are mostly road games: a long ride, a group, a sprint at the end. Track racing is different, and it is a sport with very few places to practise it. A track racer gets one elimination race every few weeks, on a real track, on the right night. In Watt Fighters they can ride three in an evening, and practise what wins races: the draft, the start, where to sit in the bunch, when to go, how to read a race, and the rules.

The events are the ones from the track programme:

• Match sprint, two riders, a game of position and nerve.
• Keirin, behind the derny, the small motorbike that sets the pace and pulls off before the sprint.
• Elimination, where the last rider across the line every other lap is out.
• Points race and scratch race, and the unknown distance race, where nobody is told how many laps are left.
• Time trial with a standing-start gate, and the flying 200 m.
• Open track, for riding with nobody to race.

That is nine events. A rider can race one, ride a tournament, or ride a session of races in a row, against bots or online. The bots attack, counter and sit in like real riders, because practising race craft against riders who only ride a line teaches nothing.

This is where my own background saved the most time. How the neutral lap is judged, what a keirin feels like when the derny pulls off, which gear a sprinter rides on a short track: I knew each answer, and it took one sentence to put it in the instructions. A team without a racer would have spent weeks reading rulebooks, and would still have missed how it feels.

03Physics a racer believes

A track racer notices when the physics are wrong, so the game puts the effort there:

• Speed from watts. What a rider pushes on the pedals decides how fast the rider goes.
• Drafting, tuned to team pursuit data, so sitting behind someone saves what it saves in real life.
• The bends. A rider needs a minimum speed to stay up on the banking: about 25 km/h at London.
• Gears. Track gears are fixed, so the game picks a gear per rider and event.
• Tiring and recovering, modelled with W′, the amount of work a rider can do above threshold before they are empty, and how it comes back.
• No swerving in the final straight. That is a rule in real sprints.
• Crashes, with a realism slider, so a young rider can turn them down.

One of the first bugs shows why this needs a racer. Bunch races start with a neutral lap, ridden together at an easy pace, and a rider who rides away or drops off gets a warning and then is disqualified. The first version judged it by position: the biggest group was the bunch, and anyone outside it was away. When a slow player held up the bots behind, the bots ahead were suddenly “off the front”, and 13 riders were disqualified in one call. A commissaire would not blame them. So the bunch became the first group riding the neutral pace, and only the rider who left a gap gets the blame. In 150 simulated neutral laps after that, no ordinary rider was ever warned.

0420 velodromes, drawn from their real designs

There are 20 velodromes in the game, drawn from their real designs: London, Marymoor, Burnaby, ’t Kuipke in Ghent, T-Town, Roubaix, the Vigorelli and more. Each has its own length, its own bends and its own banking, so the same event is a different race on each track.

Each has a crowd sized to the night, a race-night infield and ads on the fence boards. Five bikes ride in it with made-up names, such as the Sprocketti Zebra and the Zappington Eel. Riders can be a man, a woman or a girl, and a rider can have their own 3D rider, made from four photos.

05A voice for every race

A race with no sound is a rehearsal. Watt Fighters has a race announcer with four voices (British and American, a man and a woman) and about 4,000 recorded lines. The lines have excitement levels, so a bunch sprint sounds different from a lap behind the derny, and there are stories about the bots, so the announcer has something to say about the rider in front of you.

Recording is part of the deploy. Every deploy records any lines that are missing, so nobody has to remember to do it.

Coach Mac is a gruff coach with a voice of his own. He teaches race craft: where to sit, when to hold and when to go. A new rider gets the lesson a club coach would give, in the middle of the race, when it matters.

06Online, accounts and the apps

Online racing runs in rooms on Cloudflare Durable Objects. Accounts are on Supabase, with an email link, Google or Apple to sign in. There is a ladder from Cat 5 to Pro with standings. A finished race can be watched again as a replay, and exported as an MP4 for Instagram. Rides can be uploaded to Strava, and the trainer’s resistance can be controlled by the game.

The game is one codebase, with only a thin platform layer for each app, and a test enforces that thinness. It runs on the web, in Chrome and Edge, as a Windows app, as an Android app, and as an iPhone and iPad app in TestFlight. If a rule about racing lived in the Windows app, the iPhone app would be wrong the next day. The test makes sure the platform layer stays a layer.

An Apple TV app is planned for the App Store by 14 November 2026.

07The business around it

A game that people pay for needs more than a game. Around Watt Fighters there are:

• An admin site with 17 tabs. Every table exports to Excel: cost per player, service limits, deploys, feedback.
• An ads site where Claude checks every ad before it runs.
• A clubs site and a press kit.
• A support assistant that knows the game.

The game is free in open beta until at least the end of January 2027. After that it costs $9 a month.

08How it was built: many sessions, one set of rules

Several Claude Code sessions ran at once on the same codebase. Left alone, sessions working at the same time on the same files would break each other all day. What kept them apart was a set of rules, written down once, and read by every session before it starts.

The rules file, CLAUDE.md, says how every session works:

• Ship without asking. Commit, push, migrate the databases and deploy. No session waits for me to say yes.
• Plain words in every line a player reads, so a kid on the bike understands it.
• Made-up bike names only. No session invents a real brand.
• Every screen built the same way, so the game feels like one game.
• Changes go live first and into the labs only when I ask, so work does not hide in a side room.
• Docs updated in the same commit. This is how sessions learn from each other: the next session reads what the last one changed, in the place it will look.

Two more rules keep sessions from breaking each other. Each session commits only its own changes, so it never commits another session’s half-done work by accident. And the deploy runs from a clean copy of the code, not from the folder a session is working in, so nobody’s unfinished work goes live.

A memory keeps my decisions across sessions. When I decide something once, such as how a screen looks or what a word means, it is written down, and a session that starts tomorrow already knows.

There are also twelve lab pages. A lab lets me try a change before it reaches the real races. By the rules, changes go live first, and into the labs only when I ask for it.

The rules file is the contract. Every session reads it first, so many sessions behave like one team.

09What the AI got wrong, and how it was caught

The AI says “done” with the same confidence when it is wrong. These are four cases, and none was found by the AI’s own report:

• The rider in a green test suit. The rider exported for the Apple TV test wore the 3D models’ green test suit. The kit was painted by a shader, and a shader cannot be carried inside a model file. The export did not know that, and no error was raised.
• Backs that sagged. Riders’ backs dipped in the middle where a cyclist’s back rounds. It looked fine at a glance and wrong to anyone who has ridden a track bike.
• Bots disqualified in the neutral lap, because judging went by position, as in section 03.
• Invisible riders. In the Unity test, the riders were not drawn. Only their shadows were.

Each was found by a test, or by looking at a close-up screenshot. That is why every 3D change gets a close-up, and why the deploy runs the tests. A test does not get tired and does not say “looks good.”

10The estimate, and its limits

How much work is this, for a conventional team? There are two ways to guess.

By lines of code, the project is about 197,000 lines, which a team would need 15 to 50 person-years to write. The range is wide because lines of code are a poor measure of work.

Feature by feature is better. Adding up the features, I get about 600 person-weeks to build, and 800 to 900 with design, management and testing. That is roughly 15 to 18 person-years, or a team of 15 to 20 for about a year. The headline figure of about 15 person-years is the low end of that.

It is a model, not a measurement, and it has two limits. Code written by AI is longer than a careful person’s, so the line count flatters the amount of work. And a team’s estimate includes hardening: real players, real load and real bugs from the field. That has not happened here yet.

11Best practices

1. Write the rules down once, and make every session read them. A rules file is cheaper than a meeting.
2. Let the expert decide fast. One sentence from someone who has raced beats a week of research.
3. Ship without approval gates, but behind tests. Speed comes from not waiting for people. Safety comes from a deploy that stops when a test fails.
4. One shared platform layer instead of a copy per app. Keep it thin, and test that it stays thin.
5. Docs are how sessions learn from each other. Update them in the same change as the code.
6. Look close up before calling visual work done. The AI’s “done” is not a check.

12What’s next

Several things are not proven yet, and I would rather say so than let a count of commits stand in for them:

• Real players, at scale. The game works. How it holds up with many riders racing at once, on many kinds of computer and phone, is still to be seen.
• Trainer resistance on a real trainer. The control is built; it has to be proven on the trainers people really own.
• The Android app in Google Play.
• The Apple TV app. It is a Unity app that draws the online race, and it has to be tested against Apple’s RealityKit on a real Apple TV.

After that, I will contact velodromes in the US whose own track is already in the game, about a winter league.