Con lo que lidian de verdad los gestores de propiedades cada año
Nester es una plataforma de gestión de alquileres para propietarios, agencias e inquilinos: contratos, facturación y comunicación, todo en un mismo lugar. Casi todas las líneas de renta recurrente están vinculadas a un índice de precios —normalmente el IPC de España—, que se actualiza una vez al año en una fecha distinta para cada contrato.
Hasta entonces, cada actualización era manual: recordar la fecha, buscar el nuevo valor, hacer el cálculo y editar la línea a mano. Entre 5 y 8 minutos por contrato. En una cartera de 5.000 inmuebles, eso sumaba unas 38 horas de trabajo al mes —un día y medio para cada persona de un equipo de 3—, con un coste estimado de 5.900 € al mes en horas de trabajo.
Los account managers lo señalaban como una de las quejas principales, y el equipo comercial escuchaba la misma pregunta de casi cada nuevo lead: ¿esto puede ser automático? Estaba en el backlog como prioridad alta desde 2024: todos coincidían en que importaba, pero nadie tenía un plan.

Por qué un recordatorio no era la respuesta
Un recordatorio que ya existía y nunca se construyó
Por fin se priorizó en septiembre de 2025, para el Q1 de 2026. Pero el primer intento venía de 2024: Tasks, una propuesta más amplia de gestión de tareas —no específica de índices— que incluía un recordatorio para las actualizaciones de índice y permitía a los gestores vincularlo. Tasks nunca se construyó: se quedó en el icebox.



Dos problemas, no uno
Ni siquiera ese recordatorio lo habría resuelto: solo avisa, no calcula ni toca la línea de facturación. Así que el brief cambió: no recordarle a alguien que haga el trabajo, sino hacer que ocurra automáticamente, e involucrar a una persona solo cuando de verdad haga falta su criterio.
Diseñar una actualización que funcione sola
Entender la operación, no el parche
Antes de diseñar nada, observé cómo lo resolvían realmente los gestores. Se repetían tres cosas: el propio trabajo manual, revisar las fechas de los contratos solo para saber si algo vencía, y avisar a los inquilinos con suficiente antelación: al menos un mes, no el día anterior.
Extender lo que ya funcionaba
Nester ya tenía un motor de facturación recurrente: los contratos generan facturas automáticamente, con su propio calendario, sin que nadie las cree a mano. La actualización del índice era un problema con la misma forma, así que, en lugar de un sistema aparte, extendimos esa misma línea recurrente y añadimos el índice como una propiedad más.
El verdadero beneficio fue una vista nueva, “Actualización masiva”, donde una vez por semana el gestor podía ver todas las actualizaciones próximas y resolverlas en un par de clics: días de trabajo manual convertidos en unos minutos.
Acertar con la lista de índices
Quedaba por decidir qué índices soportar. El equipo daba por hecho que con IPC e IRAV bastaba; en lugar de diseñar sobre esa suposición, lo probamos directamente con clientes de España y México, incluido Vivia, nuestro mayor cliente, a quien preguntamos qué usaba realmente además de esos dos.

Así apareció el IGC —usado como tope legal en 2022–2023— y un caso que no habíamos previsto: inmuebles no residenciales con un porcentaje fijo. México sumó un índice propio de su mercado. El selector salió con cinco opciones en lugar de dos: IPC, IRAV, IGC, INPC y manual/fijo. Dejamos el tope mínimo/máximo fuera de la v1 para no retrasar el lanzamiento; el equipo técnico dejó preparados los campos en la base de datos.

Qué se construyó, de la pantalla al backend
Cómo se configura una línea
Cada línea se configura una sola vez, al crear el contrato: si es actualizable, con qué frecuencia (de mensual a anual) y cuál de los cinco índices aplica.
Un campo resultó más importante de lo esperado: “fecha de próxima actualización”, que le indica al sistema cuándo volver a revisar una línea. Fue clave al migrar contratos antiguos: sin él, el sistema habría asumido que todos los contratos tenían que actualizarse desde cero —desde la firma, a veces años atrás— y habría marcado al instante cientos de contratos ya gestionados como vencidos. Configurar bien este campo permitió que cada contrato retomara desde su próxima fecha real, en lugar de reiniciar todo su historial.
A partir de ahí, el sistema sigue la fecha por sí solo: el gestor solo confirma el porcentaje cuando toca (más sobre esto en la Reflexión) y, una vez confirmado, se aplica y se notifica automáticamente.
Una vista pensada para supervisar
Creamos una vista “Actualización” con cuatro pestañas: Pendientes, En proceso (que avisa si la notificación al inquilino quedó desactualizada tras una edición posterior), Completadas e Ignoradas. Las filas se pueden editar en bloque desde un único modal: definir el porcentaje, elegir si notificar a los inquilinos y aplicarlo a toda la selección.



Dos puntos de contacto más: integración con el calendario (pedida por account management) y dos emails mensuales opcionales, uno para el gestor y otro para el inquilino. El dashboard de inicio incorporó una nueva tarjeta de “Actualizaciones pendientes” en lugar de la antigua de “Inmuebles/Propietarios”.

Hecho para durar, sobre un stack que no lo estaba
Proceso: presenté el enfoque, escribí el PRD completo (49 páginas, con Google AI Studio), hice sesiones de preguntas y respuestas con los desarrolladores y después un test interno de 4 días que hice yo misma, contrato por contrato, registrando cada incidencia.
890 actualizaciones y creciendo cada mes
Lanzado el 23 de febrero de 2026. El uso creció de forma sostenida, sin un pico seguido de estancamiento: 36 → 115 → 185 → 250 actualizaciones de abril a julio, una bajada a 207 en agosto (por las vacaciones) y 97 en lo que va de septiembre. Hoy hay 85 pendientes y 1 ignorada. Incluso el pico de julio queda por debajo de las 285–456 actualizaciones mensuales que acabaría necesitando la cartera completa: la opción es voluntaria, así que es un sistema que todavía está creciendo hacia su escala total, no un despliegue terminado.

Lo próximo que impulsaría
Tanto la opción de actualización como el email mensual son opcionales y vienen desactivados por defecto: la decisión correcta para lanzar con seguridad, pero significa que muchas líneas que podrían usarlo aún no lo tienen activado, simplemente porque nadie ha entrado a hacerlo.
El siguiente paso no es una funcionalidad más grande, sino una más pequeña: activarla por defecto en las líneas que cumplen los requisitos, en lugar de depender de que alguien se acuerde. Una automatización que todavía necesita activación manual está hecha solo a medias.
El paso más grande: conectar directamente con el organismo oficial que publica cada índice, para que Nester sugiera el porcentaje en lugar de que el gestor lo busque a mano. No era viable dentro de los plazos de este proyecto, pero es el siguiente paso natural.
