I Shipped a Finished Site Nobody Could Find

The Traitors: New Blood premieres on 17 September, and I built a fantasy league for it. You draft a team from the castle, the platform scores every banishment and murder, and at the end of the season you find out whether you actually read the game or just enjoyed it.

This is the third of these. SurvivorTribes came first, then BBFantasy, and this one is a fork of BBFantasy. So the interesting question going in was not "can I build it" but "what does a fork actually cost."

The rename was cheap. The correctness was not.

Forking a working app feels like it should be mostly find-and-replace, and the find-and-replace part genuinely was. What it did not cover:

• A database constraint still pinned to the old show's rooms, which rejected every insert for the new one.
• Colour tokens carrying the parent's theme, forty-two arbitrary hex values deep.
• Season constants hardcoded in places that only fire on a broadcast night, so nothing failed until a rehearsal.
• A running-totals chart that had inherited a defect from the original that nobody had noticed in the original either. It drew a headshot at every episode for every player, which at seventeen players across twenty-seven episodes is four hundred portraits stacked over the lines they were supposed to annotate.

That last one is the one I keep thinking about, because fixing it meant fixing it three times. The same component had drifted into three versions with a shared ancestor, and the differences were the kind that break a blind copy silently rather than loudly: one of the three has no baseline row in its chart data, so an index offset that is correct in two of them lands a face one episode off in the third, with nothing failing and no test noticing.

Three apps in three repos with no shared package means "build once" is really "copy carefully and note where the original lives." That is fine at three. It would not be fine at four, and now I know roughly what the fourth would cost.

The part I got wrong

Here is the actual lesson, and it is not a flattering one.

Nine days before premiere, the site was finished and good. Every route prerendered with a real title, a real meta description, a real <h1> and structured data. Cast pages carrying original research: what each player said about themselves before filming, who else asked for the same side, how the castle's ages and trades stack up. A sitemap of 168 URLs, all returning 200. Security headers, a passing accessibility bar, sub-second loads, a payment path proven with a real charge, eighteen backend functions deployed.

And if you searched for a Traitors fantasy league, you got four competitors and not me.

I had built the thing and shipped the thing and confused that with people being able to find the thing. Built, indexed, and linked-to are three separate claims, and I had earned exactly one of them. Search Console was not set up until four days before premiere. Analytics had no measurement id. And the part no configuration fixes: nothing on the web pointed at the site. Google's own guidance is blunt about this. Most pages are found because something links to them. A sitemap tells a crawler what exists on a site it already knows about; it does not tell anyone the site exists.

The uncomfortable version of this is that the technical excellence was partly the problem. Prerendering, structured data, keyword-mapped slugs, a clean Lighthouse run: all of it is legible work with a clear finish line, and all of it can be done alone. Distribution is none of those things. So the backlog quietly filled with the work that felt like progress, and the actual constraint sat unticketed until someone went looking for it.

What I would do differently, in order

1. Set up Search Console and analytics on day one, before the first commit. They take under an hour combined and they have days of lead time. Doing them last means the launch spike lands on a site the index has never seen.
2. Put a "who links to this" line in the roadmap next to the features. If it has no owner and no ticket, it is not a plan, it is a hope.
3. Check for the constraint outside the codebase. Every failure on this project that actually mattered lived in a dashboard, a DNS record, or a decision, and none of them could be caught by a test. A repo is very good at telling you about itself and completely silent about whether anyone has heard of it.
4. Distinguish a credential from a decision. Half the things filed as blocked were two commands somebody could have run. The other half looked identical and were genuinely somebody's call. Filing them in one bucket meant both halves waited.

The site is good. That was never the hard part, and I think I knew that and built the easy thing anyway. The remaining work on this project is not a feature.

If you watch The Traitors and want somewhere to put your theory about who is lying, it is at playtraitorsfantasy.com. Members play free; only the person running the league pays.