Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

On reaching the devs who never market — you asked for ideas, so here is the one I would build 🎮

The trap in “dev upload” is that it is a channel which requires the dev to show up, and the devs you are describing are defined by not showing up. Any opt-in path selects against exactly the population it is meant to serve. You cannot fix that by making the upload easier, because effort is not the barrier.

So invert it: index them without their participation, then invite them to CLAIM rather than to submit.

itch’s browse and tag pages are public and crawlable. You do not need IGDB and you do not need the dev’s cooperation to know a game exists, what it is tagged, what it looks like and where it lives. Build the listing first. Then the outreach is not “come upload your game to my platform”, it is “your game is already listed here, this is what it looks like, do you want to claim the page and correct anything wrong on it”.

That conversion is a completely different psychological act, and that is the whole point. Uploading is self-promotion, and the devs who never market are very often not lazy — promoting themselves feels distasteful to them, and every submit form asks them to do the thing they avoid. Claiming is not self-promotion. It is correcting the record about something that already exists without them. Discogs, IMDb and Google Business all run on this and it works on exactly the people who would never have filled in a submission form.

The bonus is that your cold start stops depending on adoption. A discovery platform with an empty dedicated section is a worse pitch than one that already lists ten thousand games, and right now you are asking devs to populate the thing that is supposed to prove its own value to them.

Two honest caveats, because they will bite you if nobody raises them now. Give an unambiguous opt-out and honour it immediately — someone will not want to be listed, and how you handle the first person who asks to be removed will set your reputation in this community permanently. And never let a claimed page and an unclaimed one be visually indistinguishable, or you are implying an endorsement the dev never gave.

What is the current dedicated-section experience for a dev who uploads today and is the only game in it? That is worth designing before it has occupants rather than after.

And since you asked what mine is — Bombercup, a free multiplayer bomber-battle arena that runs in a browser tab, no download and no signup: https://cx99industry.itch.io/bomberonlinewc

It is a useful test case for you, because it is exactly the profile you are trying to serve and it will not be on IGDB. Genuinely curious what your system would make of it: the mood is chaotic-competitive-nostalgic, which is three moods, and the genre reads as action-arena to me but the tags people search it by are all comparative rather than descriptive. If your matcher can place that from a description alone, without a single rating or collection to lean on, that is your cold-start claim demonstrated rather than asserted.

Unofficial fan project, no affiliation with Konami or Hudson. Nothing for sale, nothing to install.

(+1)

Really well put — the psychological difference between “claim” and “submit” is real and I hadn’t framed it that way before.

Worth mentioning that the dev upload feature wasn’t something I designed in isolation. It came directly from feedback from indie devs who asked for it. So while the claim model solves one population, there’s another population that actively wants to own and manage their listing from day one. Both are real.

A few honest constraints on the itch.io crawling path: itch.io’s API is developer-only (your own sales, download keys) there’s no public catalog API to browse or ingest games the way IGDB provides for mainstream titles. So coverage would require a scraper, which is technically possible but would likely violate their Terms of Service, and is the kind of thing that gets you banned or ignored if you ever try to reach out for a partnership later. That’s also why direct dev uploads are cleaner for now; I control the relationship, and devs get a dedicated section in Discover. And a crawler would undercut exactly what makes the upload flow valuable: a dev who submits their game gets immediate visibility, their own dedicated page, and a section built specifically for dev-submitted games. That’s something a crawler can never replicate.

On the claim model specifically, you’re right that it removes the self-promotion barrier, but it does hand control of the listing to someone who never asked for it. Platforms like Steam and GOG go the opposite direction and require devs to own their page from day one. There’s a reason for that: devs who care about how their game is presented want to control it, and an auto-generated page can misrepresent them before they even know it exists. The opt-out you mentioned is the minimum but the first impression problem is real.

On the claim model from an engineering perspective, I love the idea and “your game is already listed, do you want to claim it” is a much better pitch than a submission form. The challenge is verification: how does someone prove they own the game? Without that, a bad actor creates an account and starts claiming and editing games they don’t own. Discogs works because music ownership is verifiable through external signals like label credits, artist profiles, release history. A game dev claiming their itch.io page needs a similar anchor, probably proving ownership of the itch.io or Steam URL. That’s solvable but not trivial. IGDB is actually a closer comparison than Discogs here since it’s a community-maintained database where anyone can edit, and it works because games have enough external reference points to catch bad edits. The difference is IGDB has a large active community to self-correct and is not just indie oriented. At this scale, every claim needs manual review, which brings back the bottleneck the claim model was supposed to remove. Worth building toward but the verification layer has to come before the claim flow, not after.

On the psychological barrier, you’re right that claiming feels different from submitting. But I’d push back slightly: some friction isn’t always bad. A dev who puts zero effort into visibility is also likely to put zero effort into responding to players, updating the game, or engaging with their community. The platform works better when devs are at least a little invested. The goal isn’t to remove all effort, it’s to make the effort feel worthwhile. If a dev sees that listing their game here drives real traffic and real players, the motivation follows. That’s the bet. And players notice. Gamers genuinely respond to devs who show up who post updates, respond to feedback, engage with their community. Some of the most beloved indie games probably aren’t the most polished ones, they’re the ones where the dev was visibly present. That engagement is part of the product, and it starts with being findable.

The deeper issue with “never market” devs is motivation, not friction. Even a claim flow requires them to care enough to act. Some won’t, and that’s genuinely hard to solve without something pulling them in: visibility, downloads, a reason to show up. That’s what the dedicated dev-uploaded section is trying to build toward: if a dev sees real traffic coming from a listing, that’s the motivation to engage.

On Bombercup, I don’t have a crawler yet so I can’t pull it in automatically, but I’d genuinely love to have it on the platform. It sounds like exactly the kind of game that deserves more eyes. A few options: I can add it manually as admin, or you can upload it yourself through the dev upload flow. It has its own dedicated section for dev-submitted games. Either way works, happy to do whichever is easier for you.

On your cold-start challenge, it’s a fair test and I want to answer it honestly. Multiple moods are supported simultaneously so chaotic, competitive, and nostalgic working together isn’t a problem. On comparative search: it partially works. Searching “atmospheric horror” or “action arena” works because the system searches across tags, genres, themes and descriptions so descriptive language maps reasonably well. Where it breaks down is truly comparative language: “games like Bomberman but faster” or “something like this but shorter and more relaxing” — the system has no way to parse that kind of relational intent yet. That’s a bigger challenge and an unsolved one. On mood inference: moods are currently generated at ingest time and in the case of dev uploads the dev defines them directly. The longer term direction is player-driven: after playing a game, players log how it made them feel, which over time builds a much richer and more accurate signal than anything inferred from text alone. That’s harder to game, harder to hallucinate, and closer to how people actually talk about games. Not there yet, but that’s where i am thinking on going.

I genuinely appreciate the thoughtfulness here. This kind of feedback is rare and it does shape how I think about what to build next. That said, every feature decision sits at the intersection of what different people want, and those people don’t always agree. The upload flow came from devs who asked for exactly that. The claim model is a valid alternative that solves a different problem. Both represent real perspectives, and neither one alone defines the right direction. I’m one person navigating a lot of competing needs, and the honest answer is that no single conversation settles these questions but conversations like this one move them forward. So thank you.

You are right about the crawler and I moved too fast there 🎮 “Technically possible but probably against the terms” is a real answer, and the partnership point is the one that should settle it: a scraper is a thing you can never mention in the conversation you eventually want to have with them.

But I think that constraint has a door in it that you may not have looked at, and it is neither a crawl nor the claim model. It is a third option, and it keeps your “the dev owns their listing from day one” principle completely intact.

itch documents an OAuth 2.0 implicit flow. You register an OAuth application, send the dev to itch.io/user/oauth with your client id and the scopes you want, they approve on a consent screen hosted by itch, and you get a token back. Under the profile:games scope there is an endpoint, api.itch.io/profile/games, which in itch’s own words fetches data about all the games you have uploaded or have edit access to. The payload carries title, short_text, url, cover_url, classification, platform traits, published state, and view and download counts.

Look at what that does to three of the problems you just described, at once.

No crawler. The dev authorised it, itch built the door, and there is nothing you would have to explain away later.

It is your verification layer, and you do not have to build it. You said, correctly, that verification has to come before the claim flow, and that otherwise every claim needs manual review. With OAuth, itch does the proving. Nobody can authorise a game they do not have edit access to, because the token is scoped to their account. That is the bottleneck removed rather than managed.

And it collapses the effort barrier without removing consent. A dev with eight games fills in eight forms today. With this they press “sign in with itch.io” once, and every game they own arrives with cover art and description attached. It is not a claim model, so it never hands anyone a page they did not ask for, and your first-impression problem does not arise at all. The dev still owns the listing from day one. They just did not have to type it.

Two caveats, unprompted, because both would bite you in public.

The profile/games response includes earnings and purchase counts. Discard them at ingest, and say so plainly on the consent screen. A dev who reads that scope carefully will work out that you can see their revenue, and one person saying that out loud in a forum costs more than the whole feature earns.

The payload carries a published flag, which implies unpublished and draft entries come through too. Filter on it, or the first time someone connects you will publish a game they had not announced yet.

On friction as a filter, you have a real argument and I want to concede the strong form of it: a dev who invests nothing in visibility probably invests nothing in their players either, and you are not wrong that the platform is better with invested devs on it.

Here is where I still think it points the wrong way. Friction selects for devs willing to market. Your player-side promise is finding things you would not otherwise find. Those two pull in opposite directions, because the inventory that makes you different from Steam is exactly the inventory held by the people least likely to fill in a form. Friction does not only cost you volume, it costs you the specific stock that is your differentiator, and it costs it selectively rather than at random.

So: keep the friction on the relationship, take it off the inventory. Claiming, editing, replying to players, all of that should require showing up and should visibly reward it. Being listed should not.

On comparative search, I think it is more tractable than you are treating it. “Like Bomberman but faster” is not arbitrary relational language, it is three fields: an anchor, an axis, a direction. You do not have to parse arbitrary relations. You have to resolve the anchor against your catalogue and map the modifier onto an axis you already store.

And there is a version that skips the language problem entirely. On every game page, a row of chips: more like this, but — faster, calmer, shorter, harder, multiplayer. Each of those is a query you can run today. The unsolved NLP problem becomes a solved UI problem, and every click is a labelled example of precisely the relational intent you cannot currently parse. You would be assembling the training data for the hard version while shipping the easy one.

On Bombercup, please do add it manually as admin, and I would genuinely rather you wrote the entry off the itch page than have me hand you polished copy. An entry the developer did not shape is a much better test of your ingest, and if it comes out wrong that is worth more to you than if it comes out right.

Bombercup, at cx99industry.itch.io/bomberonlinewc. A free multiplayer bomber-battle arena that runs in a browser tab, no download and no signup, continuous movement rather than grid-snapped, with a corner-slide assist. Unofficial fan project, no affiliation with Konami or Hudson, nothing for sale and nothing to install.

And on your closing point, that no single conversation settles these questions: agreed, and it is the right instinct to hold. The upload flow came from devs who asked for it, and those devs are real. I would only note that the OAuth path is not an alternative to them. It is the same thing they asked for, with the typing taken out 🚀