Monzo has been an English-only banking app for over ten years. When we started localising it for our European expansion, we made two product decisions early on: a customer's language lives in their Monzo account, not their device settings, and anything that differs between markets lives in the copy, not in the code. Both made Android's built-in resource resolution look like the obvious tool. It wasn't. This talk covers what went wrong, and how a long tail of "Android quirks" we were trying to work around were actually one systemic mismatch between what we assumed the platform did and what it actually does. This covers interesting problems like: Spanish copy falling back to US English rather than our market-neutral strings, dates formatted for one locale inside a sentence written for another, screen readers ignoring the account language altogether, third-party SDKs that have no concept of our locales at all — all of which seemed individually fixable, but ultimately symptomatic of a wider issue. This lead to a tough decision to invest in rebuilding our own version of Android localisation that we knew we could control. The second part of this is the observability gap. Incorrect copy doesn't crash, it just renders silently as if it were correct. The only way we realised it wasn’t working as expected was during manual testing, and manual testing can't scale across locales × markets × products × platforms. I'll cover where Android’s localisation system is lacking in observability, and what we had to build instead: alerting when any copy falls back to an unexpected locale. You don't need to be working on localisation to take something away. This is a talk about spotting when a platform default has stopped fitting your product, why "if it breaks, we'll notice" is a dangerous assumption, and how to decide when to stick with the plan, and when to recognise that it’s time to change course.