What a build-to-rent unit selector actually costs

In the second January after launch, a letting manager at a rental building we had built the site for rang to ask why a two-room flat on the fourth floor was not showing on the website. The tenant had given notice in November and moved out before Christmas. Somebody on her team, she was not sure who, had marked the flat as sold on the day the lease was signed, becuase that was the status that took it off the list, and there was no status for it to come back to. The flat had been empty and invisible for three weeks. She asked how many others were like that. Neither of us knew.

The build is one invoice. What a rental building actually pays for its unit selector is spread over every tenant turnover for thirty or forty years, and the biggest line is the void day, which appears on no invoice at all.

The invoice, and the building it was built for

We built a unit selector for St. Gallen, 110 rental apartments in Switzerland. Filters by monthly rent in CHF, rooms, floor and balcony size. A leased apartment drops out of the list on its own. Favourites, a shortlist you can compare side by side, a PDF per apartment. The letting team uses it as their live inventory. That is one project, one build, one invoice, and it is the only line most operators budget for.

Filters built for a purchase

Sale filters centre on total price, deposit and settlement date. A rental prospect searches by monthly rent, lease term, move-in date, pet policy and what is included. Those are five diffrent questions, and a platform built for sales arrives with answers to the wrong ones. Swapping the filter set is a seperate build rather than a setting. A prospect who cannot filter by pet policy across 300 units sends an enquiry anyway, and the leasing team spends an afternoon on a conversation that was never going to convert.

Sub-types stretch it further. Student housing lets by the room, co-living by the bed, serviced apartments by a bundled rate, and each needs its own data model. That is the second build, and the building is not open yet.

The unit page as the whole leasing office

Pre-leasing a 300-unit community starts months before the building is finished, so the prospect chooses from renders, floor plans and a 3D walkthrough with no visit to fall back on. The unit page has to carry enough for someone to apply from another city without stepping inside.

Then the channel sync. The unit shows on the project site, on the listing portals and in the operator's app, and a lease signed on one of them has to disappear from the others within minutes. The first double-booking is usually how an operator learns what that integration costs. It grows with unit count and with turnover, so it keeps growing as the building fills.

No path from sold back to available

A tenant leaves and the unit has to go back on the market. On a platform where sold is a terminal status there is no path back to available. Someone resets the status by hand, re-enables the filters and relists the unit, and the void lasts however long that takes, plus however long it takes anyone to notice. The flat on the fourth floor was three weeks of the second part.

What a turnover costs the letting team

A 300-unit building turns over constantly. Every turnover that needs a manual reset, a relisting and a filter check is time the letting team absorbs as overhead. It shows up as a longer void and a slower lease-up, and it does not show up in any budget line, which is why it survives year after year.

Void days over the life of the building

The right denominator for void-day cost is gross rental income over the life of the building. A 300-unit community runs for 30 or 40 years. Void-day cost per turnover, times unit count, times operating years, is a percentage of total rental income, and I have not met an operator who calculates it, because no invoice ever showed it to them.

This is not for a development that sells rather than lets. A unit that sells once has no turnover cost, and there the platform invoice really is the whole cost. The moment a unit has to come back to market, the invoice stops being the whole cost.

What moves the void day is a status model that lets a unit go from leased to notice given to available without anyone opening a spreadsheet. The test is easy to run on any platform, ours included. Ask what happens to this unit's listing the day after the tenant gives notice. If the answer involves a person updating a row, the void starts on that day. A sale-oriented status model does not pass that test today, and if you are choosing a platform for a rental building, that is the question to ask before the one about renders.