For a long time, I was a web developer without a personal website.
Not because I never built one. I had several. Some were decent, some were quick experiments, some died with expired domains. Back in 2019 I even made a simple one just to land my first internship. It worked.
What I did not have was a site that actually represented who I am now.
And that felt weird.
If you build software for a living but you have no space that reflects your own criteria, it is like being a chef who lives on delivery. Functional, sure. But something does not add up.
The first versions were pretty and empty
My first attempts were purely aesthetic.
I tried glassmorphism. It looked modern and polished. I shipped it fast, with help from AI, and for a brief moment it felt done.
Then the discomfort kicked in.
It was a résumé wearing a costume. Same content as the PDF, just with blur and shine. Good looking, low truth.
Then I tried neumorphism. Even prettier. I let AI drive most of it. It nailed the vibe. Still, after a while I realized I liked the style more than the message.
I was optimizing surface, not meaning.
A side project quietly changed everything
While I was stuck with the portfolio, I started a personal project called TrueStreak. The idea was simple: track gym consistency and make habits visible.
But it became a lab.
I dove into performance, accessibility, analytics, SEO, domain modeling, cloud, serverless. Not as theory. As decisions that had to hold up in a real product.
That is when I made a choice that looked odd from the outside.
I built it with HTML, SCSS, and vanilla JavaScript.
No framework. No TypeScript.
Not out of nostalgia. Out of fit.
A static product with simple flows does not need a cruise ship. It needs clarity, speed, and tolerance for iteration.
The stack served the problem. Not the other way around.
The site stopped being a site and became a tool
As the project grew, the usual friction showed up:
- compiling SCSS
- reusing shared structure across pages
- cache busting assets
- optimizing images
- generating metadata and structured data
- avoiding regressions and broken builds
- making deploy predictable
So I started solving one pain at a time.
Scripts became a pipeline. The pipeline became a builder. The builder became a small system.
I eventually packaged the idea into my own static generator:
SiteForge.
It is not a “framework replacement”. It is a way to eliminate unnecessary complexity while keeping full control over what gets shipped.
If you are curious:
- Portfolio: https://samuelcaetite.dev
- SiteForge demo page: https://samuelcaetite.dev/site-forge
- SiteForge repo: https://github.com/osamucadev/site-forge
The real problem was narrative, not design
When I finished TrueStreak and looked at it running, something clicked.
I had a real product. Something I use. Something that does not depend on context or hype.
Then I revisited my portfolio and noticed a mismatch.
My LinkedIn told the story of someone who has dealt with critical systems, production pressure, real responsibility, and the boring parts that keep products alive.
My website looked like a nice template.
Two different people.
At that moment it became obvious: the problem was not visual. It was narrative.
I did not need another place listing technologies and job titles. I needed a space that shows how I think, how I decide, and what I refuse to compromise.
I changed how I used AI
I stopped asking AI for solutions.
I started asking it for questions.
I shared the HTML and CSS. I explained the discomfort. I asked for critiques, alternatives, and tradeoffs. I used AI as an assistant that accelerates iteration, not as an author that replaces judgment.
That is the key difference.
AI can speed up execution. It cannot replace criteria.
What the current portfolio actually demonstrates
Yes, it is a static website. But it is not a static decision.
This repo exists to demonstrate engineering habits:
- full control over generated HTML, CSS, and JS
- a custom build pipeline focused on real performance metrics
- SEO that is not just “meta tags”, but structure and intent
- cache busting and predictable deploy
- security headers and basic hardening
- separation between source and production output
The goal was not to impress with complexity.
The goal was to ship something fast, quiet, readable, and durable.
In other words, the exact way I like to build software.
Why it took 3 months
Because the hard part was not typing code.
The hard part was deciding:
- what should exist
- what should not exist
- what is noise
- what actually communicates value
- what stays stable as the site evolves
A strong portfolio is not a list. It is a narrative system.
Each section has its own intention. Some need tension. Some need calm. Some need structure. Some need humanity.
The site does not try to prove seniority. It lets you feel it.
The takeaway
I spent 3 months building a static website.
And I would do it again the same way.
Not because it is “hard” or “impressive”, but because it forced me to be honest about what I value:
- clarity over noise
- responsibility over aesthetics
- fit over trend
- maintainability over cleverness
- narrative over buzzwords
If you are building your own portfolio, here is my suggestion:
Do not start with visuals.
Start with what you want to be true about you when someone closes the tab.
Everything else is implementation.
If you want to see the code and the build approach:
Top comments (0)