29 January 202614 min read

Raising the Dead: Bringing a long fallen platform back to life

Raising the Dead: Bringing a long fallen platform back to life

A gaming platform that cost £5,000/month fell under its own weight. Years later, it's been rebuilt from scratch as vgdb.co, with AI assistance and a radically simpler approach. This is a resurrection story.

The story of shuttering a beloved gaming community, walking away from everything, and then rebuilding it from scratch years later with a little help from an army of AI assistants and a drastically different approach to infrastructure.


The Original Dream

We The Players was born from a simple idea: gamers deserved a better place to talk about games. Not just review scores and hot takes, but thoughtful reviews, curated collections, shared screenshots, and genuine community. A place built by players, for players.

To bring this vision to life, we partnered with a genuinely excellent development agency. And I want to be absolutely clear about this: they did fantastic work. The platform they built was ambitious, feature-rich, and technically impressive. They approached the project with professionalism, creativity, and genuine enthusiasm for what we were trying to create.

The problem wasn't the quality of their work. The problem was what it cost to keep running.

When Success Becomes a Burden

The agency built us something sophisticated. Perhaps too sophisticated. They followed industry best practices of the time: microservices architecture, event-driven systems, machine learning recommendations. The kind of architecture you'd see at companies with teams of dozens and budgets to match.

The platform they delivered included:

  • A main GraphQL API handling core functionality
  • A separate leaderboard service for complex ranking calculations
  • A Java-based streaming pipeline using Apache Kafka for real-time event processing
  • Another Java service using Apache Flink for activity feed aggregation
  • A Python machine learning engine for game recommendations
  • Elasticsearch for search functionality
  • Two databases: PostgreSQL for the main data and MongoDB for leaderboard calculations
  • Redis handling caching, message brokering, and session storage
Eight separate codebases. Five programming languages. Enterprise-grade architecture for a passion project.

The monthly hosting bill? Over £5,000. Every single month.

For a well-funded startup with a clear path to revenue, this might have been manageable. For a community platform trying to find its footing? It was slowly bleeding us dry.

The Human Cost

Here's the part that doesn't make it into most technical post-mortems: the mental health toll.

Running a platform with this level of complexity isn't just expensive in pounds and pence. It's expensive in sleep. In weekends. In the constant, gnawing anxiety of knowing that at any moment, one of eight interconnected systems could fail, and you'd need to understand enough about Kafka consumer groups or Flink checkpointing to fix it.

Every alert at 3 AM. Every "the site is down" message from a community member. Every month watching a substantial chunk of money disappear into cloud infrastructure while you're still trying to figure out how to make the business sustainable.

The financial pressure was real, but the psychological weight was heavier. When your passion project becomes a source of dread, something has gone fundamentally wrong.

We made the difficult decision to shutter the business. Thank the community. Thank the investors who had believed in us. Power down the servers. Walk away.

We The Players went dark.

The Idea Wouldn't Die

Time passed. The servers stayed off. But the idea, that core vision of a community platform built for players, never quite left.

What changed was my perspective. And, crucially, what changed was the technology landscape.

During those intervening years, I watched the industry evolve. Managed services matured. Backend-as-a-service platforms like Supabase emerged and proved themselves. The tools available to solo developers in 2024 would have seemed like science fiction to the team building the original platform.

And then there was AI.

Not the vague, hype-cycle AI of marketing presentations, but practical, useful AI that could actually help write code. Tools that could serve as a tireless pair programmer, catching errors, suggesting approaches, and helping a single developer move at speeds that would previously have required a team.

A thought began to form: what if I could rebuild it? Not the old platform with its enterprise architecture, but the idea behind We The Players. The community features. The game reviews. The collections. The spirit of the thing.

What if I started from scratch, did it differently, and gave it a new identity? Not a continuation, but a resurrection under a new name: vgdb.co, the Video Game Database.

Starting From Zero (Literally)

I want to be crystal clear about something: this is not a migration. This is not an upgrade. This is not the old codebase with a fresh coat of paint.

I have not used a single line of code from the original platform.

What I've built is a complete reimagining, constructed from the ground up. Same vision. Same community focus. Entirely new implementation, entirely new name. Every component, every function, every line of code has been written fresh by me and my increasingly indispensable army of Claude AI assistants.

Here's the thing about AI and development that I've learned through this process: the magic isn't in replacing developers. It's in what happens when someone who genuinely understands software development works alongside AI tools. You need to know what questions to ask. You need to recognise when the AI has given you something brilliant versus something subtly wrong. You need the experience to architect systems properly and the judgement to know when a suggestion improves your code versus when it's just different.

AI doesn't replace the craft. It amplifies it. And when you've spent years learning that craft, the amplification is extraordinary.

The Old Architecture (A Respectful Autopsy)

Before we talk about what's new, let's examine what we were working with. Not to criticise, but to understand why rebuilding made more sense than renovating.

The original backend was built on Prisma version 1, an ORM that was genuinely innovative when it was chosen. The problem? Prisma completely rewrote their tool from scratch, abandoning version 1 entirely. The software running our database layer was essentially orphaned: no security updates, no bug fixes, no path forward.

The TypeScript version dated from 2019. In programming years, that's roughly equivalent to finding a VHS player in your entertainment centre. It still works, technically, but you're missing out on everything that's happened since.

The frontend used React 16 while the world had moved on to React 18. The state management relied on Apollo Client version 2, since replaced by a completely rewritten version 3. The build tools used Create React App, which Facebook itself has now officially deprecated.

And then there was the database schema: 23 separate Prisma schema files defining the relationships between games, users, reviews, collections, comments, and dozens of other entities. Understanding how they all connected required either original documentation (sparse) or the institutional knowledge of the original developers (unavailable).

This was all competent, professional work when it was created. Technology simply moved on, as it always does.

The New Philosophy: Radical Simplicity

The guiding principle of the rebuild can be summed up in one word: simplicity.

Not simplicity as in "fewer features." Simplicity as in "fewer moving parts." Simplicity as in "one person should be able to understand the entire system." Simplicity as in "the monthly hosting bill shouldn't require a second mortgage."

The centrepiece of this new approach is Supabase, an open-source backend-as-a-service platform built on PostgreSQL. Where the original architecture required eight separate services, Supabase consolidates almost everything into a single managed platform.

Authentication? Built in. Social logins with Google, Facebook, GitHub? A few lines of configuration.

Database? PostgreSQL with a clean web interface, automatic backups, and crucially, auto-generated TypeScript types that keep your code in sync with your schema.

Real-time features? Native WebSocket subscriptions, no Kafka required.

File storage? Included.

The complexity hasn't disappeared. It's been outsourced. Supabase employs teams of engineers whose entire job is making sure the authentication system is secure, the database is performant, and the real-time subscriptions don't fall over. My focus now becomes building features for the community, while being confident that the people over at Supabase continue to be amazing.

Building at the Speed of AI

Here's where things get interesting, and where this rebuild differs from any project I've worked on before.

Modern AI coding assistants have fundamentally changed what's possible for a solo developer. I'm not talking about generating boilerplate or autocompleting function names. I'm talking about genuine collaboration.

When I need to implement a complex database query, I describe what I want, and Claude helps me write it, often catching edge cases I hadn't considered. When I'm stuck on a tricky bit of React state management, I can rubber-duck debug with an AI that actually understands React. When I need to refactor a component and I'm not sure of the cleanest approach, I have a collaborative partner that's absorbed more programming knowledge than any single human could.

But here's what I want to emphasise: this only works because I know what I'm doing. I've spent years understanding how web applications work, how databases should be structured, how to think about user experience. The AI doesn't replace that knowledge. It builds on it. When Claude suggests an approach, I can evaluate whether it's right for this specific situation. When something feels off, I have the experience to know why and to push back.

The developers who built the original We The Players were skilled professionals. The agency that delivered that platform employed talented people who cared about their craft. What's changed isn't that developers are less necessary. What's changed is that a developer with the right tools can now accomplish what previously required a team. That's not a criticism of teams. It's a celebration of how far our tools have come.

The new codebase reflects this collaboration. It's cleaner than code I'd write alone, because I have a tireless reviewer catching inconsistencies. It's more robust, because potential bugs get flagged before they're committed. It's more modern, because my AI assistants are up-to-date on current best practices in ways that would require constant study for a human developer working solo.

Is it cheating? I don't think so. It's using the tools available. Developers have always used tools: IDEs, linters, frameworks, libraries written by others. AI assistants are just the latest tool in that lineage, albeit a remarkably powerful one.

The New Technical Stack

For those interested in the specifics, here's what vgdb.co runs on:

Build Tools & Runtime:

  • Vite instead of Create React App, with builds in milliseconds instead of minutes

  • Node.js 20+ with modern JavaScript features

  • TypeScript 5.9 with strict type checking


Frontend:
  • React 18 with concurrent rendering and Suspense

  • React Router v6 with lazy-loaded routes

  • TanStack React Query for server state management

  • SCSS modules for styling


Backend:
  • Supabase handling database, auth, storage, and real-time

  • PostgreSQL with auto-generated TypeScript types

  • Edge Functions for server-side logic when needed


Infrastructure:
  • Docker for consistent deployments

  • Express server for production with proper security headers

  • Sentry for error tracking (lazy-loaded to keep bundles small)


The entire application is code-split by route. Visit the home page, and you only download the code for the home page. Navigate to a game review, and that code loads on demand. The result is faster initial loads and a snappier experience throughout.

The Numbers Don't Lie

Let's talk about what matters: the monthly bill.

The difference between running eight separate services across multiple servers versus running a single Supabase instance with a modest usage tier is night and day.

This changes everything about what's sustainable. At £5,000 per month, We The Players needed to find £60,000 per year just to keep existing, before paying anyone, before marketing, before any other business expense. With the new architecture this cost is significantly reduced and the breathing room this creates is difficult to overstate. There's no ticking clock. No monthly panic about server bills. No pressure on how we're going to keep the lights on.

For the first time, vgdb.co can grow at its own pace.

What's Built, What's Coming

Let me be honest about where we are: this is a work in progress.

The core functionality is there. Users can browse games, write reviews, create collections, share screenshots. The authentication works. The database is solid. The foundation is complete.

But not everything from the original platform has been rebuilt. The leaderboard system exists but needs refinement. The recommendation engine, that Python machine learning service, hasn't been reimplemented yet. The admin tools for moderation are basic compared to what the original backoffice offered.

Some features might not come back at all. Some might be rebuilt differently. The beauty of starting fresh is the freedom to make those choices based on what the community actually needs, not what was built years ago under different assumptions.

This is a platform being built in public, iteration by iteration. It's messy. It's incomplete. It's also alive in a way that the old platform, for all its technical sophistication, never quite managed to be.

Lessons Learned (The Hard Way)

This journey has taught me things that I wish I'd understood years ago:

Complexity is a hidden tax. Every additional service, every extra database, every "we might need this for scale" decision compounds over time. The cognitive load of understanding a complex system is real, even if it doesn't show up on any invoice. Build the simplest thing that works. You can add complexity later if you actually need it.

Technology moves faster than projects. The original platform was built on best practices that became obsolete within years. This isn't anyone's fault. It's the nature of the industry. But it does mean that architectural decisions should favour tools that are simple enough to replace when the next wave arrives.

Managed services are worth it. The instinct to own your infrastructure, to run your own servers, to maintain complete control. I understand it. But when Supabase can provide authentication, database, storage, and real-time features with a team of experts maintaining it, the DIY approach stops making economic sense for most projects.

AI assistance is a genuine force multiplier. I was sceptical at first. Now I can't imagine building without it. A solo developer with good AI tools can move faster than a small team did five years ago. That's not hyperbole. It's been my lived experience building this platform.

Mental health matters more than metrics. A project that succeeds but destroys you in the process isn't really a success. Sustainability isn't just financial. It's personal. vgdb.co is built at a pace I can maintain, using tools that don't keep me up at night.

Looking Forward

The spirit of We The Players is alive again, reborn as vgdb.co.

Not the same platform. Not even close. But the same idea. The same hope that gamers deserve thoughtful spaces to discuss their hobby. The same belief that community can be built around shared passion rather than engagement metrics and rage-bait.

This time, it's built on a foundation I understand completely, because I wrote every line of it. It runs on infrastructure I can afford indefinitely, because I chose tools that make that possible. And it's being developed with assistance from AI that makes a solo project feel less solo.

The gaming community won't see most of this. They'll just see a platform that loads quickly, doesn't crash, and treats their contributions with respect. That's as it should be. Technology should be invisible when it's working well.

But for anyone who's ever shut down a project they loved because the costs, financial, emotional, temporal, became too high, this article is for you. It's possible to come back. It's possible to rebuild. And it's possible to do it in a way that doesn't break you.

The platform had fallen. I walked away. I came back.

Now it's risen again. And this time, I've built it to last.


vgdb.co is being built in the open, one feature at a time. The infrastructure is solid. The community is waiting. And somewhere in the cloud, a small army of AI assistants stands ready for the next coding session.

The resurrection continues.