Nester
2026
Rent Index Engine
A workflow that recalculates and applies rent increases automatically, based on each contract's price index — replacing a manual process property managers had to repeat by hand, every month.
Context
What property managers actually deal with every year
Nester is a rental management platform for owners, agencies, and tenants — contracts, billing, communication, all in one place. Almost every recurring rent line is tied to a price index, most often Spain's IPC, which updates once a year on a different date for every contract.
Before this, every update was manual — remember the date, look up the new value, do the math, edit the line by hand: 5 to 8 minutes per contract. Across a portfolio of 5,000 properties, that added up to about 38 hours of work every month — a day and a half each for a team of 3, an estimated €5,900 a month in labor.
Account managers flagged it as a top complaint, and sales heard the same question from nearly every new lead: can this be automatic? It sat on the backlog as high-priority since 2024 — everyone agreed it mattered, nobody had a plan.
Account Management Hub - How demand for this feature showed up before it had a system to live in
5,000
properties across the portfolio
38 hrs/mo
manual work per month — ~5 full-time days for one person
€5,900/mo
estimated labor cost of doing it by hand
~2 years
how long this sat on the backlog (2024 → Q1 2026)
Challenge
Why a reminder wasn't the answer
A reminder that already existed, and wasn't built
It finally got prioritized in September 2025, for Q1 2026. But the first attempt dated back to 2024: Tasks, a broader task-management proposal — not index-specific — that included a reminder for index updates, letting managers link the index. Tasks never got built — it stayed in the icebox.
How demand for this feature showed up before it had a system to live in
The Nester home dashboard, with the tasks widget and calendar
Two problems, not one
Even that reminder wouldn't have solved it — it only notifies, it doesn't calculate or touch the billing line. So the brief changed: don't remind someone to do the work, make it happen automatically, and only involve a person when it truly needs their judgment.
Approach
Designing an update that runs on its own
Understanding the operation, not the workaround
Before designing anything, I looked at how managers actually handled this. Three things came up repeatedly: the manual work itself, checking contract dates just to know something was due, and giving tenants enough notice — at least a month, not the day before.
Extending what already worked
Nester already had a recurring billing engine — contracts generate invoices automatically, on their own schedule, nobody creates them by hand. The index update was the same shape of problem, so instead of a separate system, we extended that same recurring line, adding the index as one more property.
The real payoff was a new view, "Actualización masiva," where once a week a manager could see every update coming due and clear it in a couple of clicks — turning days of manual work into a few minutes.
Getting the index list right
What was still open was which indices to support. The team assumed IPC and IRAV covered it — instead of designing around that, we tested directly with clients in Spain and Mexico, including asking Vivia, our largest client, what she actually used beyond those two.
That surfaced IGC — used as a legal cap in 2022–2023 — and a case we hadn't planned for: non-residential properties on a fixed percentage instead. Mexico added a market-specific index. The selector shipped with five options instead of two — IPC, IRAV, IGC, INPC, manual/fixed. We left the floor/ceiling cap out of v1 to avoid delaying the launch; engineering prepped the database fields for it.
The discarded path would have duplicated dates, calculation, and notifications in a separate system, disconnected from what the business already knew about each contract. The one we shipped adds the index as one more property on the existing recurring-billing line and reuses the same engine end to end.
Solution
What got built, from screen to backend
How a line gets configured
Each line is configured once, at contract setup: whether it's updatable, how often (monthly to annually), and which of the five indices applies.
One field mattered more than expected: "next update date," which tells the system when to check a line next. It was key when migrating old contracts: without it, the system would assume every contract needed updating from scratch — starting from when it was first signed, sometimes years ago — and immediately flag hundreds of already-handled contracts as overdue. Setting this field correctly meant each contract just picked up from its real next date, instead of restarting its whole history.
From there, the system tracks the date on its own — a manager just confirms the percentage when it comes due (more on that in Reflection), and once confirmed, it applies and notifies automatically.
Recurring billing view.
A view built for oversight
We built an "Update" view with four tabs — Pending, Processing (flagging if the tenant's notification went stale after a later edit), Completed, Ignored. Rows can be bulk-edited from one modal: set the percentage, choose whether to notify tenants, apply to the whole selection.
Bulk update view and process
Two more touchpoints: calendar integration (requested by account management) and two opt-in monthly emails — one to the manager, one to the tenant. The Home dashboard got a new "Pending updates" card in place of the old "Properties/Owners" one.
Calendar view with upcoming updates and card of pending updates
Monthly reminder for the manager, and reminder for the renter
Built to last, on a stack that wasn't
Process: presented the approach, wrote the full PRD (49 pages, Google AI Studio), ran Q&A with developers, then a 4-day internal test I ran myself, contract by contract, filing every issue.
Impact
890 updates in, and growing every month
Launched February 23, 2026. Usage grew steadily, not a spike-then-flatten: 36 → 115 → 185 → 250 updates from April to July, dipping to 207 in August (holiday slowdown), 97 so far in September. 85 are pending today, 1 ignored. Even July's peak is still short of the 285–456 updates a month the full portfolio would eventually need — the setting is opt-in, so this is a system still climbing toward full scale, not a finished rollout.
7,238 lines
recurring lines with an index configured today
890 updates
applied automatically since launch, with no manual re-entry
25 clients
new clients captured since the feature shipped
~8%
of clients who'd churned specifically over not having this, came back
Pulled directly from the production database.
Reflection & what's next
What I'd push on next
Both the update setting and the monthly email are opt-in, off by default — the right call to ship safely, but it means many eligible lines still aren't switched on, simply because no one's gone in and done it.
The next move isn't a bigger feature, it's a smaller one: default it on for qualifying lines instead of relying on someone remembering to. Automation that still needs manual opt-in is only half done.
The bigger step: connecting directly to the official body that publishes each index, so Nester suggests the percentage instead of a manager looking it up by hand. Not feasible within this project's timeline, but the natural next move.