Skip to content

Case Study

We The Players

We The Players

Overview

I founded We The Players in November 2018. The pitch was simple: a Letterboxd for games, a place to log what you play, rate and review it, build collections and find people who share your taste. It was funded by me and a group of angel investors I trusted, built by two agencies, launched, and ran until 2023.

It started with a frustration I'd felt for years as a player. I love video games, but I've never really loved the places we talk about them.

Over time, most gaming discussion had ended up in the same handful of spaces: sprawling Reddit threads, chaotic Discord servers, or social feeds optimised for outrage rather than enthusiasm. Conversations moved fast, disappeared quickly, and were often dominated by the loudest voices rather than the most thoughtful ones. If you were a casual player, an older gamer, or someone who just wanted to talk about why a game resonated with you, it was surprisingly hard to find a space that felt welcoming.

Despite gaming being one of the most social mediums in the world, the communities around it often felt fragmented, hostile, or exhausting.

That tension became the starting point for We The Players.

The Question

Instead of asking "How do we build another gaming social app?", I reframed the challenge as something more human:

What would a video game community look like if it was designed around players first, rather than platforms, popularity or engagement metrics?

I wasn't interested in replacing Reddit or Discord. They do what they do very well. What interested me was the gap between those platforms and how many players actually want to engage: calmly, thoughtfully, and around shared taste rather than competition or clout.

The idea behind We The Players was to create a space that felt closer to a good local games café than a global shouting match.

Shaping the Vision

From the beginning, the product was driven by identity and belonging rather than scale.

Instead of defining users by follower counts or activity levels, We The Players treated profiles as expressions of taste. The games you play, the genres you love, the platforms you use, and the way you like to engage were treated as signals of identity rather than stats to optimise. The goal was for someone to look at a profile and immediately understand what kind of player that person was, without needing numbers to validate it.

Communities were designed around games and shared interests, not endless feeds. A single-player narrative fan and a competitive multiplayer grinder could both exist in the same ecosystem without being forced into the same behavioural patterns. The emphasis was always on discussion, reflection, and shared enthusiasm, rather than speed or volume.

We made a conscious decision to avoid many of the mechanics that dominate modern social platforms. There were no obvious attempts to manufacture engagement through outrage, no aggressive gamification layered on top of conversation, and no sense that the product was trying to "hack" user behaviour. If people were going to show up, it needed to be because the space felt worth showing up to.

Designing the Experience

A lot of the work on We The Players lived in the subtleties.

The interface aimed to feel calm and considered, deliberately stepping away from visual noise and infinite-scroll anxiety. Conversations were given room to breathe. Discovery was designed to feel personal and intentional, guided by what players cared about rather than what was trending that hour.

Moderation and tone weren't treated as afterthoughts or policy documents, but as part of the product itself. The structure of communities, the way posts were surfaced, and how interactions unfolded were all designed to encourage good behaviour by default, rather than relying on heavy-handed enforcement when things went wrong.

One of the most interesting challenges was resisting the urge to copy patterns that are "known to work". As a product designer, it's uncomfortable to intentionally leave growth mechanics on the table, but that discomfort was part of the point. We The Players was as much about what not to build as what to build.

What I Learned

Building and running We The Players was the most formative work I've done.

It reinforced how much community behaviour is shaped by structure, not just rules. It showed me that identity-led discovery feels more human than algorithmic feeds. And it confirmed a long-held belief that gamers don't want more places to talk: they want better ones.

It also taught me the hardest lesson a founder can learn. A product can be well designed and well built and still cost more to run than the business can sustain. The platform our agencies built was sophisticated, and hosting it cost between £4,000 and £12,000 a month, more during large data ingests. Across its life the company spent nearly £400,000. In 2023 I closed it.

Perhaps most importantly, it strengthened my conviction that product design always carries values, whether they're stated or not. Choosing calm over chaos, depth over speed, and belonging over virality are design decisions, not accidents.

Re-platforming and running costs

Closing the company did not mean I wanted the product to disappear. But one person cannot keep paying what a funded startup paid to host it.

The original build was a perfectly reasonable piece of engineering for a team with a budget. Behind the React app sat an AWS estate: two bespoke production API servers over GraphQL with two matching staging servers, Kafka and Flink for event streaming and feed aggregation, Elasticsearch for search, a WebSocket endpoint for live updates, a dedicated image resize service, an object store and a CDN. In the browser sat a client-side stack that included error tracking, session replay, heatmaps, two analytics vendors and a CRM integration called straight from the browser. Every one of those pieces was something to pay for, patch and monitor.

That is a sensible shape when there is a team and a roadmap. It is an indefensible shape for a product with no revenue and one person maintaining it in the evenings. I had two honest options: switch it off and let the idea die as a set of screenshots, or work out how to run exactly the same product for close to nothing. The interesting question was never whether it could be done cheaply. It was whether it could be done cheaply without quietly degrading the product into a demo.

The constraint that shaped everything was that the product had to survive intact. This was not greenfield. It was an existing site with around thirty page routes, hundreds of components, over four hundred bespoke stylesheets and a full custom design system. Reviews, ratings, collections, media uploads, follows, kudos, comments, notifications, leaderboards and a six-step onboarding flow all had to keep working. A migration that shipped a thinner product would have proved nothing. The data had to survive too, because a games platform with an empty catalogue is not a platform.

A managed backend also cannot do everything a bespoke server can. There is no place to put arbitrary application code, no long-running processes, no custom middleware. Anything the API servers used to do had to be re-expressed as a database function, a security policy, a scheduled edge function, or work the browser could safely do itself.

So I worked in order. I modelled the target schema in Postgres first, with foreign keys, indexes, triggers and row-level security from the start rather than bolted on later. I backfilled the catalogue from the games API in batches of five hundred, resolving platforms, genres, companies and franchises to real rows and handling downloadable content as children of their parent games. Then I replaced the data layer one query at a time behind the existing interface, so every step was invisible to anyone using the site. Only when nothing pointed at the old world did I delete it: the entire GraphQL client directory, sixteen packages, and every wrapper component that carried an API client, followed by a sweep for the orphaned files the migration left behind. With the data layer settled I moved the toolchain forward, from Create React App to Vite, from JavaScript to TypeScript in strict mode, and out of the component library entirely in favour of the design system that already existed.

What replaced the servers is deliberately small. Heavy work became database functions: fuzzy matching and full-text search with relevance ranking, filtered and paginated search, activity feeds, platform-exclusive rankings. Anything needing a secret became one of eleven small edge functions: catalogue sync, leaderboard calculation, sitemap generation, upload validation, notification delivery, login by username. Counters, slugs, follower totals and average ratings moved into database triggers instead of application code. Game artwork is hotlinked from the games database CDN by hash, so the single largest category of image traffic on a games catalogue costs nothing to serve. The whole front end now ships as one container serving static files and nothing else, with a nonce-based content security policy, compression, rate limiting and a health endpoint. It has no API routes at all, and a one-kilobyte request body limit to prove it.

The old platform cost between £4,000 and £12,000 a month to host. What disappeared: two production API servers, two staging twins, the Kafka and Flink pipelines, Elasticsearch, a WebSocket service, an image resize service, an object store and a CDN in the hot path, a CRM integration and three separate analytics and session replay vendors. What replaced them is one managed database and one small container on a server I already pay for.

The other numbers are about the artefact. The main bundle dropped from 316 KB to 232 KB gzipped and the application chunk from 793 KB to 433 KB. The production image came down from roughly 500 MB to roughly 150 MB. The codebase moved to fully typed strict mode across 937 files, taking a type error baseline of over two thousand down to 35. Two full audits have followed: all 112 findings from the second were fixed the same day, and 51 of the 55 from the first are closed.

What I'd change

I'd move off client-side rendering. A catalogue site lives or dies on search indexing, and shipping an empty shell to crawlers undermines that.

I'd finish the decommissioning in one deliberate pass. The content security policy still allows the retired API hosts, a legacy environment variable still sits in the configuration table, and the robots file still points crawlers at the previous domain's sitemap. None of it is harmful, all of it is untidy, and a final checklist would have caught the lot.

And I'd track the new running cost from day one. I know what the old platform cost to host; I should be able to show the new figure to the pound, not just the shape of the saving.

Why It Belongs in My Portfolio

We The Players represents how I like to approach product problems: starting from human frustration, questioning default patterns, and designing with intent rather than assumption. It is also the project where I carried the whole weight of a funded company, from the pitch to the decision to close it.

It sits at the intersection of games, community, and ethical product design, a space I continue to explore across my work, most recently in VGDB. More than anything, it reflects a belief that good products don't just scale behaviour; they shape it.