Why an email address is not a name tag

We start with safety, because it is first for a reason.

Remember how Supabase was using email addresses as the labelled ID? The ugly consequence was that the front end was displaying people's actual email addresses whenever they had not yet attached a name to their profile. Strangers could see strangers' emails. That is not a small bug. That is a safety breach wearing a small bug's clothing.

So I went to the AI and gave it a clear instruction: ensure no personal information is ever made public unless it is explicitly permitted, so that things like a person's name and interests can show, but their private credentials never do. The mechanism for this is something called RLS.

What is RLS (Row Level Security), in plain language?

Let me be precise, because you will say this word in rooms with technical people. RLS stands for Row Level Security. The plain-language version, the one that actually matters, is this:

RLS is just a fancy way of deciding who is allowed to see what, based on who they are.

It works hand in hand with roles. On my platform there is an admin role, a user role, and a non-user role. Take an example. A non-user, someone who has not signed up, can land on a page and look at it. But they cannot interact with it. They cannot leave a comment before signing up. They are gated from that action based on their role. Different people, different permissions, all enforced at the level of the data itself, so it cannot be tricked from the front end.

And here is the instruction I cannot give you strongly enough: you must run an audit on this. Go through it deliberately and make sure you are not leaving private information lying around where a hacker can come and have a field day. The beautiful part is that you do not do this alone either. Tell your AI plainly that this is your intent — that you want to lock down private data and audit your permissions — and it will not only do it, it will find ways to do it better than you knew to ask for.

Identity before access: fixing user onboarding at the root

After the RLS reset, there was a related job. I had to fix onboarding so that every single user gives enough information to actually have an identity before they start using the site. Because the whole email-on-display disaster happened in the first place because the system had nothing else to fall back on. No name, so it showed the email. Solve the root, not just the symptom.

So now every new user fills a short form on the way in: name, username, age, gender, and interests. Two birds, one form. It guarantees the person has a real identity on the platform so we are never forced back onto their email, and the interests data lets me start optimising their experience from the very first session.

Identity is not bureaucracy. On a social platform, a proper identity is itself a safety feature.

How to design an app that women actually feel safe using

Safety done, comfort is next. And comfort, on a social product, is its own deep discipline.

Social sites are funny things. You start a perfectly nice conversation with someone, and then, suddenly, you need to never hear from them again. So I obsessed over questions like: how do I make sure nobody on here ends up stalked? How do I make people feel genuinely in control of who reaches them? Now, if your product is not social, you probably will not need to lose sleep over this. But HVNG is intensely social, so there I was, running every horrible scenario in my head.

And here is where I have to stop and beg you, bros, directly. Ask women what safety features they would want. I am serious. Sit down and ask them, and then listen.

You will learn more about safety from the people who have been victims than you will ever learn from the people who cause the harm.

But — and this is the part that separates a founder from an order-taker — you must also learn when to say no. A surprising number of my female reviewers wanted the ability to rate their hangout, and the person they met, publicly. And I said no. Something about publicly rating other human beings and your time with them is, for me, always going to be a no. That instinct is not me ignoring my users. That is me doing my actual job.

Being a founder is knowing not only which features to add, but which features to refuse.

What I did build was a block button and a shadow-ban reporting system. The rule I settled on: if three people report you within twenty-four hours, the platform treats what they are saying as true, and you get shadow banned. One honest founder's footnote, since you will build something like this too: a rule that automatically trusts three reports can be gamed by people coordinating false ones, so as you grow you will want a way to catch brigading as well. But as a starting line in the sand, it works, and it tells your users that the platform has their back.

What are your users actually there for?

Safe and comfortable — now the last door. Utility. And I had to ask the genuinely hard question: what exactly are people on HVNG trying to get out of it?

Here is the trap. You assume utility means something practical, a clear service rendered. But that is not how the most addictive products on earth work at all. Look honestly at Instagram. What is its utility? It is a medium for status signalling, for crowdsourcing validation, for living voyeuristically through other people, for sliding into DMs, for pure entertainment. Not one of those is a tangible service. Not one is a thing you could write on an invoice. And yet together they are exactly what keeps that entire userbase hooked.

So at this point I had to start thinking about my users almost like subjects in a lab. Observe what they actually do, not what they say, and certainly not what I assumed.

The day I learned what I had actually built

And this is where the most humbling lesson of the whole journey arrived.

I had built HVNG, first and most honestly, for myself. I find Lagos strangely stressful, because being out in Lagos still is not really a social experience, and I cannot fully explain why, but it had started to feel like we had drifted into too much isolation. I just wanted to be able to go and check out the new Mortal Kombat with other people who actually cared about it. That kind of thing. Connection around a shared interest.

Then a friend looked at it. And his very first comment was that this would be perfect for guys looking to take girls out on a date.

No shit. I had built a dating app, and I had not even noticed. In fairness to me, it was an easy thing to miss, because I am married, so "this is for dating" simply does not live near the front of my mind. My wife, who is my honourable co-founder, and I had both been happily telling ourselves we were building primarily for communities and events.

I cannot stress this part enough.

Listen, and iterate. Do not rush to rush into rubbish. But do not iterate forever and forget to launch.

That is the whole tightrope of being a founder, held in one breath. You have to hear what people are really telling you about your product, even when it contradicts your own intentions, and you have to act on it, without falling into the swamp of endless polishing that never ships.

What I knew I wanted, underneath all of it, was for HVNG to give people a sense of exploration and adventure. And here is the soft truth I will defend: you do not even have to be outside to get something from it. Sometimes just seeing other people out and about is enough. (But please. Come outside.)

Form is psychology: why a swipe changes what your app means

Then another friend told me, flatly, that I was building a hookup site. And rather than get defensive, I got curious, because two different people had now read my "community and events" product as something romantic, and that pattern was a message.

So I went looking for why, and I found it in the design itself. Originally, I had used a Tinder-style mechanic: swipe left or right to accept or reject a hangout. In my head, the logic was innocent. The default results showed both men and women, so surely that signals this is not a dating app, right?

Wrong. The swipe itself had already zoned the user's mind. It did not matter what I displayed. The gesture carried meaning, and the meaning it carried was "rate these humans, yes or no," which is the exact grammar of dating apps.

Form is not neutral. There is a psychology to form and function, and it shapes how people perceive what you have built, often louder than your content ever will.

So we changed it. We moved from the swipe to a feed, something closer in feel to Facebook or Instagram, which carries a much more general, social, non-romantic vibe. The gesture changed, and the perception changed with it.

And I will be honest with you: I would go on to change that design one more time. But that is a story for the next entry.

---

Hands-on lab

The chapter above is the why. These guides are the how. The one rule never changes: if a step stumps you, screenshot it and paste it to your AI with "assume I have no technical experience; tell me exactly what to click next." Nothing here cannot be undone.

G5.1 · Lock down private data with RLS and run a privacy audit [Core]

What you'll have: Personal data protected so it is never exposed publicly.

Before you start: Intermediate · 1–2 hrs · free · you'll need Supabase and your data

1. Understand RLS (Row Level Security): rules deciding who can see or do what, by role (admin, user, non-user).
2. Tell Claude: "Ensure no personal info is public unless permitted by RLS. Names and interests can show; emails and private data cannot."
3. Set role-based access (for example, non-users can view but not comment).
4. Ask Claude to run a full RLS and privacy audit: "find anywhere private data could leak, and fix it."
5. Test as a logged-out visitor and confirm you cannot see private data.

Check you did it right: No emails or private fields are visible publicly, and roles enforce access.

If something looks off: Locked yourself out of something → adjust that specific policy.

Unlocks: → G5.2

G5.2 · Build an onboarding form (identity before access) [Core]

What you'll have: Every user has a real identity, so you never fall back on showing emails.

Before you start: Beginner · ~1 hr · free · you'll need auth working

1. Ask Claude to add a required onboarding form for new users: name, username, age, gender, interests.
2. Gate the app so users complete it before using core features.
3. Use the username or display name (never the email) as the public identifier.
4. Store interests to personalise the experience.

Check you did it right: New users must complete the form and the public identifier is a username, not an email.

If something looks off: Too long a form deters sign-ups → keep it to the essentials.

Unlocks: → a safer, more personal platform

G5.3 · Add a block button and a report / shadow-ban system [Optional]

What you'll have: Users feel in control and safe, and bad actors get handled.

Before you start: Intermediate · 2–3 hrs · free · you'll need social features

1. Ask Claude to add a block button (a blocked user cannot contact or see the blocker).
2. Add reporting on profiles and content.
3. Add a rule (for example, 3 reports in 24 hours triggers a shadow ban), and ask Claude to also flag coordinated or false reporting so the rule cannot be gamed.
4. Consult women and at-risk users on what would make them feel safe, and build from that.

Check you did it right: Blocking works, reports accumulate to trigger the rule, and brigading is flagged.

If something looks off: False reports → rely on the anti-brigading check and review borderline cases by hand.

Unlocks: → comfort. On to Part Six.

---

Software is easy, humans are the work

The code was never the hard part. Articulating logic to a patient super-senior engineer turned out to be the easy half. The hard half is human: making people feel safe, making them feel comfortable and in control, and being honest enough to discover what your product actually is to them, rather than what you wished it to be.

And notice the through-line. The email fix came from listening. The safety features came from asking women and actually hearing them. The whole shape of the product came from two friends telling me an uncomfortable truth, and from a wife and co-founder thinking it through beside me. None of the important moves came from me alone in a room. They came from people. You cannot build for humans in isolation from humans — and Africa especially cannot win this as a thousand lonely founders each guessing in the dark. We move as an ecosystem.

What's next

You have a platform now that is safe, comfortable, and finally honest with itself about what it is. Next: that one last design change, the loneliest problem in tech — the cold start — and what separates a product people merely use from a product people love.