Building a Portfolio That Explains the Engineering Behind the Work

A project list is a useful introduction, but it rarely answers the questions I want an engineering portfolio to answer. What problem did the project address? Why was a particular approach chosen? What can someone actually use today, and what still needs work?

I built my personal portfolio, Sanfor, around those questions. The site brings together project writeups, technical articles, professional context, and an original art archive. My focus is systems and backend engineering, Linux, networking, and performance. The portfolio gives that work somewhere to be explained.

The problem: a stack does not explain a decision

Technology names are compact. That makes them convenient for cards and resumes, but they leave out the part that makes a project interesting.

Two applications can use the same framework and solve very different problems. A local authoring tool has different storage assumptions from a shared hosted service. A background worker needs a failure story as well as a happy path. Those distinctions cannot be communicated by listing TypeScript or a database.

The goal for this site was to provide room for that context without making the first visit feel like opening a manual. A visitor should be able to scan, pick a project, and then choose how deeply to read.

The method: give different questions a clear home

The site has five main destinations: About, Projects, Writing, Art, and Contact. Each answers a different question.

Projects explains what the work is. Writing gives more space to a specific investigation or decision. About provides professional context, while Contact offers public channels for a conversation. Art makes room for another part of my practice and keeps the portfolio personal.

The home page is intentionally brief. It establishes the name and engineering focus, then points to those destinations. The detailed explanations belong on the pages where someone has chosen to read them.

This separation also helps with editing. A short project description does not need to contain every technical lesson, and an article can focus on one question without repeating the whole biography.

Keep the content connected through Astro

The implementation uses Astro with Markdown content collections. Projects and blog posts have separate schemas because they need different metadata. A project includes role, status, and stack; a blog post requires a category and a cover image with alternative text.

Those entries feed the pages and their surrounding reading paths. A blog article has an individual page, an index entry, topic archives, and an RSS item. A sitemap is generated as part of the static build.

The practical result is that adding a content entry does not mean separately authoring every place that points to it. The data is shared, while the presentation can adapt to the index, archive, or article page.

That does not make publication automatic in every sense. The current site filters entries using a draft flag. A future publication date does not schedule a release. Writing that rule down matters because the visible frontmatter can otherwise suggest a feature that is not implemented.

Use a project to explain a concrete tradeoff

One current article looks at 360Vision, a local studio for connected panorama tours. The useful story is not simply that the application uses Next.js and Three.js.

The article explains why panorama hotspots use angular yaw and pitch, while floor-plan points use percentages. It also describes local JSON persistence and the difference between downloading a JSON document and backing up its referenced images.

Those details connect a design decision to a consequence. The reader can see the coordinate problem, the representation chosen to handle it, and the behavior that representation makes possible. The backup discussion also names a limit instead of implying complete media portability.

Another article discusses queues and background work. Its value comes from explaining retries, duplication, observability, and recovery. These are examples of the kind of reasoning I want the writing section to preserve.

Give the site a recognizable visual language

The design uses warm paper colors, orange accents, visible borders, large headings, and compact technical labels. The original logo, portrait, and art give the presentation continuity with the person behind the work.

There are light and dark themes and optional music controls. The player persists through internal navigation, which means browser initialization and persistent state still need attention even on a statically generated site.

These details are part of the experience, but the core content must remain understandable without playing audio or inspecting a hover effect. The writing, navigation, and descriptions carry the meaning.

The result and the remaining work

The current portfolio contains seven project writeups and four articles. A visitor can start from a project, follow a related explanation, read about the author, and find a public contact channel. Those are observable capabilities, not a claim about hiring outcomes or traffic growth.

Several project summaries are still short. There are also opportunities to improve auxiliary page consistency, image delivery, and small interaction details. A portfolio is an ongoing publishing practice, so the next improvement is often a clearer explanation rather than another visual effect.

My takeaway is to make the connection between problem, implementation, and result easy to follow. It gives a reader something more useful to assess than a stack list, and it gives me a structure for documenting the next project.

Explore Sanfor and pick one project to start with. What information makes an engineering case study useful to you?