How to document projects so your Passport sells the work

Passport documentation is a product surface — write it for a busy stranger in Nairobi or London, not for yourself six months ago. Recruiters rarely clone your repo on day one. They scan for clarity: what problem you solved, whether the demo runs, and whether you can explain trade-offs. The difference shows up when someone opens your work cold — from another city, on a mid-range phone, with ten minutes to decide whether to message you.

A simple project template

Problem — who hurt and why it mattered Approach — what you tried and what you discarded Stack — languages, frameworks, infra Outcome — metrics, screenshots, or user impact Links — live demo, repo, design files

Lead with a one-sentence result so skimmers get the point.

Lead with a one-sentence result so skimmers get the point in five seconds. Then expand problem → approach → stack → outcome → links. If you collaborated, name your ownership slice honestly so endorsements and Execution Reputation stay coherent.

Put the stack in a short list near the top. Keep the narrative under 400 words unless the system is complex. Lead with the outcome sentence so skimmers get the point.

Common mistakes

• Screenshots without context
• Feature lists with no user outcome
• Private repos with no demo
• Tutorials pasted as “projects”
• Walls of text above the fold

Takeaway: If a stranger cannot explain your project after one minute, rewrite the summary before you apply.

Walls of text above the fold hide the demo link. Tutorials pasted as “projects” collapse under one clarifying question. Private repos with no demo ask strangers to trust you on faith — which is the opposite of proof-based hiring on Africoders.

Hiding that a demo is read-only or seeded wastes reviewer time. Label constraints honestly so trust compounds instead of collapsing on first click.

Make it scannable

Put the stack in a short list. Keep the narrative under 400 words unless the system is complex. Use headings that match how interviewers ask questions.

Use headings that match how interviewers ask questions: What was hard? What failed? What would you redo? Keep narrative under roughly 400 words unless the system is complex. Put the stack in a short list so Career Explorer–aligned skills are easy to match.

Use headings that match interviewer questions: trade-offs, failure modes, what you would do next. Link the demo twice on mobile-friendly pages so it is hard to miss.

Africa-aware constraints to mention

Bandwidth, device class, offline modes, local payment rails, and multilingual UI are credible constraints — name them when they shaped decisions. Context beats generic “built a scalable app” claims that could belong to any SaaS landing page worldwide.

Interviewers who hire for African markets notice when you designed for mid-range Android and flaky networks. That detail is proof of judgment, not a footnote.

Maintenance as reputation

Dead links destroy trust. Quarterly, open every featured URL in a private window. Demote anything that fails. Reliability is part of Execution Reputation.

Dead links destroy trust and quietly stall Execution Reputation when recruiters bounce. Quarterly, open every featured URL in a private window. Demote failures. Prefer seedable sandboxes or static exports for long-lived Passport entries.

When a host dies, publish a rebuild note and update the Passport link the same day. Silence looks like neglect even when the repo is excellent.

Closing

Rewrite one Passport project today using the problem → approach → outcome → link template, then open the demo in a private window to confirm it still works. If you stall, ask Aurora for one next action that matches your persona, hours, and target role — then ship the link.