The Terner Housing Policy Simulator (“Simulator”) is a tool which enables policymakers and researchers to simulate the impact of various policy scenarios on the financial feasibility of housing development.

The Simulator models a comprehensive suite of feasible multifamily developments on a site, the financial viability of each potential development, and the likelihood of development for the most profitable option. Users can then toggle between policy scenarios and compare their potential impact on future development.

The Simulator uses a built-in proforma, a financial projection which estimates the potential profitability of rental projects. It analyzes hypothetical projects, from duplexes to 1,000-unit buildings, which conform to site regulations and user input assumptions across potentially hundreds of thousands of parcels.

The below provides a detailed explanation of the Simulator methodology, including our data sources and the Simulator’s assumptions.

The Terner Housing Policy Simulator (“Simulator”) is a tool which enables policymakers and researchers to simulate the impact of various policy scenarios on the financial feasibility of housing development.

The Simulator models a comprehensive suite of feasible multifamily developments on a site, the financial viability of each potential development, and the likelihood of development for the most profitable option. Users can then toggle between policy scenarios and compare their potential impact on future development.

The Simulator uses a built-in proforma, a financial projection which estimates the potential profitability of rental projects. It analyzes hypothetical projects, from duplexes to 1,000-unit buildings, which conform to site regulations and user input assumptions across potentially hundreds of thousands of parcels.

This document provides a detailed explanation of the Simulator methodology, including our data sources and the Simulator’s assumptions.

Broadly, the Simulator works as follows:

1. For each parcel, the Simulator first conducts a simple and generic building massing to estimate the largest unit count that can fit on each parcel. This maximum unit count is first constrained by physical characteristics of the parcel (lot size, certain existing features limiting developable area), then constrained by local land use and development regulations (e.g., maximum building heights, floor area, density limitations, parking space requirements).
   

2. Next, the Simulator uses its proforma to calculate the type of development (e.g., small multifamily, high-rise apartment building) and corresponding number of units with the strongest financial performance. We call this output the “optimal development.” This calculation uses assumptions (e.g., economic conditions, development timelines, fees, construction costs, operating revenue) that are constant across all simulations but can be adjusted from the baseline settings by the user. This calculation also considers the parameters that users can manipulate from one simulation to the next (i.e., parking inclusion, fee amounts, or zoning allowances).
   

3. The Simulator then estimates the probability that the optimal development might actually be built in the future. This probability is based on a statistical analysis of past development data. This analysis quantifies the relationship between the financial metrics of a potential development (from the Simulator’s proforma) and whether a new multifamily residential building was actually built on a given parcel. Based on these statistical relationships, the Simulator calculates the probability that what it has determined is the optimal development with similar financial metrics will be permitted in the future.
   

4. From there, the Simulator calculates the “expected number of units”: the number of units in a parcel’s optimal development multiplied by the associated probability of development. For example, a parcel with an optimal dwelling unit count of 100 and a development probability of 10 percent has an expected number of units of 10. The expected number of units that would be developed citywide is the sum of the expected number of units for all parcels.

Differences in the expected number of units under each policy scenario can result from a combination of two types of changes. First, the optimal development on a parcel could change, resulting in a different number of units. For example, the optimal development for a given parcel might have 10 units for the baseline scenario, but it could increase to 15 units if a larger building would fit if fewer parking spaces were included. Second, the estimated financial metrics and associated probability of development could change. For example, the optimal development for a given parcel might be 10 units for both scenarios, but the probability of development might increase.

The Simulator is made up of the following files and programs:

• Parcel file: Contains the parcels of a city or county including coordinates and geometry attributes. This is sourced from local or county governments. We match assessed values to parcels and impute missing and outlier parcel values using a hedonic model trained on available assessments and sales data from assessors and building industry data sources. We exclude undevelopable portions of parcels such as slopes (see Note 1), public easements, rivers, parks, airports, graveyards, and roadways based on geographic data from OpenStreetMaps™ (see Note 2 for a comprehensive list of excluded attributes). For condominium developments, parcels that are vertically stacked or artificially subdivided to building footprints are aggregated and dissolved to the base lot geometry. These parcels are flagged as condominium parcels, and the Simulator retains the flexibility to either exclude them from the simulation or include them with an added land-value cost to account for negotiation complexity arising from fragmented ownership.

• Assumptions layer: Controls the economic, construction, and financial assumptions used in our proforma calculations. Assumptions can vary by zoning category, neighborhood, city, county, or state, or remain consistent across all Simulators.

• Zoning layer: A shapefile containing zoning geometries and associated construction rules within the zoning code which will be spatially joined to the parcel file. This is sourced from local or county governments.

• Generic proforma: The core calculation behind Simulator outputs, through which all parcels undergo analysis to determine the profitability of developing housing. For each parcel, up to 60 hypothetical projects will be evaluated through 10 modules to determine the profitability of each project. The proforma’s modules are explained in section 2 below.

• MapCraft™ web application: MapCraft provides the back-end computing power and online interface for users developing scenarios. Via the MapCraft interface, users can view a map of the expected number of dwelling units built and other outputs for each parcel. Users can see results for various scenarios by toggling economic, zoning and other policy factors.

Parcel files, zoning files, and fee information are sourced from city or county websites or provided by planning department staff. Economic assumptions are sourced from federal data sources or building industry reports. Some local development and economic assumptions are provided as direct feedback from multifamily developers working in those jurisdictions, or from actual project budgets/proformas shared with Terner Labs.

The Simulator proforma consists of 7 core modules that estimate the construction parameters, cost, and revenues of a project at each stage of its development, from land acquisition to disposition (the re-sale of a property once development is completed).

The building envelope module determines how many units can be built on a parcel based on the zoning regulations and physical restrictions of the parcel (in this context, the “building envelope” refers to the approved size and shape of allowable construction). The Simulator begins by modeling 60 hypothetical apartment projects by density. The lowest-density project is a duplex (2 units) and the highest-density is a 1,000-unit building. The Simulator assumes that each unit in a project is a 2-bedroom unit, sized between 900 - 1,100 square feet depending on the jurisdiction-specific default assumption. The Simulator does not yet determine a single allowed number of units for a site, that happens later; rather, it evaluates whether each of the 60 potential building sizes falls within the constraints of the parcel and its zoning requirements.

The land use policy which determines the building envelope is drawn from the jurisdiction’s zoning regulations, including:

• Maximum and/or minimum floor area ratio (FAR)

• Maximum dwelling units per lot

• Maximum and/or minimum dwelling units per acre (DUA)

• Maximum height of buildings (both feet and number of stories)

• Maximum lot coverage of the building footprint

• Averages of the setbacks on the front, back, and sides of parcels

• Maximum and/or minimum parking requirements per dwelling which determines amount of parcel land reserved for parking spaces

The building envelope module will determine the maximum unit count a project can construct on a parcel and disqualify building scenarios that exceed the limit.

To determine the maximum number of dwelling units that can be built on a parcel, the building envelope module calculates up to four different theoretical maximum dwelling unit limits, depending on what aspects of a zoning code are applicable for the parcel. Unless certain conditions can be ignored under a certain policy, a development’s maximum density is determined by the most restrictive of four zoning conditions (see exceptions in Note 3):

• A direct limit on maximum dwelling units per lot

• Maximum dwelling units per acre and the parcel’s acreage

• A simplified massing exercise determining maximum density by floor area ratio and allowable building footprint

• A simplified massing exercise determining maximum height and lot coverage limits
  

If zoning does not specify one of these conditions, then it will be ignored, and the other conditions will be used to calculate maximum theoretical density. When maximum lot coverage is not regulated through zoning requirements, the envelope assumes that the building footprint is a square, and maximum lot coverage is obtained by reducing twice the site’s average directional setback from each side of the square. This calculation generates the buildable area. The number of assumed surface parking spaces included on a given project directly impacts the maximum building footprint that the building envelope calculates (more details on parking are included in the construction section below). If lot coverage is specified, then the same formula is applied on a square of the specified size.

For each scenario, the construction module returns a parking structure type, a building type (low-, mid-, or high-rise), the height of the building, and its associated construction costs, entitlement costs, and building time in months. The Simulator defaults to assuming that construction will take 14 months for low-rise buildings, 18 months for mid-rise, and 24 months for high-rise, unless these assumptions are changed by the user.

The construction module estimates construction costs for each of the 60 different housing project types described above that fall within the allowable density derived from the building envelope. Project sizes that exceed zoning requirements in the building envelope module or are physically impossible within parcel constraints are excluded.

In real estate development, buildings are often referred to as low-rise, mid-rise, and high-rise (specifics are provided below in 2.2.3). The Simulator determines which type of building (low, mid, or high rise) best accommodates a project’s maximum density, and for each applies a fixed marginal cost per square foot, maximum height, and a maximum density based on industry standards. Baseline assumptions listed in sections below may vary by state.

Parking costs are estimated by multiplying the cost-per-square foot costs of each parking type (surface, underground, and aboveground) by the minimum number of spaces or stories required by local and state parking regulations or user-adjusted toggles. The Simulator assumes that each parcel’s parking is either all surface, all aboveground, or all underground (not a mix of types).

The parking structure that allows for the least costly building type is prioritized, even if the parking structure itself is more expensive. For example, if a mid-rise project is possible with above-ground parking, but fitting the same number of units using cheaper surface parking would require the building to be a high-rise, the Construction module will pick the mid-rise because the overall project will likely be cheaper. If a project is mid-rise under either parking typology option, the proforma will opt for the cheaper surface parking over aboveground parking.

The maximum amount of surface and aboveground parking, respectively, are determined as follows (see Note 4 for exceptions). Underground Parking is only utilized if aboveground and surface parking is not physically feasible.

• Maximum surface parking: The minimal surface area needed to accommodate the set number of units, given average dwelling square footage and the maximum number of floors subtracted from the maximum buildable lot area (lot size times the derived maximum lot coverage). The difference is divided by the gross square footage of a surface parking stall.

• Maximum above-ground parking: The square footage needed for accommodating the set number of dwellings, given average dwelling square footage, subtracted from the maximum buildable square footage (lot size times the derived maximum lot coverage times max height in floors). The difference is divided by the gross square footage of a non-surface parking stall.

Parking areas are assumed to be as follows:

• Aboveground Parking: 400 square feet per stall

• Surface-Level Parking: 330 square feet per stall

• Underground Parking: 400 square feet per stall

The construction module also calculates the estimated entitlement cost of each project scenario, based on the size of the building and subjective political assumptions. These include:

• Entitlement duration: default assumptions vary by jurisdiction and building typology. Default assumptions are provided by city staff based on prior studies or through formal reports to state agencies. Users can change these assumptions in the interface using input toggles.

• Entitlement cost: This is assumed to vary by building size as well. For 2-4 unit buildings the entitlement process is assumed to add 1% to the total construction cost (which excludes the cost of land). For 5-49 unit buildings, it is assumed to add 3% to that cost, and 5% for 50+ unit buildings.

• Entitlement density compromise: The entitlement process can result in lowered development density, as developers sometimes reduce the density of proposed developments in order to win project approval. To incorporate this possibility, we allow users to toggle what we call the "density compromise amount" (the percentage a proposed project’s density is likely to be lowered by during the community engagement process). The default setting is to not reduce unit count below the entitled amount; however, the user can toggle different density compromise amounts by building type.

Each building type (low-rise, mid-rise, and high-rise) assumes a fixed marginal cost per square foot. These costs vary by jurisdiction and can be adjusted by the user. Default values are sourced from building industry and other county-level economic reports (data is mostly limited to 2023 but is inflation-adjusted for the current year) and in some cases are validated through interviews with local developers. Users have the option to choose different construction timeframes for each building type.

We assume the following for each building type (“construction type” here refers to the International Building Code’s system for classifying buildings by their fire resistance capabilities).

• Low rise:

  • Construction type VB for buildings with 2-4 units; VA for buildings with 5+ units

  • Building height: 1-4 stories

  • Building material: Wood frame

  • Maximum density: 30 dwelling units per acre

• Mid rise:

  • Construction type V1

  • Building height: 5-8 stories

  • Building material: Concrete podium with wood frame structure

  • Maximum density: 100 dwelling units per acre

• High rise:

  • Construction type IA

  • Building height: 9+ stories

  • Building material: Steel frame

  • Maximum density: 400 dwelling units per acre

The fee calculator module uses a collection of local fee schedules to calculate anticipated fee amounts per parcel and building type for each jurisdiction. Fees applied through districts that spread beyond city limits such as utility, water and school districts are also included.

Certain local fees are incorporated differently depending on the way in which they are apportioned, e.g. as a lump sum fee, or in proportion to the number of dwellings, the square footage, or the construction cost. Fees are collected from city, county, and special district fee schedules and categorized as environmental fees, impact fees, building services fees, or planning department fees. We cross-reference these fees with the fees actually paid (if city or county staff provided this information). Certain fees are “flat fees” and apply to all projects citywide. Users can experiment by setting these fees or voiding them using toggles. Valuation per square foot is sourced from the given jurisdiction or the International Code Council’s Building Valuation Table.

The operating revenue module determines the average net operating income per unit. Net income is rental income minus the income lost to vacancies (sourced from CoStar data on new rentals in local submarkets) and operating expenses. Operating expenses are a percentage of a building’s overall revenue.

Income is calculated by multiplying the number of market-rate units by the average rent price for newly constructed rental units of a similar density in the area, sourced from CoStar™. Depending on the jurisdiction or policy toggles employed by the user, a portion of the units may be considered below market-rate (BMR) units, and a portion of the total project income will consist of BMR rents in addition to the market-rate rents. BMR rents and the discount on them relative to market-rate are calculated from the county or HUD income limit and will fluctuate depending on the affordability level toggled by the user (e.g., moderate income, very low income or extremely low income).

Operating expenses for a multifamily building include property management, staffing, janitorial services, utilities, property taxes, insurance, maintenance, repairs, and replacement reserve. The Simulator assumes these operating expenses result in a 30% reduction from gross operating income to net operating income (this figure comes from a MapCraft analysis of industry standards).

The financial outcomes module calculates financial outcomes for all housing projects not yet disqualified.

A key component of the Simulator’s financial metrics is the assumed cost of acquiring the land and any existing building. This is also the only way in which the existing use of the parcel is taken into account. There is no readily available source of information on every parcel’s current market value. To predict the cost of property acquisition, we use the following statistical modeling process based on commercial real estate and county assessment data:

1. Assemble spatial database of existing commercial properties (i.e., non-residential and apartments) from commercial real estate data

2. Adjust last sale price (where existing) to the current year’s value using a use- and neighborhood-specific index of mean sale values per square foot by year

3. Use a hedonic regression model (a statistical method used to estimate the value of property by decomposing it into its characteristics like location, size, year built, etc) to estimate the values of properties without last sale prices based on their attributes and neighborhood mean values

4. Assemble spatial database of existing ownership residential properties (i.e., single family homes and and multifamily ownership units) from assessment data

5. Adjust assessed value in relation to any location-specific property tax rules to generate a current-year property value

6. Use a per-acre minimum value generated from residential vacant land sale data to set a minimum floor for any parcels in the database without a value

The financial outcomes module calculates three financial outcomes for all housing projects not yet disqualified:

1. Residual land value to property value ratio (RLVPV): A static measure that divides the residual value of the development and land by the cost of acquiring the property

2. Net present value (NPV): Dynamically considers the timing of income to estimate the net value of a property post-development compared to its present value

3. Net present value per dollar of equity (NPV/E): Divides the NPV by the total equity of a project to determine investor return exclusively

These metrics are chosen to account for the monthly timing of cash flow, a demonstration of how multiple financial measures could be combined, and the lighter computational burden of NPV versus its sibling measure, the Internal Rate of Return (IRR).

These metrics are calculated using a variety of parcel-specific calculations and jurisdiction-specific assumptions including:

• Costs: land acquisition, building and parking construction costs, fee payments, and carrying costs (defined below)

• Timing: entitlement time, construction time, lease-up time, holding time, incorporating relevant inflation rates

• Financing: interest rates, loan to cost ratios, and investors’ preferred rate of return

• Revenues: net operating income, rent appreciation rates, capitalization rates, sale value

In addition to the assumptions noted above, the NPV and RLVPV additionally depend on the assumed capitalization rate at disposition, the typical loan-to-cost ratio that dictates necessary investor equity, investors’ preferred returns, and the duration of construction, as well as the cost of acquiring the land for development. NPV is the same as RLVPV, with the addition of investors’ preferred rate of return.

Cash flows relevant to each financial metric are calculated monthly. In each month’s financial calculations, costs are normalized and every major cash-flow input grows over time at the user-toggled nominal rates. Land acquisition costs are subject to a carrying cost, which reflects a variety of costs incurred by holding on to a property over time. Unless adjusted by the user, these are assumed to be:

• Fee inflation: 3% annually

• Construction inflation (MCC): 3% annually

• Carrying (property) cost inflation: 3% annually

• Carrying cost level: 1.5% of land value per year

The sequencing of fee payments and other costs reflect our best assessment of the payment schedules for typical projects, resulting in earlier-occurring fees receiving less discounting.

The following assumptions may vary by jurisdiction, are adjustable by users, and are updated by Terner Labs staff over time. Most financial assumptions are sourced from CoStar or from macroeconomic reports from Federal Reserve Economic Data (FRED) and include the following:

• Interest rate: Construction loans are assumed to persist through the sale of the development at the end of the stable period following absorption. The interest on loans is assumed to be 7% in 2025 based on FRED data for recent simulations. This assumption will update over time as rates shift.

• Loan to construction cost (LTC) ratio: The LTC ratio (the ratio of debt to equity) is assumed to be 65%.

• Multifamily cap rate: The capitalization rate used to infer the proceeds from selling the development from its net operating income. The capitalization rate varies slightly by area and is sourced from CoStar.

• Investors’ preferred rate of return: Investors’ preferred rate of return, which is essential in determining the residual land value, is assumed to be 10%. This figure is obtained fromMapCraft.

• Absorption: The time required to rent out the newly constructed units is assumed to progress at a pace of 30 units per month, and the stable period following absorption is assumed to take 18 months. These figures are sourced from consultation with select developers.

With income flow and residual value determined, the optimal building module will select the most profitable development scenario out of the up to 60 feasible project scenarios analyzed for a given parcel. The unit count and building type for each parcel determined to be financially optimal is the result that users will see in the Simulator. Subsequent statistical aggregations regarding overall housing development statistics for a region will also be based on the optimal dwelling unit count for each parcel.
Each development project is assigned a single score based on a combination of the residual land value to property value ratio (RLVPV), net present value (NPV), and net present value per equity dollar (NPV/E). This score reflects how consistently profitable a given development project is. To calculate the score, a Cobb-Douglas utility function is used, which favors scenarios and building types that perform moderately well across most or all financial metrics, rather than those that excel in a few areas but perform poorly in others (refer to Note 5 for details).

With the optimal project determined, the probability of a given project being built is estimated based on the historical outcomes of similarly-scored projects using the Terner Simulator probability model. The probability model is calculated outside of the proforma framework, and the resulting coefficients are applied after the Simulator’s proforma calculates feasibility metrics for each parcel. The probability model uses the historical relationship between financial feasibility metrics and observed multi-family residential development to estimate the likely number of residential units resulting from a given simulation.

The Simulator is grounded in the idea that developers tend to make rational, profit-maximizing choices about where and when to build new residential buildings in a city. While parcels with higher development feasibility metrics are expected to be more likely to develop, there are a variety of reasons that profitable parcels may not actually see development during a given time period. For example, the existing parcel owner may have highly specific and unobservable financial considerations. Another use not considered in the Simulator’s proforma may be more profitable (e.g., a hotel or office building). In a given year, there is a limited set of existing real estate developers that have access to a limited amount of capital. Even in a constrained market, only a limited number of new residents are able to occupy any new construction, and overbuilding will drive down prices in the short term, making simultaneous construction on all feasible sites not actually profitable.

The probability model is built by constructing “historical Simulators” in jurisdictions with current-year Simulators (see Note 6). These historical Simulators are meant to capture conditions about 5 to 15 years before the current year . Each historical Simulator uses historical zoning, land values, economic assumptions and rents to estimate past financial metrics derived from the Simulator’s proforma framework, and observe the relationship between those metrics and actual observations of development that occur during this historical period. The historical parcel file includes a field indicating whether development occurred on the parcel between the historical year and the current year, along with the year it was built and the number of units built. This data is primarily sourced from CoStar and county assessments.

A statistical model is then used to ground this historical rate of conversion in the macroeconomic and land use policy environment of the historical period, so that an improved conversion rate is available for various current-day scenarios where either or both of these factors may have changed. Specifically, a logistical regression model is used to model the relationship between the financial metrics from the historical Simulator and the observed development dataset (see Note 7). This model aims to capture the behavior of potential real estate developers present during the historical period. The unit of analysis is each parcel that legally allows multi-family residential development. An observed development event represents the case where a developer made the choice to build a new muti-family building. We assume the probability that a parcel is developed will increase in one direction as the financial feasibility metrics increase. We also expect other factors (both observable and non-observable) to make the relationship between the financial metrics and observed development less consistent.

Once estimated, the logistic regression model outputs are used in the historic Simulator to produce an initial estimate of the total number of housing units expected in the historical period. For a variety of reasons (e.g., missing data, miscoded data, idiosyncratic development approval patterns), the number of housing units expected in the historic period may differ from the number of units that were actually built. In this case, the logistic regression model’s coefficients are adjusted, or calibrated, to better hit the historic unit target.

Once estimated and, if needed, calibrated, the logistical regression model is used to predict the number of units likely to be built with a different set of proforma model inputs representing current or expected future conditions. This generally involves changes to the macroeconomic or policy inputs that impact the development feasibility metric. The model’s prediction assumes that similar levels for this metric (when compared to the recent past) will lead to similar probabilities of parcel conversion, and uses this relationship to predict the probability of parcel conversion with the modified inputs (for current or near-term future years). These probabilities are then multiplied by the proforma’s optimal dwelling unit output for each parcel and summed to calculate the number of annual expected units for a given scenario.