This portfolio is intentionally small, but it is not casual. The codebase is trying to do a few specific things well: keep the site fast, preserve a distinct editorial visual language, and make content updates cheap without introducing unnecessary infrastructure.
The result is a project that stays narrow on purpose. There is no large application shell, no heavy client-side state layer, and no component sprawl for its own sake. Most of the value comes from a clean content structure, a small set of reusable Astro components, and a design system that is explicit enough to keep the UI coherent.
The project is built around Astro’s strengths
At the highest level, the repo uses Astro as a content-forward site rather than as a container for a client-rendered app. That choice shows up immediately in the structure:
src/pageshandles the route surfacesrc/layoutsdefines shared document structuresrc/componentscontains reusable interface piecessrc/content/blogstores authored blog posts as Markdownsrc/styles/global.cssholds the design tokens and utility conventions
That is a good fit for a portfolio because most of the work is presentation and authored content, not complex user interaction. Astro lets the site ship mostly as HTML and CSS, which is exactly what a project like this should optimize for.
The visual system is treated as code, not mood
One of the stronger qualities of the repo is that the visual direction is documented instead of implied. DESIGN.md makes the intent concrete: modern editorial composition, OKLCH color tokens, fluid type, asymmetrical layout, and tactile grain texture.
That matters because the code can then follow a real system instead of a series of one-off decisions. In src/styles/global.css, the typography scale is defined with clamp(), the palette is expressed as semantic tokens, and reusable layout utilities such as editorial-container and editorial-grid carry the page structure.
This is a better pattern than scattering visual choices across every component. The site still feels expressive, but the expression is constrained by named decisions:
- the serif and sans pairing is consistent
- accent colors have clear roles
- spacing and borders reinforce the editorial rhythm
- dark mode inherits the same system instead of becoming a second design
That is the difference between styling and a design system. Styling decorates screens. A design system reduces future decisions.
Components stay narrow and recognizable
The components in this repo are small, which is the right call. Header, Section, ExperienceItem, SkillBadge, ThemeToggle, and Intro each carry a clear responsibility.
That keeps the codebase readable. When a component is narrow, the page layer can remain expressive without pushing too much abstraction into the component API. The homepage benefits from that balance: it reads like a composed document rather than a tree of over-generalized building blocks.
The Header is a useful example. It is not only navigation. It also carries some of the site’s identity through the magnetic interactions, time display, and route-aware links between the one-page homepage sections and the newer blog routes. That is a good kind of coupling because it is product-facing and intentional.
The content model is simple on purpose
The blog setup now uses Astro content collections. That keeps posts in Markdown and gives the repo typed frontmatter through the collection schema.
For this site, that is the right level of structure. A portfolio blog does not need a CMS before it has editorial complexity. The current model already gives enough discipline:
- each post has typed metadata
- drafts can be excluded cleanly
- routes can be generated from the content itself
- writing remains close to the repository
That makes the content system easy to reason about. Adding a post is just adding a file. The site gets a clearer authoring workflow without inheriting the maintenance burden of a larger publishing stack.
The codebase optimizes for restraint
The most important architectural trait here is restraint. This project does not try to prove technical depth by adding moving parts. It uses just enough:
- Astro for static routing and rendering
- Tailwind utilities and custom tokens for consistent styling
- a small set of interactive scripts where they actually improve the experience
- Markdown-backed content for the blog
That makes the codebase easier to evolve. The next features are obvious: refine blog content, add more posts, possibly introduce richer post metadata, and tighten page-level polish where it matters. None of those require undoing the current architecture.
For a personal site, that is a strong outcome. The codebase is not impressive because it is large. It is effective because its structure reflects the job the site actually needs to do.