Series: Weekend at Claude's — misadventures in building a production app with an AI anyone could mistake for the person who's going to make the whole thing happen
I looked at the sign-up screen and asked a simple question: why does this need an email address? Aphilaty's entire pitch is anonymity. Every other corner of the architecture goes out of its way to avoid collecting anything identifying. So why does account creation start by asking for the one thing the rest of the app is built to avoid?
I asked Claude to check before answering — not guess, actually read the project files. The honest answer came back: there wasn't a documented reason. Email was the Firebase Auth default, never a deliberate choice. It was the one piece of the architecture that didn't match the discipline everywhere else.
Following it all the way down
Once that was on the table, the conversation didn't stop at "should we change it." It kept finding the next question underneath the last one.
If we drop email, how does someone invite a friend to share a grocery list? Turned out the org-invite flow already solved this — a short-lived token, delivered through whatever app you already use to text people, never touching Aphilaty's servers with a name or number attached. But the list-sharing screen was built differently, with a real email lookup baked in. That would have broken silently the moment email stopped being required. Found it, fixed it, same session.
If someone adds a recovery email later, where does it live? Not automatically obvious, and worth getting exactly right: turns out it can live entirely inside Firebase's own login system, never copied into Aphilaty's own database at all. Different question than "should recovery be optional" — and a more important one, because it's the difference between actually keeping a promise and just sounding like you're keeping it.
Each answer turned into a real decision, written down, with a reason attached. Use Firebase's own anonymous sign-in rather than build a custom one — not because building one is impossible, just because Google already runs that infrastructure at a scale we never will. Don't let the optional recovery setting almost re-introduce the thing we just removed. Don't migrate anything, because there's nothing to migrate yet — just test accounts that get wiped daily, plus one permanent account that was never part of the problem to begin with.
Writing down what's true, not what sounds good
That work led somewhere I hadn't expected at the start of the morning: a plain-language guide explaining exactly where anonymity holds and where it doesn't, written for the person using the app, not for a lawyer.
The instinct with something like this is to write reassurance. We tried to write something else — a precise account of four specific places identity gets less anonymous, each with an honest reason it exists and an honest description of what you're trading. A display name in your family's private group isn't a privacy leak; it's the only way your mom knows you brought the ice and not your brother. Account recovery isn't a tracking mechanism; it's the difference between losing your phone and losing every list you've ever built. Your zip code isn't really optional at all — it's what keeps an offer for a store a thousand miles away from cluttering your feed. Linking a loyalty card is the one place we said plainly: this is the most identifying thing you can do here, and right now, the only thing you get for it is convenience — the bigger rewards come later, once that part of the app actually exists.
Saying that plainly took more care than writing something vaguer would have. A vaguer version would've been easier and worse.
The part that mattered most wasn't a feature
Partway through, a question came up that wasn't really about authentication at all: if someone types a Social Security number or a credit card into a shared list, does anything stop that?
Nothing did. So that became its own piece of work — a hard block for the two things with no legitimate reason to ever appear in shared content, a warning (not a block) for phone numbers and email addresses, because those have real uses a hard rule would get in the way of. The harder call wasn't the detection logic. It was whether a user should be able to keep their own stricter setting even if the app's policy says "warn and allow." We talked through it directly, looked at how other platforms handle the same tension, and landed on no — not because user choice doesn't matter, but because a setting almost nobody would ever find before they need it isn't really protecting anyone. The actual protection is making sure the warning never quietly stops firing after the first time someone sees it.
What the morning actually was
None of this started as one project. It was a series of "wait, why" questions, each one answered by going and checking rather than assuming, each answer either confirming something was already fine or surfacing something that needed fixing. The list-sharing screen breaking silently. The recovery setting almost undoing its own point. The privacy guide that could have been reassuring instead of accurate. A gap that had simply never been asked about until someone asked it.
Bernie never got asked "wait, why does this need your email." Nobody asked Bernie anything. That's the difference.
Aphilaty is a privacy-first community coordination app. aphilaty.com