Designing a Portfolio as a Product System

A portfolio has two jobs: help someone understand the engineer quickly, then provide enough evidence to earn a deeper conversation. Everything else (articles, demos, effects, and an interactive space game) should support that hierarchy rather than compete with it.

This site is a Next.js application with a conventional professional surface, a small Labs area, server-backed demos, and Nebula: a Three.js route through the same public story. The architecture grew over several iterations, including changes that were later simplified or removed.

Give the professional story one clear hierarchy

The homepage is intentionally short and linear: positioning, selected work, Labs, writing, a brief About, and contact. It does not try to reproduce the résumé or list every project. Each section answers the next reasonable question and links to a deeper route when more context is useful.

• Case studies carry product constraints, contribution, evidence, and limitations.
• The résumé remains the compact chronological source.
• Writing demonstrates reasoning that cannot fit inside a project summary.
• Labs contains experiments without presenting them as client or employer outcomes.

This separation matters for credibility. A playful demo can show curiosity; it should not blur the distinction between shipped professional work and a personal experiment.

Keep public claims in small typed registries

Repeated profile facts, work entries, and article metadata live in typed modules rather than being rewritten independently on every page. The homepage, work archive, metadata, structured data, sitemap, and Nebula can then reference the same reviewed source.

A registry does not need to become a content platform. For a portfolio of this size, a few TypeScript records are easier to review than a CMS, keep build-time output predictable, and make stale claims testable. Articles follow the same rule: each one is a single MDX file that holds its text, its links, and a typed metadata block. A small registry reads that folder at build time and feeds the index, sitemap, feed, structured data, and reading times, so adding a post means adding one file.

Separate experiments from the primary visitor path

The travel planner and sticker generator depend on external services and have different maintenance expectations from the core portfolio. The floor-plan walkthrough offers a separate, interactive 3D study. Labs gives them an honest frame: experimental, bounded, and optional.

Each demo should explain what a visitor can try, what happens when a service is unavailable, what information leaves the browser, and whether an affiliate relationship exists. When a demo cannot be maintained to the same standard, it can remain as a clearly labeled archive without weakening the professional path.

Build Nebula as an extra route, not a required introduction

Nebula maps profile, skills, work, and contact content onto planets and stations. The game owns its renderer, controls, loading state, model assets, audio preferences, and an AI guide that answers through a server route and falls back to built-in replies when that route does not answer. It is deliberately excluded from the fastest path through the portfolio.

This boundary protects both experiences. A recruiter can read case studies without loading Three.js or GLB models; someone who wants the more memorable route can opt in. The game also has procedural fallbacks, but those fallbacks must not hide asset regressions: automated browser tests now verify that the real ship and asteroid models finish loading.

Treat every external integration as a server boundary

Contact email, AI text, travel recommendations and generated images all pass through server routes. Those routes validate input, apply time and size limits, keep provider credentials off the client, and return product-specific errors rather than raw upstream responses.

• Environment variables are server-only unless the browser genuinely needs the value.
• Rate limits and bot checks reduce abuse without making the happy path opaque.

Make quality and maintenance visible in the structure

Metadata and structured data are generated from the same content registries. Unit tests cover those contracts and API boundaries; Playwright covers the main visitor routes and Nebula assets. Accessibility checks focus on semantics and interaction rather than treating a score as proof that the experience works.

The AI-assisted workflow follows the same boundaries: work moves in gated steps, a fresh session from a different model family reviews each milestone, and status files and handoffs carry the record between sessions. How I Build with AI describes these checks and their limits.

Architecture checks, content registries, browser tests, and performance audits keep changes reviewable as the site grows. The maintenance system stays behind the scenes so the public experience can remain focused on the work rather than the tools used to build it.