Listening to Akira Yamaoka's Silent Hill 2 soundtrack while writing this.
The Idea
My uncle holds the Guinness World Record for the largest video game collection. When we'd talk about collecting, he kept coming back to the same problem: there's no good way to scan game listings and quickly figure out what's actually worth buying. You're eyeballing photos, cross-referencing prices in your head, guessing.
He wanted a tool that could look at a listing photo, detect which games are in it, pull up market values, and tell you if the price is good. So I built it.
That's GameScrape. You search eBay, the app uses computer vision to identify games in listing photos, pulls pricing data, and shows you what those games are actually worth. If something is priced well below market value, it flags it. You can set up scheduled searches so it watches for you automatically.
Why Now
I want out of this rat race. I've been a software engineer for 5+ years at a top 50 accounting firm. It's steady work and I've learned a ton, but watching rounds of layoffs hit my company made it clear that "steady" is relative. I'm still employed, but it was a wake up call. I want to build things I own.
GameScrape is my first real attempt at that. Whether it becomes a business or stays a side project, the skills I'm building (shipping a product, handling payments, marketing) are mine to keep.
One Codebase, No Framework
I gave myself 6 months. The single biggest decision I made was to not use a frontend framework. At work, I watched a project where the main API was done in about 5 months, and then we waited months for the frontend team to catch up. When the deadline came, the frontend was full of holes. I ended up learning React myself to fix issues that existed purely because the frontend devs didn't understand the product deeply enough. There was code doing backflips just to take a step forward.
The core issue wasn't the developers. It was the architecture. Splitting frontend and backend across teams multiplies communication overhead. API contracts, schema coordination, state management that balloons in complexity when both sides are liberal with their logic. Every extra layer of code is more surface area for bugs.
So for GameScrape, I went with Django and HTMX. One codebase. Server-side rendering. The backend is the single source of truth for state and logic. HTMX handles interactivity without the weight of a JavaScript framework. It's not the right choice for everything, but for a product like this, it's exactly right.
I also got to work with Django's built-in task system for background processing, Pydantic for structured AI agent interactions, and Stripe for payments. Coming from Celery and RabbitMQ at work, Django's task system felt refreshingly simple for this scale.
There are some drawbacks here however, although I was able to build much faster and cleaner without the frontend framework, at the end of the day I don't have a mobile app that I could advertise and sell on mobile app stores. However, building the API that I would need should be much faster as I could use a tool like Django Ninja or Django REST, if I ever want to try building in the future, particular if I would have customers who would be interested!
Lessons From Shipping
Cut scope ruthlessly. My uncle's original vision included auto-buying listings and reselling individual games. Cool idea, but way too much for a first version and honestly not the right market fit. Game collectors don't love flippers. I scoped it down to the core: find good deals, show market values, alert the user. That's it. Ship it.
Complexity is a choice. Every line of code you add increases the chance something breaks. It really is that simple. Before introducing a new tool, framework, or abstraction, ask yourself if the cost is worth it. Most of the time it's not.
Learn from other people's mistakes. A lot of what I know about building software came from watching things go wrong at work. Bad architecture decisions, over-engineered systems, communication breakdowns between teams. I'm grateful for all of it because it taught me what not to do. And when the opportunity came to fix those mistakes, I took it. That's how I learned React, how I understood state management pitfalls, and how I developed my own opinions on how software should be built.
What's Next
The app is live. No, it's not perfect, but the engineering is solid. Now comes the part I haven't done before: marketing. Building the thing was never where my skills fell short. Selling it? That's new territory. So here I am, writing my first blog post, figuring it out as I go.
If you collect games, give GameScrape a try. And if you're an engineer thinking about building your own thing, just start. You already know more than you think.