Co-living feasibility modeling breaks a lot of spreadsheets built for conventional multifamily, and the reason usually comes down to one structural decision: whether the model is built around revenue per unit or revenue per bed. Get that wrong at the start, and every downstream metric occupancy, NOI, cap rate ends up distorted in ways that aren't obvious until lease-up data starts coming in.
This is worth walking through carefully, because it's less a stylistic modeling choice and more a fundamental difference in what the asset actually is.
Why Revenue Per Unit Breaks Down for Co-Living
Conventional multifamily feasibility models revenue at the unit level because that's the actual transaction one tenant, one lease, one unit. Co-living doesn't work that way. A single unit might have four or five bedrooms, each leased individually to a different tenant, with shared common space factored into the rent structure. Modeling that unit's revenue the way a conventional multifamily model would one blended rent figure per unit collapses information the feasibility study actually needs.
The practical issue: a co-living unit with five beds at 90% occupancy isn't performing the same as a unit with five beds at 100% occupancy, even though a unit-level model might round both to "occupied." Revenue per bed captures that variance. Revenue per unit hides it.
Simplified illustration — not real figures
unit_revenue_model = {
"unit_1": {"beds": 5, "occupied_beds": 4, "rent_per_bed": "market_rate"},
"unit_2": {"beds": 5, "occupied_beds": 5, "rent_per_bed": "market_rate"}
}
A unit-level model might record both as "leased"
A bed-level model correctly shows unit_1 at 80% bed occupancy
Operating Expenses Don't Scale the Same Way
This is where co-living feasibility modeling gets genuinely harder than conventional multifamily. Operating expenses in co-living don't map cleanly to either the unit or the bed they map to the building's shared infrastructure and turnover frequency, both of which behave differently than in conventional rental housing.
Turnover is a good example. Co-living tenants, especially in markets with younger, more mobile renter bases, tend to have shorter average stays than conventional multifamily tenants. Higher turnover means higher unit-turn costs, more frequent cleaning and furnishing refreshes if the unit is furnished (which most co-living product is), and more leasing and marketing spend per bed than a conventional model would assume. A feasibility model that borrows opex assumptions from a standard multifamily comp set will typically understate these costs, sometimes significantly, because the underlying operating pattern is closer to hospitality than conventional residential.
Building the Bed-Level Model Correctly
A defensible co-living feasibility model generally needs three layers that a conventional multifamily model doesn't require in the same form:
Bed-level revenue tracking. Each bed gets modeled with its own occupancy assumption and rent, rolled up to unit and then building level, rather than starting from a blended unit rent and working backward.
Common area cost allocation. Shared kitchens, lounges, coworking space, and amenities need a cost allocation methodology typically per bed rather than per unit since the shared space serves individual tenants, not units as a whole.
Turnover-adjusted opex. Operating expense assumptions need to reflect the higher-turnover, furnished-unit reality of co-living rather than being pulled directly from conventional multifamily benchmarks.
Feasibility platforms built for this need to handle bed-level granularity as a first-class input rather than a workaround. FeasibilityPro.AI's modeling structure, for instance, allows revenue and occupancy assumptions to be built at the bed level and rolled up automatically, which matters because manually reconciling bed-level and unit-level data in a generic spreadsheet template is where a lot of feasibility errors creep in. Other platforms like EstateMaster tend to be more oriented toward conventional multifamily and require more manual adjustment to handle bed-level granularity accurately.
Where This Matters Most in GCC Markets
Co-living and student housing product in GCC markets, Dubai and Riyadh in particular, often serves a tenant base with different stay-length patterns than co-living products in, say, London or New York. A meaningful share of demand comes from young professionals on shorter-term assignments or students in academic-year-length stays, which pushes average turnover even higher than in some Western co-living markets. Feasibility models built without adjusting for this local pattern using, for instance, a US or UK average length-of-stay assumption tend to understate both turnover costs and the marketing spend needed to keep bed occupancy stable through the year.
Market intelligence from JLL and Colliers on co-living and PBSA (purpose-built student accommodation) absorption in these markets is a more reliable benchmark source here than generalized multifamily data, precisely because the tenant behavior patterns are different enough that conventional residential comps don't transfer cleanly.
The Practical Takeaway
The revenue-per-bed versus revenue-per-unit decision isn't a modeling preference; it's a structural requirement for co-living feasibility to produce numbers that hold up against actual operating performance. Teams that try to force a conventional multifamily template onto co-living product, at unit-level granularity, tend to discover the gap during lease-up, when actual bed occupancy and turnover costs don't match what the pro forma assumed.
Curious how others here are handling the common area cost allocation piece specifically per bed evenly, or weighted by unit size and shared amenity access?
Top comments (0)