Articles
Urban Development
May 13, 2026
Most generative design work in real estate starts from a fixed input. You take a building system, a typology, or a product catalogue that already exists, and you write algorithms that arrange it intelligently on a site. The system was designed for humans. The algorithm adapts to it.
In 2023 we worked on a project in Vienna where the order was reversed. A developer with a custom modular construction system had designed the system itself with algorithmic placement in mind. The modules, the metadata, the structural rules, and the configurability were specified from the start to be machine-readable. We did not adapt our algorithms to their building system. They had adapted their building system to be algorithmically operable.
This is a subtle shift with significant consequences. It changes what the algorithm can do, what counts as a design decision, and where the bottleneck moves. This post is about what we learned from building that prototype, and why it matters for where modular construction is heading.
The building system was modular at its core. Volumes built from standardized modules, each with full metadata attached. Cost per module. Construction type. Allowed roof configurations. Permitted adjacency rules. The same physical system could be configured for four very different functions: hotel, student housing, senior living, and standard residential apartments.
That was the part that made the algorithmic ambition serious. The same modules, recombined with different rules, could produce four different building products. The configuration logic, not the modules themselves, was where most of the design intelligence lived.
Our job was to build an algorithm that took a site, the developer's modular library, and a target function, and produced placement and unit distribution proposals. Within each volume, the algorithm distributed units according to the function-specific rules. It selected construction type per zone. It chose roof type based on context. The output was not a sketch. It was a configurable prototype, ready for further refinement.
The most consequential difference from earlier projects was metadata. In a conventional generative workflow, you generate geometry and then bolt cost, structure, and construction information onto it afterward. The geometry leads, the data follows.
In this project, every module carried its full data payload from the start. When the algorithm placed a module, it was placing a specific cost, a specific construction system, a specific structural behavior, and a specific set of compatible neighbors. Geometry and data were the same object.
This collapses a workflow step that usually takes weeks. Traditional feasibility involves a sketch, then a quantity surveyor, then a structural engineer, each adding their layer of information to a geometry that was committed before they were consulted. When the geometry is already metadata-rich, the feasibility calculation runs in the same pass as the design generation. Cost, structure, and form converge in one loop.
The implication for risk compression is direct. The version of the project you see in the first iteration already contains the answers that traditionally only appear in iteration four or five.
The technically hardest part of the algorithm was not placement. It was adjacency.
In modular construction, vertical shafts for plumbing, ventilation, and electrical risers are not arbitrary. They must align across floors. They must connect to specific module types. They must be reachable from technical zones. A bathroom module needs to be within a defined distance of a shaft. A kitchen module similarly. A corridor module has its own rules.
This is the kind of constraint that defeats simple generative workflows. You can place modules optimally for daylight, for unit mix, for cost. Then the shaft requirement breaks the solution and you start over. We learned quickly that adjacency had to be a first-class citizen in the algorithm, not a post-hoc check.
The interesting consequence is that infrastructure ends up driving geometry in modular construction far more than in conventional building. In a traditional project, you design the layout and then route the services. In a modular system designed for algorithms, the shaft network and the adjacency requirements partly determine where modules can go before any aesthetic decision is made. The hierarchy of decisions inverts.
The single most useful idea to come out of the project was treating deviation from modularity as a quantified metric.
The premise was simple. A perfectly modular building uses only standard modules in standard configurations. Cost per square meter is at its lowest. Construction is at its fastest. But perfectly modular buildings rarely fit real sites or real briefs. There are always corners that need a non-standard module, transitions that require custom work, or constraints that force a section out of the modular grid.
The question is how much deviation a project can absorb before its modular advantage disappears. Traditional workflows handle this by intuition. A senior designer eyeballs the plan and decides it is "mostly modular" or "too custom." That judgment is unreliable and unrepeatable.
We made it measurable. For each generated option, the algorithm computed a deviation score: the percentage of the building that fell outside the standard modular library, weighted by the severity of the deviation. A pure modular configuration scored zero. A heavily customized configuration scored high. The developer could now see, before committing to a site, exactly how much custom work each option would require, and what the cost implication was.
This is a more useful framing than "is this site good for modular construction." Every site is good for modular construction to some degree, and bad for it to some degree. The question is the trade-off, and the trade-off is now visible.
Running the same engine across hotel, student, senior, and residential configurations was clarifying in an unexpected way. It revealed where modular construction actually scales, and where it does not.
Hotel and student housing were straightforward. Both have small, repetitive unit types, predictable circulation patterns, and tolerant structural requirements. The algorithm produced strong options quickly. The deviation scores were low.
Senior living was harder. Larger units, more varied accessibility requirements, more program complexity. The system worked, but the deviation scores were higher and the configurations required more careful constraint setup.
Standard residential was the most demanding. Unit mix variety, balcony placement, varied apartment sizes, market expectations about layout flexibility. The modular system was capable, but the algorithmic problem was significantly harder. More constraints, more adjacency considerations, more deviation pressure.
The lesson generalizes. Modular construction has been talked about as a single technology for a decade. In practice, its economics depend heavily on what is being built. Different building types stress the same modular system in different ways. A feasibility tool that does not distinguish between these cases gives misleading answers.
The site side of the workflow used zoning and regulatory data from the City of Vienna. The city makes much of its planning data available in machine-readable form, which is increasingly common in European municipalities but still uneven globally.
The algorithm consumed building envelope rules, height limits, setback requirements, and zoning category constraints directly from this data, not from a manually entered constraint sheet. When the developer wanted to test a different site, the city data flowed in automatically. The manual configuration step that had been a major time sink in earlier projects was largely eliminated.
This is a pattern that has only become more important since 2023. Modern early-stage feasibility is increasingly bottlenecked by data integration rather than by computation. Tools that can ingest zoning, parcel boundaries, topography, and infrastructure data without manual translation are the ones that change how feasibility actually gets done.
The intended users were not architects. They were business development teams inside the developer organization, and urban planners on the municipal side. The goal was to accelerate the early stages of project evaluation, before design teams were engaged.
This was deliberate. The bottleneck in early-stage projects is rarely architectural creativity. It is the time and cost of getting a credible first feasibility study. A business developer evaluating a piece of land wants to know, within a day, whether a modular system can produce a viable building program for that site, at what cost, with what deviation, and under what zoning interpretation. An urban planner evaluating a proposal wants to know whether the developer's claims about density, height, and program are realistic.
Both of those questions can be answered by an algorithm that has the right inputs and the right constraints. Neither requires a finished design. The tool was built to compress the time between "interesting site" and "informed decision."
Three observations have aged well since 2023.
First, building systems that are designed for algorithms produce a qualitatively different kind of feasibility output. Not faster sketching, but feasibility that is already structurally, financially, and constructionally specified. The integration tax that usually appears at handoff between phases largely disappears.
Second, deviation from modularity is the more useful question than fit to modularity. Every project deviates. The interesting work is in measuring how much, and where, and at what cost.
Third, the bottleneck in early-stage decisions has moved. It is no longer the production of geometry. It is the integration of constraints, data, and program intent into a single feasibility surface. Tools that handle that integration well will define the next decade of pre-construction software.
The Vienna prototype was a research project, not a commercial product. But the principles it explored have become part of how we think about parametric feasibility more broadly. Buildings designed for algorithms are not a niche of modular construction. They are a preview of what algorithmic feasibility looks like when the supply chain is ready for it.
