La Raya · app (3): geolocalización para ordenar por cercanía… y por qué la quité

Esta entrada es corta y va de algo que cuesta admitir: construí una función, funcionaba, y la retiré. La geolocalización por cercanía en la app de La Raya.

Lo que construí

La idea tenía sentido: en una guía local, "lo que tengo cerca" es información valiosa. Así que monté:

• Un toggle de proximidad en las pestañas de eventos y noticias: al activarlo, la app pedía permiso de ubicación y ordenaba por cercanía usando la posición del usuario (el backend ya sabía ordenar por distancia con Haversine, su serie lo cuenta).
• Radios configurables con chips de 30/50/100 km, para acotar "cuán cerca".
• Y un arreglo para que el filtro por periodo y el de proximidad convivieran en la pestaña de eventos sin pisarse.

Técnicamente, bien. Permiso de ubicación, parámetros lat/lng/max_km a la API, ordenación correcta.

Por qué lo quité

Y aun así, semanas después, un commit lo resume: "refactor: quitar permiso y filtro de proximidad por geolocalización". Las razones, honestas:

• El permiso de ubicación es un coste alto. Pedir geolocalización en una app de consulta de pueblos es desproporcionado: asusta, baja la conversión y obliga a justificar ante las tiendas por qué accedes a algo tan sensible.
• El valor real era dudoso. El usuario de La Raya normalmente ya sabe en qué pueblo está o sobre cuál quiere mirar. El filtro por localidad (el chip + modal de la entrada anterior) cubre el 95% de la necesidad sin pedir nada.
• Menos superficie, menos problemas. Una función que pide permisos sensibles y aporta poco es deuda: hay que mantenerla, explicarla en la store y lidiar con los "no" del usuario. Quitarla simplificó la app y su ficha de privacidad.

No fue un fracaso técnico; fue una decisión de producto. La proximidad por GPS resolvía un problema que mis usuarios no tenían tanto, a cambio de un permiso intrusivo.

Lo que me llevo

• Que funcione no significa que deba existir. El listón no es "¿soy capaz de construirlo?", es "¿le compensa al usuario el coste (permisos, complejidad) frente al valor?".
• Los permisos sensibles se pagan caros. En percepción, en conversión y en burocracia de tienda. Pide solo lo que de verdad necesitas.
• Borrar código propio es una señal de salud, no de derrota. El proyecto quedó más simple, más privado y más fácil de mantener. Y la necesidad real (elegir localidad) ya estaba cubierta mejor por otra vía.

A veces la mejor entrada de un diario de desarrollo es la que cuenta lo que deshiciste. Con la app más enfocada, lo siguiente fue prepararla para el mundo real: publicarla en Google Play. Y ahí me esperaba un pequeño lío con las herramientas de build, que es la próxima entrada.