When Claude Kept Writing Android Was Coming Soon

The Setup

The Android app for Banavu had been live on Google Play for a few weeks. Claude had helped immensely in building, testing and ultimately deploying the Android app to the Google Play Store. Both apps — iOS and Android — were downloadable, had real users, and were being actively developed. The homepage at banavu.com had a download call-to-action at the bottom, with links to both stores.

Except the CTA text said: "Download free on iPhone. Android coming soon."

The Google Play badge was right there, just below that line. The copy above it told every Android visitor they couldn't have the app yet.

Where Claude Got It Wrong

I'd been working on the homepage badges — fixing sizing, CDN issues, layout across breakpoints. During that work, Claude read the existing copy and left it unchanged: it treated the page as a source of truth for what copy to preserve, rather than checking what was actually true about the product.

I caught it and pointed it out. Claude fixed the line immediately — "Download free on iPhone and Android." — added proper HTML document structure (the file was also missing <!DOCTYPE html>, viewport meta, and closing tags), and deployed.

Then Claude also worked on adding a structural guard: deploy_home.sh greps for phrases like "coming soon", "android coming", "ios coming". If any match, the deploy aborts with a clear message. The thinking was: belt and suspenders. A memory file for the recall path, a deploy guard for the ship path.

Then I pointed out this had happened before. More than once.

Why Prevention Round One Wasn't Enough

The memory file feedback_platform_copy_check.md said: before writing or reviewing any web copy that mentions platform availability, check project memory for live status. And there was already a memory file project_android_app_live_play_store.md confirming both apps were live.

The problem is that memory files are recalled on demand. They don't fire at the start of a session. Claude has to think "I should check platform status before writing this copy" — and then actually look. That's exactly the cognitive step that failed in the first place.

The deploy guard catches it before it ships. But it fires at deploy time, not at session start. Claude could spend an entire session drafting, reviewing, and editing copy that treats Android as unreleased — and only hit the guard when trying to deploy. The guard prevents the mistake from reaching users, but doesn't prevent Claude from making it.

What was missing was something that fires unconditionally, before anything else happens, in every session without requiring any recall or trigger.

The Fix That Actually Holds

The project's CLAUDE.md file loads into every session's context from the very first turn. No recall needed. No trigger condition. It's just there.

The ## Android app section previously described the Android codebase and where its rules lived. It said nothing about whether the app was live. I added this at the top of that section:

+ **Both apps are LIVE.** iOS: App Store `id6758827585`. Android: Play Store
+ `com.banavu.kidsactivities`. Never write "coming soon" for either platform
+ — both have been live since late 2025. See [[project_android_app_live_play_store]].

Now the live status is visible before the first line of any session. Three layers enforce the same constraint at different points:

The deploy guard and the memory file were already there. The CLAUDE.md entry was the missing piece — the one that fires before anything happens.

There was one more mistake in that line, and it took me a couple of weeks to see it. "Both have been live since late 2025" was wrong. The Android app went live on Google Play in early August 2026, only a few weeks before the homepage told visitors it was coming soon. Claude wrote the date without checking it against anything, and because it sat in CLAUDE.md, every session after that read the wrong date as fact.

I caught it while revising this post, when I changed "live for months" to "a few weeks". Claude checked the session notes, found the first production upload at the end of July and the app live in early August, and rewrote the line to say Android has been live since early August 2026, citing those notes.

Learnings

• Memory files are passive; CLAUDE.md is active. A memory file requires Claude to think "I should check this" before it becomes relevant. CLAUDE.md is in the context unconditionally. For a fact that must hold in every session regardless of what work is happening, CLAUDE.md is the right place — not memory.
• Reactive prevention catches the mistake after it's made; proactive prevention stops it before. The deploy guard stops the mistake from reaching users. The memory file stops it when copy is explicitly in scope. Neither stops Claude from making the mistake in the first place. Only the CLAUDE.md entry does that.
• Recurring mistakes need escalating prevention. The first time is a one-off; add a memory file. The second time is a pattern; add a structural guard. The third time is a signal that something fires before work begins — CLAUDE.md, a pre-session checklist, or a build-time check. Match the prevention layer to when in the session the mistake happens.
• When a fact has zero tolerance for being wrong, it belongs in the unconditional context. "Both apps are live" is not a nuanced judgment. It's a binary fact that affects every piece of copy, every blog post, every homepage edit. Facts like this go in CLAUDE.md so there's no way to start a session without them.
• A wrong fact in CLAUDE.md is wrong in every session. The same property that makes CLAUDE.md the right place for "both apps are live" makes it the worst place for an unchecked detail. The "late 2025" date sat there for weeks, read as fact by every session. Before a date or number goes into CLAUDE.md, it should come from a source you can point to.