Why I built this site the way I did.

The last time I had built a portfolio site was in college. Thankfully at this point in my life I had a lot more free time to work on my own projects. I had always wanted to build something that looked sleek with cool JS frameworks with exciting animations.

The stack

The whole thing runs on Astro. It’s the kind of framework that gets out of your way for mostly static content like this, and then lets you drop in an interactive island exactly where you need one instead of shipping a heavy JavaScript bundle for the whole page.

The hero starfield on the home page is one of those islands. It’s a React component built with React Three Fiber, which is just Three.js wrapped up in React’s declarative style. The background canvas runs its own shaders in GLSL, the language that runs on the graphics card. I wrote it so it respects your reduced motion settings and pauses when you leave the tab, because a spinning starfield you can’t see is just wasted battery.

There’s a second island on the About page: a photo rotator that crossfades through a few pictures of me and my life. Same idea, no reason to load that logic on every page visit.

Styling is Tailwind, which means I write utility classes directly in the markup and the build tree-shakes out anything I don’t use. The content, including this post, lives as MDX files in a content collection. Astro generates types from the frontmatter schema, so if I get a field wrong the build fails loudly instead of silently breaking at runtime.

Deployment is handled by the Vercel adapter. Every push to main triggers a build, and within a minute or two the live site reflects the change. That’s the CI/CD loop, and it’s nice.

Why it’s built this way

The short version is that I wanted the site to feel alive without being slow. A lot of portfolio sites go two directions: they’re either a static wall of text, or they load a megabyte of JavaScript to animate a page flip. I tried to split the difference. The showy parts, the starfield and the photo rotator, are isolated so they can’t drag down the rest of the experience. Everything else is static HTML, which is cheap to serve and fast to load.

The other choice that mattered was the content collections. I like that blog posts and projects are plain files with typed frontmatter. It keeps writing feel like writing, not like filling out a database form, and it gives me type checking for free.

If I had to do it over, the one thing I’d change is probably starting with a real content plan instead of building the shell and then realizing the hard part is the writing. The tech was the fun part. The content is the work, and I’m still doing that part.

What’s next

I want to give the blog things like reading time, related posts, and tags you can actually navigate. I’ve also got a couple of real project case studies in the works that’ll go deeper than the summaries on the projects page. And I’ll keep adding posts here about wading back into full stack development, since that’s been the whole point of building this thing.