# Building While Black, Building While Woman: The Infrastructure of Being Seen
I have shipped 8 production applications. I have 1,000+ commits. I have 3+ paying clients. I have a published poetry collection. I have 15 distinctions from Nelson Mandela University.
And I still, in certain rooms, spend the first 15 minutes of a meeting establishing that I built what I say I built.
This is not a complaint. It is an observation about infrastructure, the invisible scaffolding of credibility that determines whether your technical work is received on its merits.
The Credibility Infrastructure Gap
Technical credibility is not equally distributed. A developer who looks like the cultural image of a developer walks into a meeting carrying assumed competence. Every deviation from that image (being a woman, being Black, being from a coastal city in the Eastern Cape rather than a tech hub) creates a credibility debt that must be paid before the actual technical conversation can begin.
This is the infrastructure of being unseen. It is not dramatic. It is constant. It is exhausting in its accumulation.
How I Built My Own Infrastructure
I built it the only way I know how: by shipping.
GitHub commits don't carry bias. A live URL doesn't care what you look like. A 15-wing personal AI operating system running in production is its own argument. Code is the most democratic credibility infrastructure available: it either works or it doesn't, and the diff doesn't know your gender.
This is why I build in public. Not for the audience. For the record. The commit history, the deployed applications, the documented architecture decisions, these are credibility that cannot be taken away because it is not granted, it is produced.
The Double Standard in Proof
But here's the part that doesn't make it into the optimistic version of this story: the proof requirement is not equal.
A developer from a privileged demographic with one well-publicized project gets assumed competence extended. A Black woman from East London with eight live applications, 1,000 commits, and 3 paying clients often gets "can you walk me through how you built this?"
I'm not averse to walking people through how I built things. I do it in this publication every week. The asymmetry is in who gets to start the meeting at zero proof required versus who starts at -50 proof and has to earn their way to zero before the actual work begins.
What Changes When You Stop Performing for the Room
The most significant shift in my professional life happened when I stopped building for the approval of people who weren't going to give it.
I built K53 Drill Master because 60% of South Africans fail their learner's licence and I thought I could help. Not because I thought it would make someone in a boardroom believe I was a developer.
I built JarvisOS because I needed it, not because I needed to prove I could build something complex.
The applications got better when they stopped being arguments about my capability and started being solutions to problems I actually care about.
The Advice I Didn't Get
Build something real, not something impressive. The most credible thing you can make is something that works for someone who needs it.
Document everything. Your process, your decisions, your mistakes. Documentation is proof that is infinitely copyable.
Find your community before you need it. The women in African tech who are visible are often surrounded by other women who are less visible but equally capable. That community is infrastructure too.
Know that some rooms are not the right rooms. The goal is not to make every room grant you credibility. The goal is to build things that make certain rooms irrelevant.
What are you building that doesn't need anyone's permission?
Reader Insights
0 responses
No insights yet. Be the first!