← Back

Some notes on how I made Cross Your Friends

In January 2026, I was in a group chat with a bunch of friends and we’d send each other our completion times for the NYT daily crosswords. I sent a message one day: “If I made a little site where you could send tricky crossword puzzles to your friends, would you use it?” The answer was yes, so I fired up Codex with GPT 5.1 and got to work.

As far as I can tell, this filled a gap in the “market” because other tools don’t really let you create and try to fill in a grid. If you’ve ever tried to make a crossword grid by hand, you’ll know it requires a pretty exhaustive search through all the combinations of words in your dictionary, and it’s very easy to write yourself into a corner and have to do a lot of backtracking.

Now we can let the machine do that.

I don’t really know how to write a development blog for Cross Your Friends. From one perspective, I spent many dozens of hours on it over the last six months, and I refined and tested every aspect of it. From another, all of this was specified in plain English, sometimes in diagrams, to something else that wrote and tested the code for me. This was more or less “dark factory” vibecoding, where I didn’t inspect the code at all, just did iteration after iteration of asking different agents to do so.

I went down a lot of dead ends in terms of development, too. The biggest one is that until about May 2026, the solver engine was server-side, and it was much slower and would time out regularly. I drafted a whole payment/credits system where I could hopefully ask heavy users to buy credits to generate more puzzles, appealing to them by saying the server cost several dollars a day to host and run. I was not optimistic about this.

Looking back, that might seem silly or naive, but remember - there was nothing like this already made, and from what I could see with my testing, the ability to make a puzzle in a single second while looking through a dictionary of 100,000+ words really did need a parallel CPU backend. I think this is a serious risk when trying to vibe code real, enjoyable, performant software. You might be convinced by some very impressive metrics that you’re on the right path.

But with Codex as my guide, I decided one day to benchmark on-device solving, and … it was faster on my slowest phone than on my MacBook. It had written an on-device solver that was significantly more efficient, and used a smaller dictionary to boot, without impacting puzzle quality. That knowledge makes me even happier that I don’t need to pay for a powerful server on the back end, and I can happily remove any semblance of a paywall. Nobody wants to pay for this kind of thing. From there, all I had to really do was make the UI as good as it could be and make sure there was a large and high-quality word bank for the solver to pull from.

The whole time, I’ve been acutely aware that once this is made, anyone else could do it much, much faster by just asking their agent to clone the site. Everything you need to launch this by yourself is already downloaded to your browser; there’s nothing of real consequence server-side.

You see, in writing this development blog I feel somehow that I need to justify being proud of this. What I’m most proud of is the time I spent refining it to be as intuitive and usable as possible, and I’m weighing that sense of satisfaction against what I might feel if someone else did the same thing but better.

Ah well. Better that happens than I never release anything, right? Enjoy.