My Web Game Worked on My PC but Broke on Phones — The Deployment Trap I Missed

I published a web game.

It worked on my computer. The fixed code was on GitHub. The deployment had succeeded.

And yet, on some phones, it still broke.

The error I found in analytics was:

SyntaxError: Unexpected token '<'

I was writing JavaScript, so why was a less-than sign suddenly the problem?

This happened while I was building my web game, ORA Quest. The useful lesson was not a clever one-line fix. It was learning what this error is often trying to tell you.

The “<” may not be the real problem

My first instinct was to look for a JavaScript syntax mistake. Maybe I had typed a strange character. Maybe a JSON file was broken. Maybe a comma was missing.

But with Unexpected token '<', one of the first things worth checking is whether the browser asked for JavaScript or JSON and received HTML instead.

Imagine the browser requests game.js. It expects JavaScript. But the server returns an error page that starts with <!DOCTYPE html>.

The browser tries to parse that response as JavaScript, hits the first <, and fails.

So the message can be misleading. The symbol is not necessarily the culprit. The browser may simply have been given the wrong kind of file.

The worst bugs do not break for everyone

In my case, that was what made the problem so frustrating.

It was not “the game is down for everyone.” It could work on a desktop, work on one phone, and fail on another phone or inside an in-app browser.

That creates a dangerous debugging loop:

fix the code → deploy → open it on your own PC → it works → assume it is fixed.

I used to consider that a successful check. I do not anymore.

If the failure depends on cache, browser behavior, an old asset, or a specific request path, your own machine can give you a false sense of safety.

The five things I would check first now

1. Open the URL of the failing JavaScript or JSON file directly.
2. Check whether the response is actually JavaScript or JSON.
3. Look for an HTML error page, login page, WordPress page, or redirect instead.
4. Confirm that the production server is serving the same file you expect from GitHub.
5. Test again on another device or browser without relying on the same cache.

The first check is especially valuable.

Instead of changing code because the error “looks like JavaScript,” ask a simpler question first:

What did this URL actually return?

That can save a surprising amount of pointless editing.

Correct on GitHub does not mean correct in production

This was another painful lesson.

You can have the right code in GitHub and still have the wrong thing reaching users.

Between your repository and a player there may be deployment automation, a hosting server, WordPress, CDN or server cache, browser cache, and an in-app browser.

If one layer serves an old or unexpected response, you can end up saying, “But I already fixed this,” while users are still seeing the broken version.

So my definition of “fixed” has changed.

A fix is not finished when the commit is correct. It is finished when the production URL works under conditions close to the real user’s.

Do not only remove the error — make the next one easier to understand

I used to focus on one thing: make the error disappear.

Now I also try to leave enough information to understand it if it happens again.

Which file failed? Which URL was requested? What browser or environment was involved? Which build was running?

That turns “the same mysterious bug came back” into a much better question: “Is this the same cause as last time, or a different one?”

It is not glamorous work. But for a solo developer running a live service, it may be more valuable than another hour spent adding a feature.

Solo development is often less about writing code than understanding reality

Before I started building web games, I imagined development as writing stories, creating characters, and programming systems.

A lot of the real work has been questions like:

Why does this fail only on one device? Why is yesterday’s JavaScript still appearing? Why did a JSON URL return HTML?

Each time I understand one of those failures, the range of things I can build gets a little wider.

The biggest lesson from Unexpected token '<' was simple:

the code you wrote and the file the user actually receives are not always the same thing.

If you are seeing this error right now, before rewriting your JavaScript, open the failing JS or JSON URL directly. If you see HTML, you have found a very useful clue.

I am learning these lessons while building ORA Quest, a web game that is currently playable as a free demo. If you are curious what all this debugging is for, you can play the ORA Quest demo here.