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 led us to reach for Android's built-in resource resolution before we'd properly understood what we were asking of it. This talk covers how a long tail of seemingly unrelated issues - from rogue language fallbacks to screen reader and third-party SDK limitations - were actually symptoms of a systemic mismatch between our localisation model and the platform’s. This led to a tough decision to build our own resource management system, shaped around our product model. We’ll also address the observability gap. Incorrect copy renders silently rather than crashing, making manual testing impossible to scale across markets and products. I’ll share where platform defaults fell short and how we built custom alerting to catch unexpected locale fallbacks automatically. You don’t need to be working on localisation to take something away. This is a talk about spotting when you’re asking a system to do something it wasn’t designed for, 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.