How to Build a Software Portfolio That Attracts Remote Employers

Most Nigerian developers we speak to already have code on GitHub. The problem is usually that it's twenty half-finished tutorial clones, no READMEs and a demo link that returns an error. A hiring manager in Berlin or Toronto spends a few minutes on your profile and moves on.

This guide covers what a remote reviewer checks first, which projects to build for frontend, backend, mobile and DevOps roles, and how to write a README that does the selling for you. It also covers how to prove you can work asynchronously from Lagos or Enugu, and the Nigerian problems (sleeping free servers, power cuts, NDA work) that quietly sink good portfolios.

Quick answer

To attract remote employers, pin three to six projects on GitHub that match your target role. Each needs a live demo or short video, a README explaining the problem, your decisions and how to run it, plus tests and a clean commit history. Add at least one contribution to someone else's codebase, such as an open source pull request. Remove secrets, link everything from your CV, and check that every link works before you apply.

Why remote employers rely on your portfolio more than local ones do

A local employer can invite you to the office, sit you beside a senior developer and judge you in an afternoon. A remote employer hiring from another continent has to do most of that from your written application, your code and a few video calls.

That's why the portfolio carries extra weight for remote roles. It answers three questions before anyone speaks to you:

• Can this person build working software in the stack we use?
• Can they explain their work in clear written English to people who will never sit next to them?
• Will they finish things without someone checking on them every hour?

Remote work is common in software, but plenty of companies still expect people in the office. In the Stack Overflow 2025 Developer Survey, 32.4% of respondents said they work fully remotely, and the rest were hybrid, in-person or free to choose. Fully remote roles that accept applicants from Nigeria make up a smaller slice still, so each application has to count.

Some employers say plainly that they want outside evidence of your work. GitLab's published job family for software engineering interns lists "Contributor to open source projects" as a requirement, and its process includes an automated online technical assessment. A good portfolio won't let you skip assessments, but it gets you invited to take them.

What a remote reviewer checks in the first five minutes

Reviewers rarely clone your code on the first pass. They skim. This is roughly the order in which a busy engineering manager or technical recruiter looks at a candidate's links, and what they want to see at each stop.

GitHub lets you pin up to six items (repositories or gists) to the top of your profile. Treat those six slots as your shop window. Anything you don't pin, most reviewers won't see.

The profile README

A profile README appears at the top of your GitHub profile when you create a public repository with exactly the same name as your username and put a README.md file with some content in its root. Keep it short and factual:

• One line on what you build ("Backend developer working in Python and Django, focused on payments and APIs").
• Your time zone and overlap ("Based in Lagos, WAT (UTC+1). Comfortable working UK hours and up to 2pm US Eastern").
• Links to your best two projects, your portfolio site and your LinkedIn.
• How to contact you.

Skip the animated banners, the visitor counters and the wall of 30 technology badges. They take up the space a reviewer would use to understand you.

Choose projects that match the job, not projects that look impressive

The most common mistake is building whatever a YouTube tutorial suggested. A reviewer hiring a React developer gets nothing from your Python scraping scripts, and a backend hiring manager won't judge you on a landing page.

Start from five or six real job ads for the role you want. List the technologies and responsibilities that keep coming up, then build projects that prove exactly those. The table below gives starting ideas by role. Treat them as patterns to adapt, because a project tied to a real problem you understand will always read better than a generic one.

For deeper role advice (skills, courses and the usual path), see the WorkRemote guides for remote frontend developers, backend developers and software engineers in general.

Use Nigerian problems as your edge

You understand some problems better than a developer in Ohio does, and that's useful material for projects. An offline-first mobile app makes sense when your users' connections drop. A payment integration that handles failed and delayed webhooks shows you've thought about real money moving. An SMS or USSD-style flow shows you can design for people without smartphones.

The project doesn't need to be about Nigeria. But a README that says "I built this because mobile data in my area drops several times a day, so the app queues writes locally and retries" tells a reviewer you design around real constraints. Teams with users in emerging markets hire for exactly that.

How many projects are enough

Three strong projects beat ten weak ones. A sensible target for most applicants:

1. One substantial project in your main stack (several weeks of work, deployed, tested, documented).
2. One or two smaller projects that show range within the role (a CLI tool, a library, an integration).
3. One piece of collaborative work: an open source pull request, a team project with real code review, or a contribution to a community tool.

If you're still trying to get your first role, the planned guide on becoming a junior software developer without a job covers how to get that first real experience.

Write READMEs that do the selling for you

The README is where a remote reviewer decides whether you can communicate. Most of your future work will be pull request descriptions, design notes and Slack messages to people several time zones away. Your README is the first sample of that writing.

A README that works for hiring covers these sections, in this order:

1. What it is, in one or two sentences, plus a link to the live demo.
2. Screenshot or short GIF of the main screen or the key flow.
3. Why it exists: the problem and who it's for.
4. Tech stack, with one line on why you chose the main pieces.
5. Key decisions and trade-offs: what you considered and rejected.
6. How to run it locally, with commands that actually work on a fresh machine.
7. Testing: how to run the tests and what they cover.
8. What I'd do next: known limitations and planned improvements.

Section 5 is the one most portfolios skip and the one senior reviewers value most. "I used PostgreSQL rather than MongoDB because orders and payments are relational and I needed transactions" says more about you than any list of badges.

Example (hypothetical): a README opening that works

SettleUp API: a REST API for splitting group expenses and settling balances, built with Django REST Framework and PostgreSQL. Live docs: (link).

I built this after watching friends argue over shared rent and Jollof party contributions. The hard part was rounding: splitting ₦10,000 three ways can't be exact, so the API assigns the leftover kobo to the payer and records it, so balances always reconcile to zero.

Trade-off: I store amounts as integers in kobo, not floats, to avoid rounding errors. I chose server-side settlement calculation over client-side so every app version gets the same result.

That's short, specific, and shows judgement. A reviewer knows within 20 seconds what you built and how you think.

Licence your public repos

If a public repository has no licence, GitHub's licensing documentation explains that default copyright law applies and you keep all rights, so others can't legally reuse your code even though they can view and fork it on GitHub. Adding a standard open source licence such as MIT is a small signal that you understand how open source works. It also matters if you want others to contribute.

Prove you can work remotely, not just code

Many developers can write code. Remote employers need people who can work without a manager in the same room. Your portfolio can show that directly.

Show your Git habits

• Commit messages that explain why: "Fix double charge when webhook retries" rather than "update".
• Branches and pull requests, even on solo projects: open a PR against your own main branch, write a description, and merge it. Reviewers see that you already work the way remote teams do.
• Issues as a to-do list: open issues for planned features and bugs, then close them with PRs that reference them. It shows you can plan and track work in writing.

Contribute to someone else's code

Working in your own repos proves you can build. A merged pull request in another project proves you can read unfamiliar code, follow a team's conventions and accept review comments politely from strangers. For a remote job, that is the actual work.

Start small: documentation fixes, failing tests, issues labelled "good first issue" in tools you already use. One merged PR with a thoughtful discussion thread is worth more than ten typo fixes made only to fill your contribution graph. Reviewers can tell the difference.

Add automated tests and CI

Set up continuous integration (CI) so tests run on every push, using GitHub Actions or a similar service. A green tick beside your commits tells a reviewer, without them running anything, that your code builds and your tests pass. For DevOps and backend roles, the pipeline itself is part of what you're showing.

Mention time zones and async work plainly

Nigeria is on West Africa Time (WAT, UTC+1) all year, with no daylight saving. That puts you one hour ahead of London in winter (GMT) and on the same time in summer (BST), on the same time as Central Europe in winter, and five or six hours ahead of US Eastern. European teams find that easy, and many US teams find a morning overlap workable. Say it on your profile README and portfolio site so a reviewer doesn't have to work it out.

Build a portfolio site, but keep it simple

GitHub alone is fine for many backend and DevOps roles. Frontend, full stack and mobile developers usually benefit from a simple portfolio site, because the site itself is a sample of your work.

A good developer portfolio site has:

• A one-sentence headline that says what you do and for whom.
• Your three best projects, each with a screenshot, two or three lines, and links to the demo and the code.
• A short "about" section with your time zone and the kind of roles you want.
• A contact email (a professional address, not a nickname) and links to GitHub, LinkedIn and your CV.

GitHub Pages hosts static sites (HTML, CSS and JavaScript) straight from a repository, which suits a personal portfolio. According to GitHub's Pages limits documentation, published sites can be up to 1 GB with a soft bandwidth limit of 100 GB a month, and Pages is not meant for running a business, e-commerce site or commercial SaaS. A portfolio is well within those limits.

Buying your own domain name is optional but cheap enough to be worth it if you plan to job hunt for a while. Check current registrar prices yourself before buying.

Fix the Nigerian problems that quietly break portfolios

These are the issues we see most often on portfolios from Nigeria-based developers. None of them is about coding ability, and all of them cost interviews.

Demos that are asleep or broken

Many free hosting tiers put an app to sleep after a period of inactivity, so the first visitor waits a long time or sees an error. Free database trials also expire, and an app that worked in March may be dead by October. Reviewers don't know any of that. They just see a broken link.

• Check every demo link the day you send an application.
• Put a short screen recording (one to two minutes) in the README, so the reviewer still sees the app working if the live demo is down.
• If a demo depends on a paid API key you've stopped paying for, say so in the README and keep the recording.

Power and network cuts during live reviews

Some interviews include walking through your portfolio on a video call. Prepare for an outage: keep your laptop charged, have your inverter, solar or generator ready, and keep a second connection (a MiFi or a phone hotspot on a different network) to hand. Have the screen recordings open in a browser tab so you can share them if your local environment won't start.

Work you can't show because of an NDA

Many Nigerian developers' best work was done for agencies, fintechs or clients under non-disclosure agreements (NDAs). Don't publish that code. Instead:

• Write a case study without confidential details: the problem, your role, the stack, the result (for example, "cut API response time on the checkout endpoint" rather than naming the client and its numbers).
• Rebuild a small, generic version of an interesting piece (a rate limiter, a retry queue) in a public repo, and explain in the README that it's inspired by production work.
• Ask your former manager whether you may mention the company and describe your work at a high level.

Leaked secrets

Never commit .env files, API keys, database passwords or payment keys, even test keys. Add a .gitignore before your first commit, and if a secret has been pushed, rotate it immediately (deleting the file doesn't remove it from Git history). A reviewer who finds a live key in your repo will assume you'd do the same with theirs.

Take-home tests that are really scams

Fake recruiters sometimes send "take-home assessments" as repositories to clone and run, which can contain malware that steals passwords or crypto wallets. Be cautious about running unfamiliar code from a recruiter you haven't verified, preferably do it in a virtual machine or container, and read the install scripts first. Legitimate employers also never ask you to pay for a test or for equipment. The guide to spotting remote job scams in Nigeria covers the other warning signs.

A pinned-repo plan you can copy

Example (hypothetical): a mid-level backend developer in Ibadan targeting European fintech roles might use their six pins like this.

Notice what's missing: forked repos, course exercises, a to-do app and a weather app. Those can stay on the profile unpinned. They're not wrong to have, but they're not evidence for this role.

Connect your portfolio to your application

A great portfolio does nothing if reviewers never open it. Link it where they'll look:

• CV header: GitHub and portfolio links next to your email, as full, clickable URLs.
• Under each relevant job or project on your CV: link directly to the repo, not just your profile.
• Application form "Website" or "GitHub" fields: fill them in even when they're optional.
• Cover letter or application answers: name one project that matches the job and say why in a sentence.
• LinkedIn Featured section: add your best project with a screenshot.

Tailor which project you mention to each application. If the job ad mentions Kafka and you have an event-driven project, lead with that one. The planned guide on presenting personal projects in a remote job application goes further on wording, and how to build a portfolio that helps you get remote jobs covers portfolios for non-developer roles.

Know which companies actually hire from Nigeria

A strong portfolio still won't help if you apply to roles you can't legally take. Check the location line on every ad. As of October 2026, Canonical's Greenhouse job board listed software engineering roles marked "Home based - Worldwide" and others marked "Home based - EMEA" (Europe, Middle East and Africa). Openings and eligibility change, so always check the live ad before applying. For more on where to look, see the planned guides to the best remote software developer jobs for Nigerians and websites for finding remote developer jobs.

Common portfolio mistakes and quick fixes

Frequently asked questions

Do remote employers actually look at GitHub?

Many do, especially for engineering roles, but not all, and some only look after an initial screen. Make your GitHub easy to skim in two minutes, and also make sure your CV stands on its own, because some recruiters only read the CV before passing you to an engineer.

Can I get a remote developer job from Nigeria with only portfolio projects and no work experience?

Yes, it's possible, but it's harder than with experience, and fully remote junior roles open to Nigeria are relatively scarce. Projects that look like production work (tested, deployed, documented), plus open source contributions, close a lot of that gap. Freelance or contract work, even small, also counts as real experience on your CV.

Should I include tutorial or bootcamp projects in my portfolio?

Only if you've extended them well beyond the tutorial. Add features, tests, deployment and your own README explaining what you changed. Reviewers recognise popular tutorial projects instantly, and an unchanged clone suggests you can follow instructions but haven't yet built on your own.

Is a green GitHub contribution graph important?

Not much on its own. A graph full of green squares from trivial commits impresses nobody. Reviewers care more about what's in your pinned projects and the quality of your commits and pull requests. Steady activity over months is a mild positive, nothing more.

Do I need a personal portfolio website if I have GitHub?

Not always. Backend, DevOps and data engineering candidates often do fine with a strong GitHub profile README. Frontend, full stack and mobile developers usually benefit from a simple site, because it's another sample of their UI work and it's easier for non-technical recruiters to read.

How do I show work I did under an NDA for a Nigerian company?

Describe it rather than publish it. Write a case study covering the problem, your role, the stack and the outcome without confidential details, and consider rebuilding a small generic component in a public repo. Ask your former employer what you're allowed to mention.

How long does it take to build a portfolio good enough to apply?

That depends on your starting point. A developer who already has projects can often fix READMEs, demos and pins in a couple of weekends. Building one substantial new project properly usually takes several weeks of part-time work. Start applying once your main project is deployed and documented, and keep improving the rest as you go.

Key takeaways

• Pin three to six original projects that match the specific role you're applying for, and nothing else.
• Every pinned project needs a working demo or screen recording and a README that explains the problem, your decisions and how to run it.
• Show remote-ready habits: clear commits, pull requests with descriptions, tests running in CI, and at least one contribution to someone else's code.
• State your time zone (WAT, UTC+1) and your working-hours overlap on your profile.
• Check demo links before every application, keep secrets out of your repos, and be careful running take-home code from unverified recruiters.
• Link specific repos from your CV and application answers, and confirm each job is open to applicants in Nigeria before you apply.

Next steps

Pick the one project that best matches the jobs you want and fix its README, demo and tests this week. Then browse remote tech jobs open to applicants in Nigeria. Each listing shows where applicants may live, and after a search you can turn on a free daily email alert for new matching jobs. When you're preparing for calls, the software engineer interview questions guide helps you rehearse explaining your projects out loud. If you'd like someone from the WorkRemote team to rewrite your CV and LinkedIn so they point reviewers to your best work, see what our CV review includes as part of Premium.

Sources

• Managing your profile README, GitHub Docs
• Pinning items to your profile, GitHub Docs
• What is GitHub Pages?, GitHub Docs
• GitHub Pages limits, GitHub Docs
• Licensing a repository, GitHub Docs
• Stack Overflow 2025 Developer Survey, Stack Overflow
• Software Engineering Intern job family, GitLab Handbook
• Current openings at Canonical, Greenhouse