What I Learned Building a Personal Website This Summer

This summer I spent a lot of time turning Shadorux from a collection of pages into something that feels more like a small digital world. That meant writing code, making graphics, testing layouts, and figuring out what a personal site should actually be for.

A website needs a point of view

The biggest lesson was that a personal site does not have to look like a standard portfolio. I wanted Westopolis to feel like an old computer interface, so the Explorer became part of the navigation instead of a decoration around it.

That choice gave the site a recognizable identity. It also made every new page a design decision: file names, folder labels, status bars, colors, and even the way a link opens all contribute to the feeling of the place.

Build the identity and the useful parts together

Visual style is only useful when visitors can still find what they came for. I learned to pair the strange, retro presentation with ordinary web fundamentals: descriptive titles, readable text, permanent URLs, crawlable HTML, and clear links.

The best version of a personal website can be expressive without making visitors decode everything. A visitor should be able to explore, but they should also understand where a project, journal entry, or resource will take them.

Small experiments become a real archive

Individual pages can feel unimportant while they are being made. Over time, though, debugging notes, graphics, tools, and experiments become a record of how you think. The archive is one of the reasons I keep building instead of waiting for the site to feel finished.

Summer signal

Make the site specific enough that it could only belong to you, then make it clear enough that someone else can enjoy visiting it.

There is no final version

Hosting changes, cache bugs, missing images, and imperfect first attempts are all part of maintaining a live site. The work is not just launching a homepage. It is noticing what breaks, fixing it, and leaving the next version easier to understand.

That is what I want the Developer Journal to document: not a perfect build, but the decisions and problems behind a site that keeps growing.