We The Players

We The Players started with a simple 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.

⸻

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 — not platforms, not popularity, and not 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.

⸻

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 explored 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.

A conscious decision was made 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.

⸻

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 an exploration of what not to build as what to build.

⸻

Although We The Players remained a concept-led product rather than a fully launched platform, it was a valuable and formative piece of work.

It reinforced how much community behaviour is shaped by structure, not just rules. It highlighted how 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.

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.

⸻

A side project should not cost like a funded startup, and this one did.

The original build was a perfectly reasonable piece of engineering for a team with a budget. The React app talked to two bespoke production API servers over GraphQL, with two matching staging servers behind them, a WebSocket endpoint for live updates, a dedicated image resize service, an object store and a CDN, and 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 concept project with no revenue and one person maintaining it in 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.

I want to be careful about the result, because I did not record the old hosting bill and I am not going to invent one. What I can say is what disappeared: two production API servers, two staging twins, 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 numbers I do have are about the artefact rather than the invoice. 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 500MB to roughly 150MB. The codebase moved to fully typed strict mode across 937 files, taking a type error baseline of over two thousand down to near zero. Two full audits since, one with 55 findings and one with 112, were worked through to completion.

Looking back, client side rendering was the wrong long term choice. A catalogue site lives or dies on search indexing, and shipping an empty shell to crawlers undermines that. I also did not finish deleting the old world: the content security policy still allows the retired API hosts, a legacy environment variable still sits in the configuration table, and the live robots file still points crawlers at the previous domain's sitemap. None of it is harmful, all of it is untidy, and one decommissioning pass at the end would have caught the lot. And I would have measured the before. The whole point of the exercise was cost, and the one number I cannot produce is the one that proves it worked.

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 sits at the intersection of games, community, and ethical product design — a space I continue to explore across my work. More than anything, it reflects a belief that good products don’t just scale behaviour; they shape it.