Building a Retro Portfolio with system.css
· 3 min read · dev
← Back to BlogI wanted a portfolio that didn't look like every other developer site on the internet. Most portfolios follow the same template: hero section, gradient background, sans-serif font, dark mode toggle. They're clean. They're also forgettable.
So I built mine to look like a 1984 Macintosh.
Why retro?
I grew up fascinated by old computing. There's something about the constraints of early UI design — 1-bit graphics, 512x342 pixels, no color — that forced designers to be precise. Every pixel mattered. Every interaction had to be obvious because there was no room for ambiguity.
Modern web design has the opposite problem. Infinite space, infinite color, infinite animation — and most sites end up looking the same anyway. Going retro was a way to impose constraints that would force interesting decisions.
It also just fits my personality. I make music, I tinker with hardware, I like things that feel handmade. A brutalist retro portfolio says more about me than a polished template ever could.
The stack
- Next.js 15 with App Router — file-based routing, server components, static generation for blog posts
- system.css by @sakun — a CSS library that recreates Apple System OS (1984-1991). Windows, buttons, menus, dialog boxes, all pixel-perfect
- gray-matter + remark — for parsing markdown blog posts with YAML frontmatter
- TypeScript — because I like my bugs caught early
- Self-hosted fonts — Chicago, Geneva, Monaco. The actual fonts from classic Mac OS
No Tailwind. No component library. No CSS-in-JS. system.css is the design system. Everything else is vanilla CSS in a single globals.css file.
How it's structured
The layout mimics a classic Mac desktop:
- Menu bar fixed at the top — File, Navigate, Connect dropdowns, just like the real thing
- Sidebar as a "window" — navigation pane on the left, like a Finder window
- Content area — where pages render, scrollable, clean
Every page follows the same pattern: page-heading for the title, content-section for blocks, window class for any panel or modal. The system.css classes do all the heavy lifting.
The blog
Blog posts are markdown files in /content/blog/. Each one has frontmatter for title, date, summary, and category. The build system reads them with gray-matter, converts to HTML with remark, and serves them as static pages.
No CMS. No database. Just files in a folder. If I want to write a post, I create a .md file and push. That's it.
The notes system
I also built a local notes system with wiki-link support ([[Note Title]]), a graph view showing connections between notes, and full CRUD — all stored in localStorage. It's like a tiny Obsidian inside the portfolio. Overkill? Probably. But it was fun to build and I actually use it.
What I'd do differently
The experience section started as a plain table. It works, but a timeline view would be better — more visual, more Mac-like. I'm planning to replace it.
I'd also like to add more personality: a mixtape page, a guestbook, maybe a terminal emulator. The retro theme has so much room for interactive features that would feel weird on a modern portfolio but completely natural here.
The point
Building this site was a reminder that constraints are underrated. When you can't rely on gradients and animations to make things look good, you have to think harder about information hierarchy, interaction patterns, and what actually matters on the page.
The best design isn't the prettiest. It's the one that communicates the most with the least.