The Rule Was Guarding a Proxy
The privacy rule said non-members see nothing. It was meant to protect other people's data. Redrawn around ownership, it got safer and the product got a door.
somesignal reads a relationship between two people through saju — Korean four-pillars astrology, worked from a birth date and time — together with MBTI. Two people put their details in, and a reading comes back that both of them see. The inputs are as personal as inputs get: a birth date, a birth time, a personality type, sometimes a gender.
From the first version the service had one privacy rule, written down and enforced: non-members do not see service data. It was a good rule. It was short, it was easy to check, and for a service holding birth times it erred on the safe side. It was also, by September, the single biggest thing standing between the product and anyone using it.
What the rule was costing
Follow the rule to its consequences. To see a reading about two people, both had to be members. So when one person invited another, the invited person hit a sign-up wall — a Kakao login, then a birth date, then a birth time — before seeing a single word of what they had been invited to. The person who sent the invitation waited, often for nothing.
The share card followed the same logic. A reading could be drawn as a vertical card in the colours of its five-element type, but opening that card required a login. So nothing left the product. Not a card, not a link, not a screenshot worth sending, because whoever received it would meet the wall.
Every successful product in the neighbouring space does the opposite: result first, no login, an image you can post. The rule had put the product in exactly the inverse position, and it had done it for a reason that sounded like principle.
The tempting fix, and why it was wrong
The obvious move was an exception. Keep the rule, punch one hole for the share card, maybe a second for the invited person's first view. Most privacy rules die this way — not repealed, but exempted until nobody can say what they cover.
An exempted rule is worse than a narrow one, because it can no longer be trusted. Once "non-members see nothing, except…" has three exceptions, the next engineer has no way to tell which data is actually protected. The rule stops being a boundary and becomes a list of past arguments.
So instead of asking where can we make an exception, I asked what was this rule for. What was it actually protecting? The answer was not "members". The answer was other people's data. Nobody should see personal information that is not theirs. Membership had only ever been a stand-in for that — a proxy, because "is this person logged in" is easy to check and "does this data belong to them" is not.
Redrawing around the real thing
The rule was rewritten: non-members do not see third-party data. Not loosened; redrawn around the purpose that had been behind it all along.
Then the data was sorted by that rule. Birth date, birth time, the full chart, MBTI, gender, and the numeric score — all personal, all belonging to a specific person — stay exactly as protected as before. Not one character of that list was relaxed. The anonymous card — a first initial, a five-element type, a relationship category, one sentence — is nobody's private data. It contains nothing that identifies or exposes anyone. So it opens for whoever holds the link, member or not.
The same test opened the invitation. An invited person now sees a form instead of a wall, fills in their own details, and both readings appear at once. They are looking at their own data and a result derived from it. An account is asked for later, only if they want to keep the relationship on their map — which turned sign-up from a price of entry into a way to save.
The redrawn rule is safer than the old one. Under the old rule, a member could in principle see any service data; the boundary was membership, not ownership. Under the new one, the question is asked of every piece of data regardless of who is logged in. The product got a door, and the boundary got sharper at the same time.
Ask what the rule was for
When a privacy rule is blocking the product, the common response is to negotiate with it — an exception here, a special case there. The better question is what the rule was written to protect. Almost always the real purpose is narrower than the rule, because the rule was written around whatever was easy to check rather than around the thing itself.
A boundary redrawn around the purpose tends to be stricter where it matters and looser where it does not. That is the opposite of an exception, which is looser where it matters and unchanged everywhere else. And it leaves you with a rule you can still state in one sentence, which is the only kind anyone will keep enforcing.