Phase 40 · Singles · Q5 alternate · 2026-05-26 PM

"Open to meet" ribbon — visible or hidden?

Built with the ribbon always visible per Claude's pick. Surfacing both options side-by-side so you can pick the one that ships. The tradeoff is honesty-vs-privacy: visible says "I'm using Singles," hidden says "I'm a Nabe resident who happens to be in Singles."

Default in code: visible. To swap to hidden, change ProfileContainer to only render the ribbon when viewerIsViewingFromSingles. One-line gate.

Side-by-side comparison

Option A · currently shipping

Ribbon always visible

Anyone who taps this profile — from feed, search, group, or Singles — sees the "Open to meeting people" ribbon. Honest, low-friction.

Open to meeting people
Maya Schwartz, 32
She/her · 287 Bedford Ave · 4 years here
87
Block Score
Trusted neighbor

"Designer at Etsy. Marathon-adjacent. McCarren mornings, Devocion afternoons."

[Activity strip + tabs + activity entries continue below]
Pros (Option A): Honest. A neighbor seeing this profile from anywhere knows what mode this person is in. Lower friction for the person doing the browsing — they immediately know they can say hi.
Cons (Option A): Coworker / parent / neighbor casually tapping a name from a feed post sees the ribbon — even though they're not in Singles. Mild "uh OK I didn't need to know that" energy.
Option B · privacy mode

Ribbon only when viewing from Singles

Tapping the same profile from a feed post → normal profile. Tapping it from the Singles browse → ribbon + "Say hi" CTA. The viewer's context controls visibility.

Maya Schwartz, 32
She/her · 287 Bedford Ave · 4 years here
87
Block Score
Trusted neighbor

"Designer at Etsy. Marathon-adjacent. McCarren mornings, Devocion afternoons."

[Activity strip + tabs + activity entries continue below]
Pros (Option B): Maximum privacy. Maya being in Singles is invisible to anyone she doesn't want it to be visible to. Doesn't change how non-Singles neighbors experience her profile.
Cons (Option B): Slightly dishonest UX — viewer doesn't know "say hi" is even an option. Could feel like asymmetric information (browser sees "open" status, browsee doesn't see that browser knows). Adds a state-context gate to ProfileContainer.

⚖️ Claude's recommendation

Option A (currently shipping) matches the rest of Nabe's "identity-coherent across surfaces" principle. The product premise is that you're the same person on every screen — your photo's the same, your posts are the same, your building is the same. Hiding the Singles state on some views and showing it on others breaks that principle.

Option B feels right for old-school dating apps where the dating persona is the parallel persona. For Nabe, where Singles is "a filter, not a fork," Option A is more on-brand. The ribbon is a small signal that says "yes, this person is on Singles and they know everyone can see that."

If anything in the demo feels off when you walk through it, swap to Option B with the one-line gate. But Option A is the more honest default.

🏗️ Implementation toggle

// ProfileContainer.tsx hero — Option A (current):
{user.singles?.enabled && }

// To swap to Option B (privacy mode):
const viewedFromSingles = useFromSinglesContext();  // new context, set when
                                                     // navigating from Singles
{user.singles?.enabled && viewedFromSingles && }

// SinglesContext provider wraps SinglesBrowse and signals to nested user
// profile drawers that the navigation came from Singles. Reset on close.