How many projects should I have in my portfolio?

Two to four is the sweet spot. Two well-built, deployed, documented projects are better than eight half-finished ones. Each project should demonstrate different skills or solve a different type of problem.

Do I need a custom domain for my portfolio?

It helps but is not required. A custom domain (your-name.dev or your-name.com) looks more professional. But your-name.vercel.app or your-name.github.io works fine. The content matters far more than the URL.

Should I include group projects or open-source contributions?

Yes, if you can clearly explain your specific contribution. "I built the authentication system and the payment integration for this team project" is specific and valuable. "I worked on this project with a team" is vague and unhelpful. Open-source contributions, even small ones, show that you can work with existing codebases.

Can my portfolio replace a CV?

Not entirely. Most employers still want a CV for their records and HR systems. But a strong portfolio makes your CV much more compelling. Link your portfolio prominently at the top of your CV. Some hiring managers will spend more time on your portfolio than your CV.

How to Build a Developer Portfolio That Gets Interviews

What hiring managers actually look at

Before building your portfolio, understand what the person on the other side sees. A hiring manager or senior developer reviewing portfolios is usually scanning quickly. They have 20+ applications to review. Here is what they notice.

In the first 10 seconds:

Does the site load? Is it deployed and working? You would be surprised how many developer portfolios are broken or throw errors on load.
What does this person build? A one-line bio and a list of technologies immediately answer this question.
Are there projects to look at? If the portfolio is just a fancy landing page with no projects, there is nothing to evaluate.

In the next 30 seconds (if they are still reading):

Can I click on a project and see it working? Live links matter enormously. A project with a live demo gets 5x more attention than one with only a GitHub link.
Is the code on GitHub? Can I read it? Clean, organised code with readable file names and some structure signals that you think like a professional developer, not just a tutorial follower.
Did this person build something real, or is it a to-do app clone? Projects that solve actual problems (even small ones) signal initiative and practical thinking.

That is the reality. You have less than a minute to make an impression. Everything in your portfolio should be optimized for that window.

Choosing projects to showcase

Quality beats quantity every time. Two or three strong projects are better than eight mediocre ones.

What makes a project "strong":

It solves a real problem. A school fee tracker for Kenyan parents. An M-Pesa payment integration for a small business. A bus route finder for Nairobi commuters. Projects rooted in real problems show that you think about users, not just code.
It works. The live demo loads. Buttons do what they say. Forms submit. Errors are handled gracefully, not with a blank screen. This bar is surprisingly low, yet many portfolio projects fail it.
It demonstrates your skills. Each project should highlight different skills. One project might show front-end work (React, responsive design, animations). Another might show back-end skills (API design, database schema, authentication). A third might show full-stack capability or a specific integration (M-Pesa, Paystack, WhatsApp API).
You can talk about it. In an interview, you will be asked: "Walk me through this project." You should be able to explain why you built it, what decisions you made, what was hard, and what you would do differently.

Project ideas that resonate in the Kenyan market:

A payment integration demo (M-Pesa STK Push with callback handling)
A dashboard for tracking something (sales, inventory, student attendance)
An event booking or ticketing system
A simple e-commerce store with checkout
A content management tool (blog, portfolio CMS)
An API that other developers can use (weather data for Kenyan counties, KCSE grade calculator)

See our guide on project ideas that work well for portfolios for more specific suggestions.

How to structure your portfolio site

Keep it simple. Your portfolio is not the place to show off every CSS trick you know. It is a tool to get you interviews.

Essential sections:

Hero / Introduction: Your name, a one-line description of what you do ("Full-stack developer building for the African market"), and links to your GitHub and LinkedIn.
Projects: 2 to 4 featured projects. Each project card should have: a screenshot or short video, the project title, a one-paragraph description, the tech stack used, a link to the live demo, and a link to the GitHub repo.
About: A short section about you. Not your life story. A paragraph about what you are working on, what you are interested in, and what kind of role you are looking for. Make it personal. "I am a developer in Nairobi focused on building payment integrations for East African businesses" is memorable. "I am a passionate developer who loves technology" is not.
Contact: An email address and links to your LinkedIn, GitHub, and Twitter/X. A contact form is optional. Make it easy for someone to reach you.

Optional sections:

Skills: A list of technologies you actually use. Do not list every technology you have heard of. Only list things you can discuss in an interview.
Blog or writing: If you write technical articles, link to them. Writing demonstrates communication skills and deep understanding. But only include this if you actually write. An empty blog section looks worse than no blog section.
Experience: If you have work experience, a brief timeline. If not, your projects speak for you.

Technical choices for the portfolio itself:

Build it with the same technologies you want to be hired for. If you are targeting React jobs, build your portfolio in React or Next.js. The portfolio itself becomes a demonstration of your skills.
Make it fast. Optimize images. Minimize JS. A portfolio that takes 5 seconds to load on Kenyan mobile data is a bad first impression.
Make it responsive. Many recruiters will open your link on their phone first. If it is broken on mobile, they will not switch to a laptop to give you another chance.
Deploy it on Vercel, Netlify, or GitHub Pages. Use a custom domain if you can afford one (a .dev or .com with your name). Your-name.vercel.app works too.

How to present each project

The difference between a portfolio that gets callbacks and one that does not is often in how projects are presented, not what projects are included.

For each project, include:

A clear title: "M-Pesa Payment Dashboard" is better than "My Project 3".
A one-paragraph description: What the project does, who it is for, and why you built it. "A dashboard that lets small business owners track M-Pesa payments in real time. Built for a hardware shop in Kawangware that was managing transactions on paper."
The tech stack: List the technologies clearly. "React, Node.js, Express, PostgreSQL, Daraja API, deployed on Railway."
A screenshot or demo video: A 30-second screen recording showing the app in action is more compelling than any description. Use Loom or a screen recorder. Embed the video or GIF directly on the portfolio page.
Live link: The project should be accessible on the internet. If it requires credentials, create a demo account with test data and share the login details.
GitHub link: The repo should have a README that explains how to run the project locally. Include setup instructions, environment variable documentation, and any prerequisites.
What you learned: One or two sentences about what was challenging and what you learned. "This was my first time handling M-Pesa callbacks. I learned about webhook security and idempotent payment processing." This level of reflection shows maturity.

Common portfolio mistakes to avoid

These are patterns that weaken portfolios. If you see yourself in any of these, fix it before sending your portfolio to employers.

Too many tutorial projects. A to-do app, a calculator, a weather app, and a counter. These are fine for learning, but they do not belong on a portfolio aimed at employers. They show you can follow instructions, not that you can think independently.
Projects that do not work. Broken links, login screens with no demo credentials, APIs that have expired, pages that crash on load. Test every project on your portfolio before sending it out. Test it on mobile too.
No live demos. A GitHub repo without a live link forces the reviewer to clone and run your code. They will not do that. Deploy everything.
Over-designed, under-built. A gorgeous portfolio with parallax scrolling and 3D animations, but the projects are basic HTML pages. The design of your portfolio matters less than the substance of your projects.
Listing skills you cannot back up. If your portfolio lists "Docker, Kubernetes, AWS, Terraform" but your projects are all deployed on Vercel with no infrastructure work, the interviewer will notice the disconnect.
No personality. Your portfolio should have a voice. You are a person, not a template. A sentence about what you care about, a specific problem you want to solve, or a brief mention of your background makes you memorable.
Outdated information. Projects from 3 years ago that use deprecated technologies and have not been updated. Either update them or remove them. A portfolio with 2 current projects is better than one with 6 stale ones.