IT Infrastructure for Build-to-Rent Developments: What Developers Get Wrong

BTR is different from commercial fit-out

In a commercial office development, the tenant's IT team specifies and installs their own infrastructure within a shell. The developer provides the building, the risers and a comms room. What goes in them is someone else's problem.

Build-to-rent doesn't work that way. Residents aren't IT teams. They expect connectivity to work the way their mobile phone works – fast, immediate, covering every room, with nothing to configure. That expectation applies on move-in day, not after a two-week installation window.

This shifts the responsibility squarely onto the developer and operator. The in-building Wi-Fi, the residents' broadband service, the building management network, the access control system, the CCTV and the EV charging infrastructure all need to be designed, installed and managed as part of the building. Connectivity isn't a utility you can leave to the occupant. It's a service you're delivering – and residents will judge you on it.

That commercial reality matters. Poor connectivity leads directly to negative reviews on platforms like HomeViews and Google. It comes up in lease renewal conversations. It's a material factor in whether residents recommend the building to others. In a sector where word-of-mouth and review scores meaningfully affect occupancy rates, getting IT wrong has a commercial consequence well beyond the cost of remediation.

The most common mistake: specifying IT too late

The typical pattern we see is this: IT infrastructure gets mentioned at Stage 4 (Technical Design) or Stage 5 (Manufacturing and Construction), by which point the building layout is fixed, the riser shafts are sized, the electrical rooms are located and the ceiling voids are already planned around M&E runs. Everything that should have been decided in principle at Stage 2 now needs to be retrofitted into a fixed design.

The consequences are predictable. Comms rooms end up in the wrong location – too large for electrical equipment (which has different ventilation requirements), too small for IT equipment, or positioned so that cable runs to the furthest units exceed the 90m structured cabling limit. Riser routes conflict with pipework or ductwork that was designed without a cable containment zone in mind. External connectivity ducts are undersized or not routed to the right point on the building boundary for fibre providers to connect.

Retrofitting structured cabling in an occupied or near-complete building costs three to five times more than installing it during construction. Comms room conversions mean repurposing finished space. In BTR, where the development margin is already tight, this is a significant and avoidable problem. We're also seeing more claims against contractors and architects for inadequate IT specification – as BTR operators become more sophisticated, the tolerance for 'we didn't think about that' is falling.

What needs to be decided at Stage 2

Stage 2 – Concept Design – is when the building's floor plate, core arrangement and service strategy are being established. It's the right point to lock in the following IT infrastructure decisions.

Comms room location and sizing. A BTR development needs at least one dedicated IT comms room per 50 units, sized at a minimum of 10m². This must be a separate room from the main electrical intake – different ventilation requirements, different access controls and different maintenance regimes mean they shouldn't share a room. The comms room needs a clear cable route to the building entry point (where external fibre will terminate) and to the riser shafts serving each floor.

Riser locations and containment routes. Horizontal and vertical cable containment needs to be planned in coordination with M&E from the outset. Cable trays, trunking routes and conduit through walls should be agreed before M&E design is finalised – not worked around it after the fact.

External connectivity strategy. Full-fibre wayleave agreements with ISPs need to be initiated early. The lead times for wayleave agreements, particularly with Openreach on non-FTTP estates or with alternative network providers (altnets), can run to several months. Starting this process at Stage 2 means the wayleave is in place before the building reaches practical completion. Starting it at Stage 5 typically means residents move in without broadband.

Connectivity model. The fundamental commercial decision – exclusive ISP partnership or open-access fibre – needs to be made at Stage 2 because it determines what passive infrastructure you need to build.

Exclusive ISP vs open-access: the right model for BTR

An exclusive ISP arrangement means the developer signs a long-term agreement with a single provider, who installs their active equipment and provides broadband to residents. The upside is simplicity – the ISP funds or subsidises the infrastructure in exchange for exclusivity, and the operational burden sits with them. The downside is that residents have no choice of provider, which is increasingly a point of friction. Some residents have existing contracts, brand preferences or specific business requirements that an exclusive arrangement doesn't accommodate.

An open-access model means the developer owns and maintains the passive infrastructure – the fibre to each unit – and multiple ISPs can connect to it. Residents choose their own provider. This is the model that BTR operators and residents increasingly prefer, and it's aligned with the direction of government connectivity policy. The trade-off is that the developer carries the capital cost of the passive infrastructure and takes on a long-term maintenance obligation.

For most BTR schemes, open-access is the right long-term answer. Resident expectations around provider choice are rising, and exclusivity arrangements are starting to appear in planning conditions as a negative factor. The passive infrastructure cost is manageable when it's built in from Stage 2. It becomes significantly less manageable when it's retrofitted.

In-building Wi-Fi: why consumer mesh doesn't scale

Consumer mesh Wi-Fi systems – the kind residents buy from Amazon and plug in themselves – are designed for a single household. They rely on a shared SSID, self-organising backhaul and relatively simple RF environments. In a multi-dwelling unit (MDU), none of those assumptions hold. Signal bleeds between units, adjacent networks interfere with each other, the RF environment is complex and the shared SSID creates security exposure between residents.

A proper MDU Wi-Fi system for BTR uses dedicated access points per unit or per corridor, a centralised controller (either cloud-hosted or on-premise), and managed bandwidth allocation per unit so that one resident can't saturate the shared upstream. Each residential unit gets its own SSID – residents see their own Wi-Fi network, not a shared building network. The building management systems get a completely separate SSID on a separate VLAN.

The access points in a well-designed system are ceiling-mounted, PoE-powered and connected back to the comms room via structured cabling. They're not consumer devices – they're managed infrastructure. Common platforms for MDU deployments include Ruckus, Ubiquiti and Cambium. The system should include a management portal that allows the operator to monitor connected devices, bandwidth usage and fault status per unit without accessing residents' traffic.

Building-wide networks beyond resident connectivity

Resident Wi-Fi is one network. The building needs several others – and they shouldn't share infrastructure.

The building management system (BMS) that controls HVAC, heating and ventilation needs its own network segment. CCTV cameras and access control readers need another. Concierge systems – intercom, parcel management, visitor access – need a third. EV charging management platforms, which are increasingly required under Building Regulations Part S for new residential buildings, need their own network connection to communicate with the EVCP back-end and to enable smart charging without exposing the resident network to industrial control traffic.

These should be separate VLANs at minimum, and in many cases separate physical infrastructure – dedicated switches and containment runs. The principle is the same as in commercial buildings: systems with different security profiles and different failure tolerances don't belong on the same network segment. A CCTV system compromise is a security incident; a CCTV system on the same VLAN as resident Wi-Fi is a significantly worse security incident.

Smart building features that need early infrastructure planning

Several features that are now expected in premium BTR – or that developers are actively specifying to differentiate – have infrastructure dependencies that must be planned at Stage 2.

Smart access control. Replacing physical fobs with mobile credentials (via NFC or Bluetooth) requires an IP-connected reader at every access point: main entrance, car park, lifts, bin stores, amenity spaces and each apartment front door. PoE structured cabling to each reader point needs to be in the cabling design from the start.

EV charging management. EVCP management systems require a network connection per charger. Where there are multiple chargers in a car park, a local network switch and containment route to the comms room needs to be planned.

Energy monitoring per unit. Sub-metering at the unit level – increasingly expected for sustainability reporting and for fair billing in all-inclusive rent models – requires smart meter connections back to a central data point. Where this is done via a wired network rather than a wireless mesh, containment routes need to be planned as part of the M&E design.

Parcel locker systems. Automated parcel lockers require a network connection for the management platform and, where they have integrated access control, for the unit unlock mechanism. A single network drop to the locker bank location is usually sufficient – but it needs to be there.