Building a portfolio is not just about putting your work out there. It is about showing how you think. In this post I am walking you through the entire process — from the first rough sketch on my notepad to finally deploying it live — and what went into every decision along the way.
Why I Even Built One
I have been working as a frontend engineer for a while now, and I also do UI/UX design as part of my job. So when I decided to build a portfolio, I did not want it to look like one of those generic developer sites with a hero section and a list of projects. I wanted it to actually feel designed — subtle animations, clean layout, the kind of thing where someone opens it and thinks “okay, this person clearly cares about how things look.”
That was the goal from day one.
Step 1 — Figuring Out the Content First
Before touching Figma or writing a single line of code, I sat down and figured out what I actually want to say and show. A lot of people skip this and jump straight to design. I have done that before and it always creates problems later.
So I listed down all the sections — who I am, my work experience, my tech stack, my projects, contact — and then thought hard about the order. The order matters more than people realise. You are basically telling a story, and the flow has to make sense to someone who knows nothing about you.
Once I was happy with the content structure, I moved forward.
Step 2 — Looking for Inspiration
I spent a good amount of time on Dribbble and Behance just browsing. Not to copy anything, but to understand what was working visually. I was particularly looking at portfolios and product design work — how people were using whitespace, typography, motion.
After browsing for a bit, I closed everything and pulled out my notepad. I sketched out a few rough layouts by hand. Nothing fancy — just boxes and lines to understand the composition. I went through maybe three or four versions before landing on something I liked.
The direction I settled on was minimalist. Clean. No unnecessary decoration. Let the content and the small details do the work.
Step 3 — Setting Up the Design System in Figma
This is the part most people either skip or do carelessly, and then they regret it halfway through the design process.
I started with the foundation — colour variables, typography scale, spacing tokens, and then built out the reusable components like buttons, cards, tags, and navigation. I also collected all the images and assets I would need and organised everything properly.
Only after this foundation was solid did I start designing section by section. Going section by section helped me stay focused and also made it easier to keep things consistent throughout. If I had tried to design everything at once it would have become a mess.
By the end I had a complete high-fidelity design that I was actually happy with — which honestly does not happen that often.
Step 4 — Development Setup
For the tech side I went with Next.js using the App Router. It made sense given that I wanted good SEO, fast page loads, and the flexibility to add dynamic pages later.
First thing I did was set up Tailwind CSS and made sure the configuration matched the design system I had built in Figma — same colour tokens, same spacing scale, same font sizes. This is something I feel strongly about. If your code and your design are out of sync, you end up making too many judgment calls during development and the final output drifts from what you designed.
I also set up the fonts and dropped all the public assets into the right folders.
Step 5 — The Data File
One decision I took early that saved me a lot of time later was creating a single data constants file. This file holds all the profile information, project details, experience, and any other content that appears across the site.
Every section just pulls from this file. So if I want to update something — say, add a new project or change a job title — I update it in one place and it reflects everywhere automatically. No hunting through multiple files.
It is a simple pattern but it keeps things maintainable.
Step 6 — Building Section by Section
Same approach as design — I built the layout components first, the things that repeat across pages like the header and footer. Then I went section by section, following the design closely.
This way of working keeps you from getting overwhelmed. You finish one thing, it looks right, and then you move to the next. Progress feels real and the quality stays consistent.
Step 7 — Blogs and Project Detail Pages
For the blog and individual project pages, I used Next.js’s built-in markdown support paired with the Tailwind CSS Typography plugin. This gave me nicely styled long-form content without having to manually style every paragraph, heading, and code block.
I also wrote custom markdown components wherever the default rendering was not enough — things like callout boxes, image captions, and inline highlights. This gave me enough control to make the content pages feel like a proper part of the site rather than an afterthought.
Step 8 — Optimizing for Web Performance with Lighthouse
This is the part that took me the most time, but I am genuinely proud of it.
After the site was mostly done, I ran it through Chrome DevTools Lighthouse and got… let us just say it was not great. Performance was fine-ish, but there were lots of small things dragging it down. Unused CSS, unoptimized images, render-blocking resources, things that individually do not seem like much but together add up.
So I went through the checklist. I optimized all images using Next.js Image component with proper sizing. I removed unused CSS by purging Tailwind. I deferred non-critical JavaScript. I made sure critical fonts were preloaded. I implemented proper caching headers. It took me a few days of tweaking and testing.
And then one day I ran Lighthouse again and got 100 across all four metrics — Performance, Accessibility, Best Practices, and SEO. All four sections. Not 98, not 99. 100.
That felt really good, not gonna lie.
Step 9 — SEO
I left SEO for the end but I did not treat it lightly. I went through the full checklist.
I wrote the manifest file, created the sitemap and robots.txt, added proper metadata to every page, set up JSON-LD structured data for rich results, and added the Google Search Console verification token. These are the things that take maybe a few extra hours but make a real difference in how search engines understand and rank your site.
Step 10 — Domain and Deployment
I bought my domain from Cloudflare. Their domain pricing is straightforward and they do not charge renewal at inflated rates the way some registrars do.
For deployment I used Vercel. With Next.js, Vercel is the obvious choice — zero configuration needed, deploys on every push, and performance is solid out of the box. The whole deployment took about ten minutes.
And that was it. praveennetinti.dev was live.
What I Would Tell Anyone Building Their Own
Plan your content before you open any design tool. Spend real time on the design system — it makes both design and development faster and more consistent. Keep your data centralised. Run Lighthouse regularly during development, not just at the end. And do not skip SEO at the end, it is not that much work once the site is built.
A portfolio is one of those projects where you are both the designer, the developer, and the client. That is what makes it hard and also what makes it satisfying when it finally comes together.