DEV Community: Mejzun

When to drop a game from your game backlog: what 770 dropped games in real backlogs look like

Mejzun — Tue, 10 Nov 2026 11:14:05 +0000

"Should I drop this game?" is the question that keeps a game backlog growing. I run a free game backlog tracker, so I looked at what people actually drop. Data from 129 accounts and 25,276 games, as of 2026-11-10.

How rare is "Dropped"?

770 games are marked Dropped, which is 3% of all games.
48 of the 129 people have dropped at least one. The other 81 never used the status.
2,899 games are Done (11.5%), so people finish about 3.8 games for every one they drop.

Dropped games are longer

For games with HowLongToBeat times (725 dropped, 2,770 done, 18,960 in backlog):

Status	Average main story	Median
Done	18.7 h	11 h
Dropped	24.7 h	12 h
Backlog	13.6 h	4 h

The medians for done and dropped games are almost the same, so length alone doesn't explain why a game gets dropped. The average is higher for dropped games (about 32% more), which means the very long games are where people give up. Games in the backlog are much shorter on the median: people add short, cheap or free games first and leave the big ones alone.

What I'd do with this

Set a rule before you start. "If I haven't touched it in a month, it goes to Dropped" is easier than deciding while you feel guilty.
Be extra careful with 25+ hour games. That is where the average pulls away. Start those only when you have a free stretch.
Dropped is a status, not a failure. A game backlog that never uses it can only grow. Moving a game out of the list is the cheapest way to make it shorter.
You can come back. The status is a label, not a delete button.

Caveats

It's a small, self-selected sample, and some of the 770 may be games a person dropped before they started tracking. HowLongToBeat times exist for 725 of the 770 dropped games, so the table doesn't cover all of them.

What is your rule for dropping a game in your game backlog?

My game search kept dying when RAWG went down, so I built a fallback from Steam and HowLongToBeat

Mejzun — Tue, 10 Nov 2026 10:55:26 +0000

How a small Express app keeps title search working when its main API is down or doesn't know a game: two keyless sources, a hard 3 second timeout each, and a cache that refuses to remember outages.

NXTO Game Backlog is a free game backlog tracker. You type a title, pick the game, it lands in your list. The catalog (about 153,000 games) comes mostly from RAWG, and RAWG is the weak link: its free tier has a hard quota, it has outages, and it lags on new releases. When search breaks, a new user can't add their first game, and that's the one moment I can't afford to lose them.

So search now has a fallback that answers when RAWG is down or doesn't know the title.

Two sources that need no API key

Steam store search knows every PC release the day it appears. It returns soundtracks, DLC and demos next to games, so each hit is checked with appdetails, and only type === 'game' survives. That same call gives genres, release year and a short description.
HowLongToBeat adds playtime, and covers console-only games Steam has never heard of.

Results are merged by normalized title into the same shape the normal search returns, so the frontend doesn't know which path answered. Playtime from HLTB is attached to the Steam entry with the same title. HLTB titles Steam doesn't have are kept only if they are close enough to the query (similarity of at least 0.75), because below that they are usually unrelated games.

Never let a slow source hold the search up

Both sources run in parallel with Promise.allSettled, each with a 3 second timeout (AbortSignal.timeout on the fetch, plus a Promise.race on the whole call as a second belt). A source that times out or fails contributes an empty list, and the other one still answers.

const [steamRes, hltbRes] = await Promise.allSettled([
  withTimeout(searchSteam(query)),
  withTimeout(searchHltb(query)),
])
const steam = steamRes.status === 'fulfilled' ? steamRes.value : []
const hltb  = hltbRes.status  === 'fulfilled' ? hltbRes.value  : []

Results are capped at 6, and the Steam cover falls back to the header image when the portrait art 404s, which it does for most small indies.

The cache bug I avoided on purpose

Answers are cached for an hour per normalized query. The detail that matters: a result is only cached when both sources succeeded. If Steam was down and I cached the thin answer, the outage would stick for an hour after Steam came back. A failed source means "answer now, remember nothing".

What I'd tell myself earlier

Decide up front what "degraded" looks like. For me it's fewer results and no playtime, never an error page.
Bound every external call. Without the timeout, a hanging provider turns a partial failure into a total one.
Cache successes, not outages.

NXTO is free to try at nxto.app, and if you track your backlog somewhere else I'd like to know what search feels like there.

My site's mobile PageSpeed went 86 77 99 in one afternoon. The "smart" fix made it worse. The boring fix gave me +22 points. What happened 🧵

Mejzun — Thu, 29 Oct 2026 12:44:01 +0000

PageSpeed 77 to 99 on a Vue site: the boring fixes that worked (and the clever one that made it worse)

Mejzun — Thu, 29 Oct 2026 11:22:45 +0000

I run NXTO, a free game backlog tracker (Vue 3 + Express + SQLite on one small server). The landing page scored 86 on mobile PageSpeed and I wanted 100. Here is what I changed, in the order I tried it, including the change that made things worse.

Attempt 1: make Google Fonts async (86 → 77)

The report said render-blocking requests would cost 840 ms, and the biggest one was the Google Fonts stylesheet. The textbook fix is media="print" onload="this.media='all'".

It made things worse: CLS went from 0.001 to 0.131 and FCP did not improve. The fonts arrived late, text re-flowed, and Lighthouse punished the shift. I reverted it.

Lesson: deferring a font stylesheet does not remove the font from the critical path, it just moves the layout shift to after paint.

Fix 1: self-host the fonts and preload the two that matter

I downloaded the woff2 files, inlined the @font-face rules in index.html, and preloaded only the Latin subsets of the two families used above the fold:

<link rel="preload" href="/fonts/inter-latin.woff2" as="font" type="font/woff2" crossorigin />
<link rel="preload" href="/fonts/space-grotesk-latin.woff2" as="font" type="font/woff2" crossorigin />

Other scripts (Cyrillic, Greek, Vietnamese) are separate files with unicode-range, so the browser only downloads them when a page needs them. The site has 12 languages, so this matters. One more family (a monospace font used in a few components) is gone from the landing page; it falls back to the system monospace.

Fix 2: the hero was hiding behind an animation

The landing headline used a fade-up animation: opacity: 0 to 1, 0.8 s long, with a stagger delay of up to 0.85 s per element. Lighthouse cannot report LCP for something that is invisible, so the headline was literally waiting for its animation. I shortened it to 0.35 s, removed the stagger, and start from opacity: .01 with a 12 px offset.

Fix 3: an `@import` hiding in a component

Round two of the report showed a second Google Fonts request: family=Cookie. It came from a scoped <style> block in a "Buy me a coffee" button, via @import url(...). Vite had bundled it into the main CSS, so my main stylesheet was blocked on a third-party request. I replaced that font with a system cursive stack.

Search your built CSS for @import and googleapis. It takes ten seconds.

Fix 4: no compression, at all

This was the big one. The audit said "text compression not applied", and curl -I -H "Accept-Encoding: gzip" confirmed it: neither the HTML nor the 76 KB CSS had a Content-Encoding header.

I had a Caddy config with encode gzip zstd, but in production Caddy was not in front of the app. The Express server was serving raw bytes. The fix was one line:

app.use(require('compression')())

Results (mobile, Moto G Power emulation, slow 4G)

	Before	After
Performance	86	99
FCP	3.0 s	1.4 s
LCP	3.2 s	2.0 s
CLS	0.001	0.023
Accessibility	95	100

Accessibility went from 95 to 100 after I raised the contrast of the gray footer text from gray-500/600 to gray-400.

What I would check first next time

curl -sI -H "Accept-Encoding: gzip" yoursite and look for Content-Encoding. Do this before anything else.
Grep the built CSS for @import.
Look for entrance animations on the LCP element.
Self-host fonts before trying to defer them.

If you have a Vue SPA with a server-rendered shell, I would love to hear what else you found. The full list of changes is in my git history; ask and I will share the diff.

Question for builders: how long did it take your free side project to earn its first euro? Mine: 103 signups in 5 months, $0 so far. ChatGPT is oddly my best traffic source. #buildinginpublic

Mejzun — Tue, 27 Oct 2026 09:07:20 +0000

Devlog #2: SEO for 150,000 game pages, and why only ChatGPT recommends my site

Mejzun — Tue, 27 Oct 2026 08:51:58 +0000

In Devlog #1 I wrote about building a backlog tracker for myself. This one is about the part I underestimated: getting anyone to find it.

My biggest problem was never the code. It was "where do I share this so people know it exists?" Reddit banned me for posting, so I stopped fighting it and went the other way: make NXTO findable on its own.

Step 1: Every game gets a real page

NXTO is a Vue single-page app, and SPAs are a bad deal for search engines and for AI crawlers, because many of them don't run JavaScript. So every game in the catalog gets its own server-rendered page at /games/<slug> with the title, genres, tags, playtime and a description in plain HTML.

Two things made that harder than it sounds:

Missing slugs. Links built from Steam titles don't always match my slugs. Backlog links now carry the Steam app id and the game page resolves it before guessing from the slug. If a slug is still missing, it redirects to the clearly most popular game whose slug starts with it, instead of a 404.
Thin content. 150,000 pages with one sentence each is a good way to be ignored. For popular games without Steam text I pull a short Wikipedia excerpt (first paragraph, 350-650 characters, with the CC BY-SA credit) and fall back to a longer AI-written description. Unique, useful text per page was the whole point.

Step 2: Tell the search engines when something changes

Google finds pages slowly. Bing supports IndexNow, so every time the catalog changes the server pings it with the changed URLs. Cheap to build, and it's probably why Bing-based products notice me first (more on that below).

Step 3: "Where to buy" without a paywall

Hosting costs money, so game pages now show where a key is cheapest, converted to your currency (guessed from your country, otherwise from the interface language).

The boring engineering behind it:

A nightly job streams a store's product feed (a CSV of hundreds of MB) into SQLite, one row per store, game and currency. Streaming matters, because loading it into memory is not an option on a small server.
Games are matched by a normalized title. That's imperfect, so not every game gets an offer.
Clicks go through my own /go/... redirect, so I can count them and the page itself never contains raw affiliate URLs.

Some links earn me a small commission. You never pay more.

Step 4: What I learned about getting recommended by AI

Right now the only assistant that recommends NXTO is ChatGPT. That isn't random. Different assistants pull from different search indexes:

ChatGPT leans on Bing's index (which IndexNow feeds).
Gemini and Google AI Overviews use Google's.
Claude uses Brave Search.

Links matter much less than in classic SEO. What matters is being in the index the assistant searches, and being mentioned in places it trusts. So my to-do list is: get into Google Search Console and Brave, keep the pages server-rendered, and collect mentions from people who aren't me. This post is part of that.

What's next

Better matching between games and store offers.
More languages for the game pages.
Whatever you ask for on the ideas page.

Questions for you:

If you've launched a side project, where did your first 100 users actually come from?
Do you check whether AI assistants mention your product? If so, how?

Devlog #1: I built a backlog tracker because I kept forgetting what to play

Mejzun — Mon, 19 Oct 2026 17:41:52 +0000

I kept forgetting which games I planned to play. So I built a simple backlog: what I'm playing, what's next, what I've finished.

That was the whole idea. Here's how it grew into NXTO, and what I learned on the way.

Step 1: A list that works

The first version did one thing: three lists. Playing, planned, finished. No accounts to connect, no clever features. Just somewhere to put games so I'd stop losing them in notes, wishlists and my own memory.

It solved the problem. But once I was tracking finished games, a new question showed up.

Step 2: "What should I play next?"

Having a history of what I'd finished made recommendations the obvious next feature. And I had a specific reason to build my own: I own games on several platforms, and Steam's recommendations can't see what I played elsewhere. Every store only knows its own corner of my library.

So NXTO recommends based on everything I've played, with my ratings as the signal. (I wrote up the technical side of that, including why my first version suggested junk, here.)

Step 3: Sharing it

Once I had this working for myself, I wanted to share it. I put it online on a random domain I already owned, nothing polished, just a link I could send to people.

Step 4: People signed up

To my surprise, people started registering. That meant it needed a proper home, so I bought nxto.app.

Hosting costs money, so I looked for a way to cover it without putting up a paywall. I added a Buy Me a Coffee link, and a price comparison for game keys: open a game and NXTO shows where it's cheapest (Eneba, G2A, Instant Gaming, Kinguin), converted to your currency. Some of those links earn me a small commission, and you never pay more.

Honest numbers

Since the first signup in May:

79 accounts, 64 of them have added games
about 10,400 games tracked in total
a catalog of around 150,000 games to search from

I'm building this in the open, with a public ideas page where you can tell me what to build next: nxto.app/ideas.

If you track a backlog, what's the one feature you'd want? And how do you decide what to play next?

Nxto story #1: I kept forgetting which games i planned to play. So i build a simple backlog to track what i'm playnig, what i plan to play and what i've finished. #buildinginpublic #indiedev #gamingbacklog

Mejzun — Mon, 19 Oct 2026 17:23:31 +0000

Why my game recommender kept suggesting junk (and how IDF weighting fixed it)

Mejzun — Mon, 19 Oct 2026 17:22:12 +0000

I play on several platforms, but every store only recommends games based on what I did there. Steam had no idea what I'd finished elsewhere, so its suggestions kept missing. I wanted one place that knows my whole library, so I built it: NXTO, a backlog tracker with its own recommendations.

The stack is boring on purpose: Vue 3, Express, SQLite via better-sqlite3. Game metadata and tags come from RAWG. The interesting part was making the recommendations not suck.

First attempt: Jaccard on tags

The obvious approach: each game has tags, and two games are similar if their tag sets overlap. Jaccard similarity does exactly that.

It looked fine until I read the results. Games matched on filler tags like 2d, atmospheric and rpg, which are shared by thousands of titles. The tags that actually define a game, like farming or souls-like, were drowned out.

Fix 1: IDF weighting

Borrowing from search: a rare tag should count more than a common one. I weight every tag by inverse document frequency and compare games as vectors with cosine similarity. Two games sharing souls-like now look far more alike than two games sharing 2d.

Fix 2: the long tail of junk tags

IDF created a new problem. The catalog has about 48k distinct tags, and 90% of them occur fewer than 10 times: typos, one-off labels, joke tags. Under plain IDF those rare tags score higher than any real tag. One tag with a document frequency of 1 got a weight of 8.5 and hijacked the cosine.

The fix is a minimum document frequency (MIN_DF = 5). Anything below the floor is dropped from the vocabulary entirely.

Fix 3: ratings are signal, not just "finished"

Finishing a game doesn't mean you liked it. I turn the user's rating into a taste weight:

Rating	Weight
5★	+2.0
4★	+1.5
3★	+0.6
2★	-1.0
1★	-2.0
unrated	+0.8

3★ means "fine, not a signal", and 1-2★ actively push the taste vector away from similar games. A user's profile is the weighted sum of their games' tag vectors.

I also only rank games with at least 10 ratings. Below that, the catalog is full of unrated jam entries that no ranking can order honestly.

Caching without serving stale results

Scoring a whole catalog per request is expensive, so I cache the sorted pool per user. The key includes MAX(updated_at) and the row count for the user's games. Both are needed. updated_at has one-second resolution, and deleting a game doesn't move the maximum at all, so a timestamp-only key would keep serving a pool that still contains the game you just removed.

I also bump an ALGO_VERSION in the key whenever scoring changes, so a deploy never serves pools built by the old algorithm.

What I'd do differently

Look at the output early. The tag problem was invisible in the code and obvious in the results.
Treat the vocabulary as data to clean, not just math to tune.

If you track a backlog, I'd love to know what it recommends for you. And if you've built a recommender, what did you do about noisy tags?

Try it: nxto.app

ive made game recommendation app nxto.app, it base on your game backlog and ur rating

Mejzun — Sat, 03 Oct 2026 11:43:50 +0000