Skip to content
Games by Harring

Craft

Why I build games alone — with web technology

The manifesto behind Games by Harring. Why one Danish developer ships complete games solo with TypeScript, React and Capacitor instead of a game engine and a team.

Halfdan Harring

Halfdan Harring

Indie game developer · Aarhus, Denmark

Every game on this site is made by one person: me. Not “one person plus contractors”, not “small team” — one keyboard in Aarhus, Denmark. This post is the why and the how behind that choice, and it’s the post to read first if you want to understand everything else in this devlog.

The unfair advantage of being alone

Solo development is usually framed as a limitation. I think that’s backwards — if you design for it.

A solo developer has no meetings, no handoffs, no design documents written to convince anyone. The loop between “idea”, “implemented” and “felt on a device” can be minutes long. When I was tuning the launch angle in Dolphin Beyond, I changed the curve, hot-reloaded, and felt the difference forty times in an hour. No team can iterate on feel that fast, because feel doesn’t survive being described in a ticket.

The cost is scope. One person cannot make an open-world game, and shouldn’t try. Every game I ship is built around one mechanic that fits in a thumb: a dive angle, a 1X2 pick, a five-question duel, a flicked die. Small surface, deep polish.

Why web tech instead of Unity or Godot

Honest answer: because it’s what I’m world-class fast in, and speed is the whole strategy. I’ve spent years building products with TypeScript, React and Firebase for clients and for my own apps. When I open a game project, I’m not learning a tool — I’m spending skill I already have.

But there are structural reasons too:

  • The browser is the best iteration environment ever built. Hot reload, devtools, profiling, shareable builds behind a URL. My playtesters click a link.
  • One codebase, every screen. Capacitor wraps the same build into a real native iOS app. Dolphin Beyond ships from one core to the App Store and the open web.
  • The web is a distribution channel, not just a runtime. A playable browser version is the best marketing a small game can have. No download wall between a curious player and the first jump.
  • When the platform isn’t enough, you drop down. Runish needed real background GPS, so I wrote custom native Capacitor plugins. Web-first doesn’t mean web-only.

The performance question is mostly outdated. My games run custom physics at 60fps on mid-range phones — WebGL through Three.js handles the 3D games, and for 2D simulation, modern JavaScript engines are absurdly fast if you respect the garbage collector.

The rules I ship by

  1. The core loop must be provable in a week. If a prototype isn’t fun with rectangles, art won’t save it.
  2. Determinism wherever possible. Deterministic simulations give you replays, tests and anti-cheat for free. Dolphin Beyond’s whole leaderboard integrity rests on this.
  3. Ship, then sharpen. A live game teaches more in a week than a private build in a quarter. Over-the-air updates keep the loop tight after launch.
  4. Everything is content. The engine write-up, the failed experiment, the App Store rejection — it all becomes devlog material. Building in the open is free momentum.

What’s on the table

Right now: three games live on the App Store — Dolphin Beyond, HeadToHead and Quiz Fight — and four in development: Ragnaroll, Big Chair, TinyTrack and Runish.

Each one gets its own posts here. Subscribe to the RSS feed if you want them as they land.