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
This whole session happened on my phone, at the airport gate, between boarding announcements. Mid-design, I asked Claude a fair question: had it actually checked the project documentation before designing this, or had it jumped straight in?
The honest answer was partial. The first pass found the offline-mode infrastructure and the existing offer notification tiers and felt like enough. It wasn't. I asked Claude to go check again before we went further.
What the second search found
There's already a fully designed Edit Organization screen in this project. Toggles for "Receive Messages" and "Receive Offers." A "Remove from Summary" control with four options. A confirmed color system. A wireframe. Decisions already locked about exactly where these settings live — on the user's org membership record, not the org itself, because they're personal preferences.
If Claude had designed the notification frequency feature without finding this, we'd have ended up with a second settings screen — a parallel place to control how often you hear from an org, sitting right next to a screen that already controls whether you hear from it at all. Two screens, overlapping purpose, neither one the obvious place to look.
That's not a hypothetical mistake. It's the default failure mode when you design a feature in isolation from a project that already has months of decisions behind it.
What changed once we found it
The whole shape of the feature changed. Instead of a new frequency dial from scratch, the design became: add one field to the same structure that already holds receiveMessages and receiveOffers, and put the new control on the exact same screen.
Same story with calendar integration — I'd assumed it was an open question. It wasn't. There's a complete spec already: a dedicated device calendar, per-org sync toggles, change detection to skip redundant writes, full revoke handling. The only real gap was one explicit "Add to Calendar" button for someone who hasn't turned on full sync. One button, not a system.
And the existing offer notification logic — three tiers already working — got generalized instead of replaced. One dial governing messages, list updates, and offers the same way, with the time-sensitive offer behavior preserved untouched.
The actual design problem, once duplication was avoided
With the existing surfaces accounted for, the real question got smaller and more interesting: how do you stop someone in eight chatty group chats, each individually well-behaved, from getting buried under thirty notifications an hour? No single org did anything wrong — it's a cross-org problem, and it needs a global rolling cap, independent of any one org's settings, that quietly stops sending once a sane ceiling is hit and lets the in-app feed catch the user up on whatever got held back.
That answer doesn't show up if you're heads-down on one org's settings. It only shows up once you stop duplicating effort and look at the seam between "this org's preference" and "this person's whole phone."
What I'm taking from this
"Did you actually check?" turned out to be worth asking twice. The first answer was good enough to feel confident, not good enough to be right. The project files had the answer. Claude just had to go look for it twice.
Bernie never got asked to double-check anything. That's the difference.
Aphilaty is a privacy-first community coordination app. aphilaty.com