A tweet, an email and a forward, and what it told me about the company I was about to build everything on.

Early in the Durable Objects private beta, John Graham-Cumming, then Cloudflare's CTO, tweeted that he thought Durable Objects could be a good fit for a game. At pretty much exactly that moment I was thinking how I was going to shoehorn a poker game into a lambda function, or manage it as part of some sort of EC2 setup (with all the requisite issues with spot vs reserved pricing etc). We were already using Workers (which, as stateless edge functions are a lot easier to comprehend), but the realisation that a single game instance could be a single Durable Object seemed immediately obvious. I therefore replied that we were building exactly that. He asked me to send him an email with some details. I did. He forwarded it to Kenton Varda, the engineer behind Durable Objects, and within a few hours we were on the beta.

There are a couple of interesting lessons in that short sequence. While John was looking for examples, there was very little commercial logic in helping us. Given John's position as CTO at the time, and what Kenton has been responsible for building, to this day I'm slightly awestruck that I got that interaction at all. We were barely a Cloudflare customer at the time, and if every ambition I have for this company is met we will still be a rounding error in their revenue. They helped anyway. Part of why PokerStars was so well regarded by its players was that it was a company where caring about the customer experience mattered, and Mark and Isai Scheinberg understood that better than anyone in the industry, even past the point when they were unimaginably successful. I got the same vibes from Kenton and John, and it made a difference in the choice to use Durable Objects. At the time the product had a lot of rough edges. The documentation was limited and you had to learn a lot of new, often novel, concepts about how to work with them. The developer tools were practically a curl script. Even so, I persevered, because once you started using them you could see the potential, and when people you respect are behind something, you should listen. I'm glad I did.

The other lesson is about agency, and it took me longer to appreciate it than the technology. I replied to a tweet and sent an email. John read it and forwarded it. Kenton acted on it. Nobody asked permission, nobody scheduled a meeting, nobody routed it through a process. I was early enough in a start-up to still half believe that access of that sort required an introduction and a reason. One thing that you get from being a founder (or by reading the best business book of all time, Shoe Dog) is that a great deal of what happens is just people deciding to do stuff. A lot of entrepreneurial activity fails, but all actions generate information, and examples like that interaction with John were at least as useful in the long run as the beta access was.

A couple of years later, I had another interaction with John. In October 2022 I wrote a draft post about the decision to build on Workers and Durable Objects, and John generously agreed to read the draft and marked it up line by line in the style of a Cloudflare blog post. I'm sure almost everyone in tech will admit their admiration of the Cloudflare blog: it's well written, clear and informative. I know John was big on how posts should be written in terms of content and style (I think he used to recommend everyone read the book On Writing Well). Most of the suggestions John made to that draft were about writing. Cut the quotation and lead with the honest sentence instead. Explain the technology for a reader who is interested but does not already know what any of it is. Stop using acronyms. All of it was correct and, because you will never find an Oxford graduate who likes an essay covered in red ink, none of it was comfortable!

One comment was not about writing. In the draft I had said that the technical post about our use of Workers had already been written many times by other people and that I had nothing insightful to add. The system that is unpoker rivals is quite sophisticated and substantial, but I've always thought of it in terms of the individual units. A Worker handles the general aspects of the system which are stateless (like authentication requests, or purchases). A Durable Object class instance handles the matchmaking and queueing. Another Durable Object class instance has the game logic and is effectively the 'server' for a single game. None of it felt special enough in and of itself to justify a technical deep dive. He told me I was selling myself short, and that if this were the Cloudflare blog he would have sent me back to write that post. I never published the original, mostly because he was right about that, and I should have followed his advice earlier. Now we have a much more developed system, using many more Cloudflare Developer Platform features, I think I should repay John the courtesy he extended me, so the second post in this series is the post he told me to write, four years late.

So this series is in part a thank you to John (and Kenton). For giving a startup access to a beta program. For being willing to take some time to review a draft blog post. But, more than that, for showing that you can be at the top of one of the most successful tech companies of all time, yet still take time to help people earlier in their journey. I built the entire Unrational Games system on Cloudflare, and I am a shareholder. Partly because I think the technology is great (but just needs the right evangelists), but also because of interactions with the likes of John and Kenton (and the more, shall I say, mischievous tweeters - I'm looking at you, Sunil!).

Good people and good technology are a pretty powerful combination.

Philip Atkinson, CEO, September 2026