Why I Keep Portfolio Sites Static First
A short explanation of why this portfolio starts with static routes, local MDX content, and restrained presentation before adding heavier features.
A portfolio site should explain who owns the work, what the person builds, and how to contact them. If those basics are unclear, animation and complex interaction do not fix the problem.
For this site, the first version stays static. The landing page is a simple App Router page, and the writing section reads local MDX files.
Static content keeps the scope honest
Static pages force the content to carry the experience. The page needs clear headings, readable copy, direct project entries, and working contact paths.
That is a useful constraint. It keeps the first version focused on identity, work, writing, and navigation instead of effects.
Local MDX is enough for early writing
Local MDX is a good fit when the site has a small number of technical notes. It keeps the content near the code, avoids a separate service, and still allows each post to have metadata for title, description, category, tags, date, and reading time.
The blog can grow later, but it does not need a content management system on day one.
Design should not hide weak content
The site stays plain on purpose: readable type, simple routes, and no decorative effects. That makes weak copy easier to see and fix.
For a developer portfolio, that tradeoff is acceptable. The work should be readable before it is decorative.