Repueblo
Si merece la pena mudarse a un pueblo cerca de Madrid, con datos y no con postal.
- Mi papel
- Reutilicé el motor de HabitaLocal para otra decisión de vida y definí las señales del índice rural.
- Estado
- Proyecto
repueblo.com, septiembre de 2026. Mil doscientos diecinueve municipios puntuados con datos oficiales. Abrirlo.
Qué existe
Repueblo compara 1.219 municipios de menos de 5.000 habitantes del anillo de Madrid —Madrid, Guadalajara, Toledo, Segovia, Ávila y Cuenca— por precio de vivienda, tren, colegio, centro de salud, fibra y ayudas vivas, todo con datos oficiales.
El ranking es multi-perfil: no hay un único orden para todo el mundo, porque no pesa lo mismo el tren para quien teletrabaja que el colegio para quien se muda con hijos.
Por qué no hay un único ranking
No pesa lo mismo el tren para quien teletrabaja que el colegio para quien se muda con hijos. El índice calcula las señales una vez; el orden se resuelve por perfil, con los pesos de esa situación.
flowchart LR
subgraph senales["Señales por municipio"]
viv["Vivienda"]
con["Tren y<br/>conectividad"]
serv["Colegio y<br/>salud"]
fib["Fibra"]
dem["Demografía"]
ayu["Ayudas"]
end
senales --> motor["Motor<br/>del índice"]
motor --> perfil{"Perfil y<br/>prioridades"}
perfil --> r1["Orden para<br/>teletrabajo"]
perfil --> r2["Orden para<br/>familia"] flowchart TB
senales["Señales por municipio<br/>vivienda · tren · colegio y salud<br/>fibra · demografía · ayudas"] --> motor["Motor del índice"]
motor --> perfil{"Perfil y<br/>prioridades"}
perfil --> orden["Un orden distinto<br/>para teletrabajo y para familia"] flowchart LR
subgraph senales["Señales por municipio"]
viv["Vivienda"]
con["Tren y<br/>conectividad"]
serv["Colegio y<br/>salud"]
fib["Fibra"]
dem["Demografía"]
ayu["Ayudas"]
end
senales --> motor["Motor<br/>del índice"]
motor --> perfil{"Perfil y<br/>prioridades"}
perfil --> r1["Orden para<br/>teletrabajo"]
perfil --> r2["Orden para<br/>familia"] Qué hice
Repueblo nació como fork de HabitaLocal. Mismo motor, misma infraestructura, problema distinto: la unidad de análisis pasa de local urbano a municipio rural, y las señales cambian enteras.
Antes de tocar código escribí el mapa de qué se reaprovechaba tal cual, qué se reconvertía y qué se tiraba. Esa media hora de escritura es lo que hizo que el fork costara semanas y no meses.
El fork, dibujado
Mismo motor, otro problema. Lo que cambia es la unidad de análisis y el juego de señales; lo que se conserva es la fontanería: recolectores con procedencia, generación de informe y cobro.
flowchart TB motor["Motor común<br/>recolectores · procedencia · informe"] motor --> hl["HabitaLocal<br/>unidad: local urbano"] motor --> rp["Repueblo<br/>unidad: municipio rural"] hl --> hls["Señales: urbanismo,<br/>obra, margen"] rp --> rps["Señales: servicios,<br/>tren, vivienda, ayudas"]
Qué se aprendió
Que cuando un motor está bien separado del dominio, la siguiente vertical es barata. Y que la cobertura hay que declararla: el factor de vivienda tiene dato real de alquiler en 325 de los 1.219 municipios, y la ficha lo dice en vez de rellenar el hueco con una media.
Qué sigue en desarrollo
Completar la cobertura de vivienda a medida que haya fuente, e incorporar las ayudas como factor del índice y no solo como listado.
Siguiente paso
Si estás mirando pueblos en serio, empieza por el comparador.
Qué cambió esto para mí
Entré pensando que tener motor propio servía sobre todo para ahorrar código.
Salí creyendo que sirve para cambiar de problema sin cambiar de herramientas, que es una libertad bastante distinta.