GLP Cerca (1): por qué quería controlar el precio del GLP

Hay proyectos que nacen de una curiosidad técnica y proyectos que nacen de un mosqueo concreto. Este es del segundo tipo.

El problema, en una frase

Repostar GLP (autogás) en España es barato comparado con gasolina o diésel, pero el precio varía muchísimo de una estación a otra, mucho más de lo que la intuición sugiere. No es raro encontrar diferencias de 15-25 céntimos por litro entre dos estaciones separadas por unos pocos kilómetros. En un depósito de GLP eso son varios euros por repostaje, varias veces al mes, todos los meses.

Y aquí está la trampa: el GLP no se anuncia en los tótems de muchas estaciones con la misma prominencia que la gasolina. No siempre lo ves desde la carretera. Llegas, repostas, y nunca sabes si la de 3 km más allá estaba 12 céntimos por debajo. El mercado es opaco justo donde más duele.

Opinión que vertebra el proyecto: el dato existe y es público. El problema no es de información, es de acceso en el momento adecuado. Repostar es una decisión que tomas conduciendo, con prisa, mirando el indicador de combustible. Cualquier herramienta que no resuelva el problema en ese instante no resuelve el problema.

La información ya existe (y es oficial)

España tiene una joya de transparencia que mucha gente desconoce: el Ministerio (MINETUR) obliga a las estaciones a reportar sus precios y publica todo como datos abiertos. Precios, coordenadas, rótulos, horarios. Actualizado varias veces al día. Gratis.

El problema no era conseguir el dato. Era que el dato vive en:

Un portal oficial (el Geoportal de Gasolineras) que es excelente para consultas administrativas pero pesado y poco ergonómico para "estoy conduciendo y necesito decidir ya".
Un endpoint JSON pensado para procesamiento, no para humanos con prisa.

Existían apps generalistas de carburantes, sí. Pero casi todas optimizan para gasolina/diésel, tratan el GLP como un producto de segunda, y te obligan a filtrar, tocar, comparar. Demasiada fricción para el caso de uso real.

Qué producto quería (y cuál NO)

Antes de escribir una línea de código tenía clarísima la forma del producto. Lo escribí casi como un manifiesto:

Lo que SÍ:

Abrir la app y ver al instante la lista de estaciones con GLP a mi alrededor, ordenadas de más barata a más cara.
Un código de color que me dijera, sin leer cifras, dónde está el chollo: verde = barato, rojo = caro.
Una sola pulsación para que me lleve hasta allí en modo conducción.
Que funcionara con mínima interacción. Pensada para mirarla 2 segundos con el coche parado, no para "navegar" por ella.

Lo que NO:

No quería una red social de gasolineras, ni reviews, ni gamificación, ni cuentas de usuario.
No quería que el usuario tuviera que configurar nada para el caso común.
No quería almacenar la ubicación del usuario en ningún servidor. La posición se usa en el dispositivo para calcular cercanía y punto.
No quería fingir que el dato es mío ni que soy oficial. Es de MINETUR, y eso hay que decirlo claro (de esto va el último artículo de la serie, sobre operación y producto).

"De un vistazo" como requisito técnico, no como eslogan

La frase "decidir de un vistazo" suena a marketing, pero en este proyecto fue una restricción de diseño dura que condicionó decisiones técnicas concretas:

El orden por precio ascendente se hace en el servidor, no en el cliente, y es el orden por defecto de la API. La app no tiene que pensar.
El color es relativo al radio de búsqueda actual, no a un umbral absoluto. La estación más barata que tú puedes alcanzar es la verde, aunque en términos absolutos no sea barata. Esto resultó ser una de las decisiones más acertadas y lo desarrollo en el artículo 4, sobre la app.
La pantalla se mantiene encendida mientras usas la app (Wake Lock), porque una app de conducción que se apaga sola es una app rota.

La arquitectura que se dedujo de la motivación

De ese planteamiento salió, casi sin discusión, una separación en dos piezas:

Un backend que se come la complejidad: descarga el feed oficial, lo normaliza, lo persiste, calcula cercanía y tendencias, y lo expone como una API REST limpia. Lo escribí en Rust (Axum + SeaORM + PostgreSQL). El porqué, en el artículo 3.
Una app móvil ligera (Tauri 2) que no sabe casi nada: pide ubicación, llama a un endpoint, pinta una lista coloreada y abre Google Maps. Toda la "inteligencia" vive en el backend. El artículo 4 entra ahí.

Esta división —backend que carga con el peso, cliente tonto y rápido— no es casual. Viene directamente del requisito de "mínima interacción": si el cliente no tiene que decidir, no tiene que tener UI para decidir.

En el siguiente artículo empiezo por el principio de todo: el dato. De dónde sale, qué tiene de raro el feed de MINETUR y cómo guardo el histórico de precios sin que la base de datos crezca sin control.