Software Developer CV Guide for Zambia in 2026

Three years ago I spent a weekend rebuilding my CV using one of the popular CV design sites. I was proud of it. The colours matched, the layout was clean, the sections balanced. I sent it out and it got me interviews it probably wouldn't have got me before. A year later I built a portfolio site to go with it, and I was prouder still.

Today I don't actively maintain either, and my CV is doing more work than it ever did.

This isn't a story about how design tools and portfolio sites stop mattering. They mattered when I needed them. It's a story about how the way you present yourself professionally has to change as your career changes — and how most career advice ignores this entirely, leaving Zambian professionals stuck in habits that worked when they were students but quietly stop working once they're not.

Here's what changed for me, when, and why.

The three stages most Zambian professionals move through

Looking back, my CV went through three distinct stages, and almost everyone I've watched build a software career in Zambia has moved through some version of the same progression.

Stage 1: The Word document CV. This is the student or fresh graduate stage. Times New Roman or Calibri, two pages, your education at the top, a Skills section listing every programming language you've ever opened a file in, a Hobbies section that mentions reading and football. It looks like everyone else's CV at UNZA, CBU, or Mulungushi because it is everyone else's CV. And honestly, that's fine for entry-level applications. Recruiters reviewing graduate roles aren't expecting a polished personal brand. They want to see if you can write coherently and if you finished your degree.

Stage 2: The polished designer CV plus portfolio site. This is the early-career upgrade. You've been working a year or two, you've started caring about how you present yourself, and you redesign your CV using one of the modern CV design tools because the Word version suddenly feels embarrassing. Around the same time, you build a portfolio site. It has your face on the homepage, a short bio, a list of skills with little progress bars, and three or four projects: a clone of a familiar app, a hackathon submission, maybe a static site you built for someone in your family. The site is your evidence that you're not just a fresh graduate anymore. You've moved past Stage 1.

This is where most Zambian software developers I know land — and stay. Stage 2 is comfortable. The portfolio site sits on Vercel or Netlify for free, you update it occasionally, and recruiters can click around and see that you exist as a coder. It works. For a while.

Stage 3: The CV with production URLs. This is the stage almost nobody writes about, because it's the stage where the rules change.

At some point, if you keep working, you stop building demonstrations of what you can do and start building things that actually work for actual people. You ship something that runs in production. It has users. It solves a problem someone has. Maybe it's a website for a client who pays you. Maybe it's a tool you built for yourself that other people started using. Maybe it's an internal product you can talk about even if you can't share the code.

When that happens, your CV evolves again. Skills lists shrink because the production work makes them obvious. The Projects section stops being a list of GitHub repos and becomes a list of URLs. Recruiters click the URLs and see real software running.

The portfolio site, meanwhile, becomes optional. Sometimes redundant. Occasionally a liability if it hasn't been updated since Stage 2.

Why the portfolio site loses importance once you're shipping real work

A portfolio site exists to show what you can do when you don't yet have evidence of what you have done. Once you have evidence, the showcase becomes redundant.

Concretely: a portfolio site says "here's a clone of Twitter I built to show I understand React." That's useful when you're 22 and have no other evidence. But a CV link to a job board running in Lusaka, used by Zambian job seekers and employers, says something different. It doesn't say I can build software. It says I have built software, it's running, people use it, and you can verify all of that by clicking the link. Different category of thing.

Recruiter behaviour changes too. A recruiter reviewing a 22-year-old wants to see capability — can this person actually code? A portfolio site is a good answer to that question. A recruiter reviewing a 28-year-old with five years of experience wants to see judgment, ownership, and shipped impact. A live URL to a working application demonstrates all three at once. A portfolio site with three React clones demonstrates none of them at this stage. It can actually hurt — it suggests the candidate hasn't progressed past where they were three years ago.

This is the part that took me too long to figure out. I spent time updating my portfolio site that I should have spent shipping new work.

What goes on your CV at this stage — and what doesn't

When you start putting URLs on your CV, you have to think carefully about which URLs you can actually use. Not every project you've worked on is yours to claim.

What you can put on your CV:

• Applications you built for yourself, like ZedHires, where we control the code and the brand
• Applications you built for your own clients — the climate change researcher who needed a site to share data publicly, the political client who needed temporary infrastructure during election season, the small business that hired you to build their internal tool
• Open source projects you maintain
• Personal blogs or sites you've designed and run
• Templates or assets you sell on platforms like ThemeForest
• Side projects that became something

The common thread is: you own the IP, or you have explicit permission from the person who does.

What you should not put on your CV:

• Internal applications you built at your day job
• Code you wrote under an employment contract that assigns intellectual property to your employer
• Client work where the contract specifies non-disclosure
• Anything where listing it publicly would breach a confidentiality clause you signed

This matters in Zambia because employment contracts here don't always make IP terms explicit, but the legal default still applies. If your employer paid you to build something, that something usually belongs to them, not you. Listing it on your public CV with a URL is asking for trouble — and even when there's no legal action, it damages your professional reputation when found.

The good news: you can still describe your day-job work. A CV can say Architected a JSONB-based health surveillance platform processing X records across Y facilities without giving the URL or the employer name. That's still legitimate, still impressive, and still safe. The portfolio links are a separate enhancement, not a replacement for describing your full work history.

The clearest rule I follow: list things you can defend. If a recruiter calls and asks "tell me about this project on your CV," you should be able to talk about it freely without worrying about who owns what.

Side hustles become portfolio (and pay for the infrastructure)

This is the part of my CV evolution I didn't expect: side hustle clients turn into portfolio.

The pattern looks like this. You take on a side project. Maybe an environmental scientist needs infrastructure to share research data. Maybe a political campaign needs temporary digital infrastructure for the months before an election. Maybe a small business needs a custom solution that off-the-shelf software doesn't quite fit. You ship it. You get paid. The site or application goes live.

Three things happen at once: you get income, you get experience, and you get a URL you can point to.

The economics also matter. Side hustle income lets you keep paying for your VPS, which lets you host your own projects, which lets you take on more side hustle work. The whole loop becomes self-funding. I run my own server with a workmate; the side hustle clients we take on between us are part of how we keep that infrastructure paid for. Some of those projects make it onto our CVs. Some don't, depending on the client and the contract.

A few things I've learned about side hustles as portfolio:

Not every project becomes a portfolio piece. Some clients want their work kept private. Some projects don't last long enough to point to. Some weren't worth the trouble. That's fine — the ones that do work compound.

Temporary projects can still count if you frame them honestly. The political campaign site that lived for six weeks during election season and came down cleanly afterwards is still a real thing you built. List it with the dates: Designed and deployed campaign infrastructure for a national political client. Ran in production July–August 2026, served Y thousand visitors, decommissioned cleanly post-election. That's a credible CV line even though the URL no longer resolves.

Always-on projects matter most. The site you built two years ago that's still running because your client still needs it — that's the strongest evidence you can offer. It says I built something durable enough that someone is still paying me to keep it alive. Few things impress recruiters more.

Keeping your CV current is the actual job

Here's the part that nobody likes to hear: a great CV that hasn't been updated in 18 months is worse than a mediocre CV that was updated last week.

A CV updated last month says this person is actively shipping things and pays attention to how they're seen. A CV last touched in early 2025 says this person either hasn't done anything notable in two years, or they don't bother to maintain their professional materials. Recruiters draw conclusions from this even when the candidate is brilliant. The dust on your CV is itself a signal.

The same applies to portfolio sites. A portfolio site whose latest project is from 2022 actively damages your application. It says I cared about my professional presence in 2022 and stopped caring after. Better to delete it than to leave it stale. An archived portfolio site is silent; a stale one is loud and embarrassing.

The practical rule I've adopted: every time I ship something significant, I update my CV that same week. Not eventually, not when I'm job hunting, that same week. If I can't do this consistently for a portfolio site too, I don't keep one. Right now I don't.

The other rule: your CV should always reflect the strongest work you've done in the last 18–24 months. Older work gets compressed into shorter bullet points. Newer work gets prominence. This requires active editing, not just adding to the bottom.

What my own setup looks like right now

To make this concrete, here's where I'm at:

My CV currently lists my day-job work in compressed form — describing the systems I've built without linking to internal URLs that aren't mine to share. It lists ZedHires as a co-founded side project with a public URL. It lists side hustle projects with live URLs where I have client permission, and dated descriptions for ones that ran temporarily.

I don't currently maintain a standalone portfolio site. The shipped applications I can point to do the work that a portfolio site used to do for me. ZedHires alone — a working job board with real users, real listings, real infrastructure — communicates more about what I can build than any portfolio page would.

I'm planning to build a personal site when I launch on ThemeForest, where I'm preparing to sell React-based WordPress templates. That site has a different job: it's commercial, not showcase. It exists to sell templates, not to demonstrate that I can write JavaScript. When that's the function, a personal site becomes useful again — but for a different reason than the Stage 2 version.

This is the broader point: portfolio sites become valuable when they're commercial assets, not when they're showcases. Once your shipped work is the showcase, your personal site needs a separate justification to exist.

A practical framework

If you're a Zambian software developer trying to figure out where you are in this progression, here's how I'd think about it:

• If you have zero to two years of experience, invest in the portfolio site. You need it. Build it well, keep it current, fill it with evidence of capability. This is your Stage 2 and you can't skip it.
• If you have two to five years of experience, keep the portfolio site but start replacing showcase projects with shipped work. Move from clones to client work, from class projects to live applications. Real users beat clean code at this stage. The portfolio site is still earning its keep, but only if it's evolving.
• If you have five or more years of experience, ask honestly whether your portfolio site is doing more work than your CV. If not, kill it or repurpose it. Let your shipped applications speak. Trust your URLs more than your design.

Whatever stage you're in, update everything when you ship. Never let your CV go more than six months without revision. Never let your portfolio site, if you keep one, fall more than three months behind your actual work.

The Word doc CV I wrote eight years ago wouldn't get me an interview today. The polished designer CV from three years ago wouldn't either. Not because they were bad — they were appropriate for who I was when I made them. But what employers want to see has shifted as my career has shifted, and the materials had to shift with it.

Don't stay frozen at the stage that worked once. Let your CV grow up with you.

If you're searching for your next role, browse current openings at ZedHires. If you're evaluating an offer, our PAYE calculator will help you see what you'd actually take home each month.

Bright Kapamulomo is a software engineer in Lusaka and co-founder of ZedHires.

Comments

Keep reading