404 as a Feature, Not an Error

While rebuilding my personal website, wadyd.wtf, I kept landing on default 404 pages that felt like placeholders. They do their job, but they say nothing. I wanted mine to feel like part of the product, not a leftover route.

That idea reflects how I approach web design and development through Solve404. I build websites for businesses and organisations with a strong focus on user experience, performance, and attention to detail. A website is not just its homepage or contact form. Every interaction contributes to how people perceive a brand, including the parts most visitors never expect to see.

The idea was simple. If someone reaches a page that does not exist, I still have their attention for a few seconds. That moment is usually wasted. I treated it as an entry point instead.

The standard 404 page is an apology. It's a white screen with some clever copy that ultimately says: you are lost, and it's probably your fault. I wanted the 404 page on wadyd.wtf to treat the error as a destination, not an end. If the user is going to be stuck, they should at least be stuck somewhere that feels like it was designed by the same hand as the rest of the site.

For me, that is what attention to detail looks like. Even something designed to handle an error can still be considered part of the experience. The best websites often get the small things right, especially the things most people overlook.

The result was "System Invasion", a full Space Invaders clone tucked into the 404 void. It wasn't built for traffic. It was built for the small number of users who get lost and decide to stay for a moment. Turning an error page into something memorable felt more interesting than simply telling visitors they had reached the wrong URL.

Implementing a game engine inside a Next.js error boundary comes with constraints. You have to handle state transitions between START, PLAYING, and GAME_OVER without breaking the page's lightweight feel. The most satisfying part was building the invader grid, not just as a list of images, but as a live coordinate system that responds to player physics.

const spawnParticles = (x: number, y: number, color: string) => {
  for (let i = 0; i < 15; i++) {
    stateRef.current.particles.push({
      x: x + InvaderSize / 2,
      y: y + InvaderSize / 2,
      vx: (Math.random() - 0.5) * 6,
      vy: (Math.random() - 0.5) * 6,
      life: ParticleLife,
      color,
    });
  }
};

It is not complex, but it is enough. The page responds. It feels aware. That was the goal.

One mistake I made early was adding too much motion. It looked impressive for a second, then became distracting. I removed most of it. What stayed was quieter, but it lasted longer.

Not everything needs to be seen immediately. Some things work better when they are discovered.

Although the project lives on wadyd.wtf, it reflects the same attention to detail I bring to client work through Solve404. Good websites are not just about the pages people expect to visit. The overlooked moments matter too. Error states, loading states, transitions, and small interactions all contribute to how a product feels.

In the end, the page does very little. But it does it on purpose. It reacts, it invites, and if you stay, it gives you something back.

For a page that exists because something went wrong, that feels like a worthwhile outcome.

Sometimes the details people are least likely to see are the ones that say the most about how something was built.

If you’re curious how that same approach translates into client work, take a look at https://solve404.dev