Building a Personal Portfolio Website
From domain purchase to production deployment.
End-to-end product journey • Frontend engineering • Hosting & deployment
Overview
This project documents the full lifecycle of building, deploying, and iterating on my personal portfolio website. Instead of using a no-code template, I intentionally chose a developer-first stack to gain practical experience in architecture, version control, hosting, DNS, deployment pipelines, and production debugging.
The outcome is a scalable, recruiter-friendly website that reflects both technical and analytical thinking, while remaining easy to expand as new projects and milestones are added.
Motivation & goals
- •Build a central professional hub to showcase projects, experience, and academic work.
- •Learn how real-world websites are deployed and maintained.
- •Gain hands-on experience with modern frontend workflows.
- •Understand hosting, DNS, environments, and deployment issues beyond local development.
- •Create a scalable structure to add new projects over time.
Process & journey
1) Domain purchase & identity setup
Bought a personal domain on Swizzonic and configured DNS records (CNAME/A records) to connect it with Vercel hosting. This introduced real-world delay and misconfiguration challenges early.
▼
1) Domain purchase & identity setup
Bought a personal domain on Swizzonic and configured DNS records (CNAME/A records) to connect it with Vercel hosting. This introduced real-world delay and misconfiguration challenges early.
This step marked the transition from a local development project to a real, publicly accessible website. I learned the practical difference between domain registration and hosting, and how DNS records function as the routing layer between them. Configuring CNAME and A records required precision, and even small mistakes resulted in the site being temporarily unreachable.
The process also exposed me to DNS propagation delays, which reinforced that infrastructure changes are not always instant and require patience and verification rather than repeated trial-and-error changes.
2) Repository & version control strategy
Structured the project in GitHub from day one to work incrementally, track changes cleanly, and keep deployments tied to repository state.
▼
2) Repository & version control strategy
Structured the project in GitHub from day one to work incrementally, track changes cleanly, and keep deployments tied to repository state.
Using GitHub as the single source of truth allowed me to build the website step by step, commit meaningful changes, and safely experiment without risking permanent breakage. This approach reinforced the importance of clean folder structures, consistent naming, and disciplined commits.
It also helped me understand how closely deployment behavior is tied to repository state, making version control not just a collaboration tool, but a core part of the deployment pipeline.
3) Local development vs production reality
Resolved issues that only appeared in production, including case-sensitive image paths, routing mistakes, and missing static assets from /public.
▼
3) Local development vs production reality
Resolved issues that only appeared in production, including case-sensitive image paths, routing mistakes, and missing static assets from /public.
Several components worked flawlessly in local development but failed once deployed. These issues highlighted differences between local file systems and production environments, particularly around case sensitivity and asset resolution.
Debugging these problems improved my understanding of how Next.js handles routing and static assets in production and taught me to test assumptions instead of trusting local behavior alone.
4) Deployment with Vercel
Used automatic builds on push, analyzed build and runtime logs, and learned that successful deployment status does not always guarantee a working page.
▼
4) Deployment with Vercel
Used automatic builds on push, analyzed build and runtime logs, and learned that successful deployment status does not always guarantee a working page.
Vercel’s automated deployment pipeline made iteration fast but also exposed hidden issues. I learned to interpret build logs, identify runtime failures, and trace problems back to specific imports or configuration errors.
This reinforced the idea that deployment is not a final step but an ongoing feedback loop that requires monitoring, validation, and careful testing after each change.
5) Modular structure for scalability
Moved from a single-page mindset to reusable layouts and dedicated routes for projects, education, experience, and credentials.
▼
5) Modular structure for scalability
Moved from a single-page mindset to reusable layouts and dedicated routes for projects, education, experience, and credentials.
As the site grew, maintaining everything on one page became impractical. Refactoring into modular layouts and dedicated routes made the site easier to maintain and extend.
This change improved consistency across sections and ensured that adding new projects or experiences in the future would require minimal structural changes.
6) Visual assets & placeholders
Balanced design quality and technical simplicity by introducing consistent placeholders and reliable asset organization across environments.
▼
6) Visual assets & placeholders
Balanced design quality and technical simplicity by introducing consistent placeholders and reliable asset organization across environments.
Handling images introduced unexpected complexity, from broken paths to inconsistent rendering between environments. To solve this, I standardized asset locations and introduced neutral placeholders where final visuals were not yet available.
This approach preserved visual consistency while keeping the technical setup simple and robust.
7) Iterative debugging and improvement
Fixed broken routes, missing assets, import issues, and responsive styling gaps incrementally instead of restarting the project.
▼
7) Iterative debugging and improvement
Fixed broken routes, missing assets, import issues, and responsive styling gaps incrementally instead of restarting the project.
Rather than rebuilding from scratch when issues arose, I addressed problems one at a time and verified each fix before moving on. This improved my debugging discipline and confidence in reading error messages and logs.
Over time, this iterative approach mirrored real-world software maintenance practices and reinforced the value of persistence and structured problem-solving.
Key challenges faced
- •DNS configuration and domain linking confusion
- •Image paths breaking due to case sensitivity
- •404 errors from incorrect route structure
- •Deployment succeeding while runtime pages still failed
- •Balancing aesthetics with maintainability
- •Avoiding repetition while keeping content rich
What I learned
- •How domains, hosting, and deployments work together in practice.
- •Why version-control discipline is critical for safe iteration.
- •How small inconsistencies can break production builds.
- •How to debug systematically instead of guessing.
- •How to design for long-term scalability, not just first release visuals.
Outcome & why this matters
The website is now fully deployed, continuously maintainable, and structured as a living product rather than a static assignment. It demonstrates ownership across the entire digital lifecycle — from domain decisions to deployment quality and ongoing iteration.
Unlike predefined coursework, this project had no fixed template and no single correct answer. Every visual and technical choice was deliberate, making it one of the clearest reflections of my real-world problem-solving approach.