Context
What needed to change
This portfolio is my first professional project and the place where my work needs to earn trust quickly. Instead of treating it as a static personal page, I approached it as a product: it needed clear positioning, a usable work index, structured project pages, public contact paths, and a deployment path that could keep improving over time.
Constraints
What shaped the solution
- The project needed to be honest about scope because it is a self-directed portfolio, not client work.
- The site had to communicate frontend quality through the product itself: layout, performance, accessibility, routing, content structure, and polish.
- The architecture needed to stay simple enough to deploy reliably through GitHub and Hostinger.
- Public content had to be easy to update as new projects, links, and professional information are added.
- The interface needed to feel professional without relying on heavy animation, generic templates, or unsupported claims.
Goals and non-goals
What success looked like
- Goal: turn the portfolio itself into a credible first project in the Work section.
- Goal: make the site explain who I am, what I build, how I think, and how to contact me.
- Goal: use a reusable case-study system so future projects can be added without redesigning the site.
- Goal: include production basics such as SEO metadata, sitemap, robots, responsive layout, and accessible navigation.
- Non-goal: present the project as commercial client work or invent metrics that do not exist yet.
- Non-goal: overbuild the first version with a CMS, database, or complex backend before the portfolio needs one.
Approach
How the work was structured
I built the portfolio around a small but durable content system. The public pages use Next.js App Router, shared UI primitives, MDX case studies, and a site configuration file for global content like navigation and contact links. The Work section reads from the same project files that power the detail pages, so the portfolio can grow through content instead of repeated page rewrites.
Key decisions
Trade-offs that shaped the outcome
Present the portfolio as a real project
- Option A
- Hide the portfolio build and wait until there are external projects.
- Option B
- Publish the portfolio itself as the first project, with honest scope and clear technical decisions.
- Chosen path
- Publish the portfolio itself as the first project.
- Reason
- The site demonstrates real frontend work: product framing, layout systems, content modeling, accessibility, SEO, and deployment.
Consequence
The Work section has a concrete first case study without pretending it is client work.
Content structure
- Option A
- Hardcode each project page directly in route components.
- Option B
- Use MDX files with typed frontmatter and shared rendering.
- Chosen path
- MDX files with typed frontmatter.
- Reason
- Future projects should be added by editing content, not by rebuilding the route structure every time.
Consequence
The portfolio now has a repeatable case-study format for this project and future work.
Deployment path
- Option A
- Keep the site as a local prototype.
- Option B
- Connect the repository to a real hosting flow through GitHub and Hostinger.
- Chosen path
- GitHub and Hostinger deployment flow.
- Reason
- A professional portfolio should be published, maintainable, and easy to update after each improvement.
Consequence
Small updates like contact links, new projects, and SEO fixes can be shipped through the same workflow.
Visual direction
- Option A
- Use decorative effects to make the first project feel bigger.
- Option B
- Use restrained typography, spacing, interaction states, and content density.
- Chosen path
- Restrained visual system.
- Reason
- For a professional frontend portfolio, credibility comes from clarity and execution quality more than visual noise.
Consequence
The site feels calmer, easier to scan, and more aligned with product UI work.
Implementation highlights
How the system was built
- Built a multi-page portfolio with homepage, Work, About, Contact, and dynamic case-study routes.
- Added a reusable MDX content model for project pages, including ordered sections, tags, stack, role, scope, timeline, and publish state.
- Created shared UI primitives for layout, cards, links, buttons, sections, tags, and case-study blocks.
- Added public contact paths for GitHub and LinkedIn through the shared site configuration.
- Generated production SEO assets through static
robots.txtandsitemap.xmlfiles. - Kept the site deployment-friendly for Hostinger by using a lean Next.js Node build instead of extra infrastructure.
Results
What the work achieved
- The portfolio now has a published Work entry called Portfolio Website that explains the project behind the site itself.
- The public site can be updated through GitHub and redeployed through Hostinger as the portfolio grows.
- The Work section, featured project area, and case-study detail page all read from the same content source, reducing drift.
- The project demonstrates practical frontend skills through a live artifact rather than only listing technologies.
- The foundation is ready for future projects, stronger proof, screenshots, and more personal career information over time.
Gallery
Artifacts and checkpoints
Artifact
Work entry for the site itself
The portfolio is now represented as a real project instead of only acting as a container for future work.
Outcome: the first project has an honest, inspectable story.
Artifact
Reusable case-study system
Project metadata and long-form content live in MDX files that can be reused across the Work index and detail routes.
Outcome: future projects can be added without changing the page architecture.
Artifact
Production publishing flow
The site is connected to GitHub and prepared for Hostinger deployment with sitemap and robots assets generated from the project content.
Outcome: improvements can be shipped as the portfolio evolves.
Artifact
Professional contact path
GitHub and LinkedIn links are surfaced in the Contact section so visitors can quickly verify public profiles.
Outcome: lower friction for recruiters, collaborators, and hiring teams.
Learnings
What I would carry into the next iteration
- A portfolio can be a strong first project when the scope is honest and the execution is specific.
- The most important early decision was to build a system that can grow, not just a single polished page.
- Content structure matters as much as visual styling because the site needs to explain decisions without live narration.
- The next upgrades should add more real project evidence, screenshots, and measurable outcomes as the portfolio matures.