I did not want another personal portfolio made from a large name, a short biography and a grid of cards.
There is nothing wrong with that format. It just did not feel like mine.
The visual language I kept returning to came from somewhere older: boot screens, directories, command lines, BBSs, IRC, NFO files, game menus and the wider computing culture I grew up around. Those systems did not hide their structure. They told you where you were, what state they were in and what inputs were available.
That became the starting point for SYSTEM BOOT.
The challenge was using that language without building a costume.
Nostalgia as grammar
The easiest version of this idea would have been fake terminal text, random hexadecimal strings and a permanent green glitch effect.
That would also have been the least interesting version.
The useful part of old interfaces is not the decoration. It is the grammar.
BOOT. STATUS. DIRECTORY. COMMAND. INPUT. OUTPUT. STATE.
Those ideas still make sense.
So the site became a small layered system rather than a single visual trick.
At the outer level there is a contained SYSTEM BOOT screen.
That opens into a launcher.
The launcher opens the actual site: HOME, WORK, ARCHIVE, WRITING, ABOUT and CONTACT.
A Command Deck sits across the system as an accelerator rather than a separate destination.
The result is recognizably influenced by older computing interfaces, but the content underneath behaves like a modern website.
That distinction became a rule:
Look like a machine. Behave like a modern website.
The boot screen had to earn its existence
An entry sequence is dangerous because it can become friction very quickly.
If the boot screen exists only to delay access to the site, it is decoration.
I wanted it to establish the environment instead.
The sequence introduces the system state, the identity and the interaction model. It makes the transition into the site feel intentional.
But it also has to know when to get out of the way.
That required thinking about fresh sessions, returning users, explicit reboot behavior, keyboard control and eventually touch input. The desktop interaction started naturally with Enter. Once the site went live, the missing question became obvious: what is Enter on a phone?
That is a useful reminder that a strong concept can still contain a basic product blind spot.
The answer is not to abandon the concept. It is to make the interaction model complete.
Keyboard on desktop. Touch on mobile. Same system.
Motion communicates state
SYSTEM BOOT uses motion, but motion is not the point.
Scanlines, signal sweeps, luminance changes and brief transition breaks exist to reinforce state. They are not there to make every screen constantly move.
That led to another rule:
Motion communicates system state. Motion is not marginalia.
A route change can produce a short signal response. A selected Archive record can have a restrained scan. Writing can carry a subtle reading pulse. The environment can breathe without turning into an animated wallpaper.
The same applies to glitch.
Glitch is an event, not a texture.
When everything glitches, nothing means anything.
Building the inside pages
The early content work was done in page-level prototypes. That was useful for resolving information architecture and copy, but it created an unexpected problem during production migration: the prototype UI began leaking into the actual product.
That was wrong.
The content prototypes were never supposed to become a second design system.
The fix was to return to the integrated shell and make that the source of truth. WORK, ARCHIVE, WRITING, ABOUT and CONTACT all had to feel like parts of the same environment rather than individually designed microsites.
That correction was probably the most important production decision in the build.
Architecture should disappear behind the interface.
Moving to real multi-page HTML, external CSS and JavaScript, semantic navigation and production-friendly assets should make the site more robust without making it look like a different site.
An interface with two speeds
SYSTEM BOOT now has two ways to use it.
The first is ordinary navigation. Click or tap through the site like any other website.
The second is accelerated navigation. Use / for Command, keyboard shortcuts, direct selection and the launcher.
The second mode should never be required to understand or operate the first.
That is another principle that emerged from the build:
Keyboard is an accelerator, not a barrier.
The site can reward people who enjoy exploring systems without punishing people who just want to read.
What SYSTEM BOOT became
The project started as a visual direction for a personal website.
It became a way of organizing several parts of my work that do not naturally fit inside a conventional portfolio: products, studios, tools, artwork, machines, writing and unfinished experiments.
That is probably why the system metaphor lasted.
A portfolio asks everything to behave like a project.
A system can hold different kinds of things and still give them structure.
SYSTEM BOOT is not an attempt to recreate an old computer.
It is a modern site built using a language I already understood.
