A portfolio can be a gallery.
It can also be a system.
The difference is not always visible at first. Both can have nice project cards, a good hero section, a contact page, and a few polished interactions. But underneath the surface, they are very different things.
A gallery is mostly arranged.
A system is designed to grow.
That was the mindset I wanted for this portfolio. I did not want every section to feel like a one-off composition. I wanted the site to have repeatable patterns: cards, headings, page rhythm, metadata, animation behavior, content structure, and visual rules that could keep expanding without falling apart.
pages are not the real product
The obvious output is the page.
The real product is the set of decisions that make the page possible.
A project page is not just a route. It depends on data shape, image rules, SEO metadata, card layout, navigation, content hierarchy, status badges, and the way the page connects back to the rest of the site.
A blog page is similar. The article is the visible part, but the system around it matters just as much:
- how posts are written
- where images live
- how metadata is validated
- how cards are generated
- how article pages are rendered
- how recent posts appear across the site
- how SEO and sitemap entries are handled
When those parts are intentional, the portfolio becomes easier to maintain.
custom does not mean chaotic
A common trap with personal sites is treating every section as an isolated artboard.
That can look interesting in the short term, but it often becomes difficult to update. Every new piece of content requires a new layout decision. Every small change has to be made in multiple places. The site gets more fragile over time.
I wanted the opposite.
The design should feel highly tailored, but the implementation should still have structure.
That is why patterns matter.
The project cards define one kind of visual language: large rounded containers, strong images, soft overlays, metadata, and small animated affordances. The blog cards build from that same language, but adapt it into something more editorial.
They do not need to look identical.
They need to feel related.
the card became a design anchor
Cards are one of the strongest patterns in this portfolio.
They do a lot of work:
- they carry imagery
- they create rhythm on long pages
- they make content scannable
- they support animation
- they establish the rounded, tactile visual style
- they give the site a product-like feeling
For the blog system, I wanted the cards to feel less like generic article previews and more like designed content objects.
That is why the blog card uses:
- a rounded image block
- tags sitting inside the image
- a centered visual symbol
- title and description below the image
- reading time and publication metadata
- a small arrow interaction for reading
content needs rules too
MDX gives a lot of freedom.
That freedom is useful, but it also needs boundaries.
Without rules, content becomes inconsistent quickly. One post might have a cover image. Another might not. One might use tags. Another might forget them. One might be published accidentally before it is ready.
So the blog system needs a clear content contract.
Every post should have:
- a title
- a description
- a publication date
- a cover image
- descriptive image alt text
- tags
- draft support
- optional featured status
That contract makes the UI more reliable because the components can trust the data they receive.
images should be organized by post
For blog images, I prefer a folder per post.
That keeps the public folder clean and makes the relationship between a post and its assets obvious.
The structure is simple:
- one folder per article
- one required cover image
- optional supporting images
- image paths referenced directly from frontmatter or MDX
This keeps content portable. If a post moves, its assets are easy to find. If an image breaks, the source is obvious.
MDX should feel designed
The point of using MDX is not just to write markdown inside a React app.
The real value is being able to mix writing with custom components.
That means an article can include:
- callouts
- custom image blocks
- project references
- stack lists
- two-column sections
- styled code blocks
- future embeds or demos
This matters because a portfolio blog should not feel like a plain document pasted into a website. It should feel like an extension of the portfolio's design system.
the system should connect across pages
The blog is not only the /blog page.
It should show up in other parts of the portfolio too.
The homepage can show recent writing.
The about page can show personal reflections.
The projects page can lead into technical breakdowns.
Individual blog posts can reference projects.
Project pages can eventually reference related articles.
That makes the whole site feel more connected.
Instead of separate destinations, the portfolio becomes a network of work, writing, process, and personality.
motion has to respect the system
Because this portfolio already uses GSAP and smooth scrolling, any new blog UI needs to follow the existing animation philosophy.
That means:
- reversible timelines for hover interactions
- restrained scroll-based movement
expo.outorpower3.outeasing- small image parallax instead of aggressive motion
- staggered card entrances
- no duplicated animation loops
- animations that support the content rather than distract from it
Motion should make the blog feel alive, but not noisy.
A reader should still feel like they are reading.
what this unlocks
Once the blog system exists, adding new writing becomes much easier.
A new post is just:
- create an MDX file
- add frontmatter
- place images in
public/blog/post-slug - write with markdown and custom components
- publish by setting
draft: false
The rest of the system handles the listing page, preview cards, article route, metadata, recent posts, and sitemap.
That is the value of building the foundation properly.
the bigger lesson
The more I build, the more I appreciate systems that make good decisions easier.
A strong system does not remove creativity. It gives creativity a reliable structure to move through.
That is what I want this portfolio to become.
Not just a place where finished work is displayed.
A place where projects, writing, experiments, and lessons can keep growing together without losing the visual identity that makes the site feel personal.
The goal is not just to have a blog.
The goal is to have a publishing system that feels like it belongs here.
