What the Login Wall Was Quietly Holding Up
Removing the sign-up wall was obviously right. It was also the only real ceiling on paid AI spend, so the ceiling had to be rebuilt elsewhere first.
somesignal reads saju — a Korean birth-chart tradition — alongside MBTI, and explains what sits between two people in a single card. Until recently you had to create an account before you could see that card.
That the gate had to go was settled long ago. It was asking people for a birth date and an account before they had been shown anything worth giving them for. But while reading the code in order to remove it, something else turned up. The gate was not only blocking convenience.
The gate was doing a job that was written down nowhere
Every result in this product is produced by a paid AI call. And the only real ceiling on that spend was a per-account quota.
A per-account quota needs an account. Which is to say, it needs the login gate. Removing the gate on its own would have left anyone free to burn paid calls without limit. This was not written in any document. The gate was recorded as the thing that collects sign-ups; the fact that it was also holding down cost was a side effect you could only see by following the code.
There were two options: pull the gate now and deal with cost later, or rebuild the ceiling first and pull the gate afterwards. I took the second.
The ceiling was not removed — it was rebuilt somewhere else
The single job the gate had been doing was split into three, each rebuilt in its own place.
- One invitation link holds exactly one result. Enforced as a unique constraint in the database, not a check in application code, so every server instance sees the same number no matter how many of them are running.
- Creating a link still requires logging in. What was opened is the place where a result is read, not the place where one is made.
- An anonymous visitor's analysis is metered against the quota of whoever created the link. Cost cannot leak into anonymous traffic; it always lands back under some account's name.
Together, total spend is bounded by the number of links created by authenticated accounts. What came down was the wall in front of the result. What stayed up was the ceiling over cost. They had been one object, but they were never the same thing.
Moving it made it stronger than it was
There was an unintended result: the new ceiling is better than the one it replaced.
A per-account quota falls over the moment someone creates several accounts. The current structure hangs on a much narrower neck — link creation — and that neck is held by a database constraint. Defence was not traded away for convenience. It got a reason to be built properly, and was.
I do not think that was luck. An old mechanism stands for whatever reason it was first built, and the jobs that accumulated on it afterwards were never designed — they accrued. Pulling those jobs off and rebuilding each in its own place usually improves them, because this time they get designed on purpose.
Counting first is cheaper than one incident
When you remove something that blocks the product, people see only its stated purpose. A login wall collects sign-ups. An approval step prevents mistakes. A rate limit stops abuse. That is what the document says, and it is also the reason you want it gone.
But a mechanism that has stood for a long time picks up other things along the way — cost, consistency, ordering, authorisation. None of those appear in a design document, because none of them were ever designed.
So before removing anything, it is worth counting what it is currently holding. Following the code can cost half a day. That is still far cheaper than one incident — particularly when the incident is metered spend coming out of your own pocket.