Articles
Urban Development
May 13, 2026
The Netherlands is one of the most digitized real estate markets in Europe. Cadastral data, zoning information, building footprints, height data, soil conditions, and infrastructure networks are all available in structured, machine-readable form. For a generative feasibility tool, this is unusually fertile ground. The constraint layer is not something you have to build manually. It is already there, waiting to be queried.
This is the context for the workflow we built with Heijmans, one of the largest construction companies in the Netherlands. Heijmans had done something similar to other developers we have worked with: they had moved decisively toward product thinking. A defined housing catalogue. Standardized typologies. Templates with known dimensions and full design documentation. The product side was settled. The site was the variable.
This post is about what changes when product thinking on the building side meets digitized data on the site side, and what that combination produces for early-stage feasibility.
We have now seen this pattern from three angles. In our 2020 work with Bonava, the predefined products were standardized single-family houses, fully modeled in Revit, with the site as the only variable. In the 2023 Vienna prototype, a developer had built a configurable modular system, again with the site as the unknown. With Heijmans, the same logic applied: four predefined house types, mostly variations on row housing typologies, with fixed dimensions, fixed templates, and full BIM documentation linked through a database to their Revit files.
This is not an accident. It reflects a broader shift in how serious housing developers operate. The economics of bespoke design for every project do not survive in a market that demands speed, cost predictability, and quality consistency. The companies that have moved furthest are the ones that have stopped treating each project as a new architectural problem and started treating each project as a placement problem.
The architectural decisions have moved upstream. They happen once, when the product catalogue is designed. Each project then becomes a question of which product, where, in what configuration, given the constraints of a specific site. This is the question generative feasibility is built to answer.
Four predefined house types. All variations on row housing typologies, which is a smart commercial bet in the Dutch market where row housing is the dominant residential form. Each type came with fixed external dimensions, defined templates, and a complete data package: floor plans, sections, structural specifications, material schedules, and cost data.
The Revit files for each type lived in a centralized database. Our algorithm did not need to carry the full geometry. It worked with a lightweight reference representation, equivalent to LOD 100, that captured the external envelope, key dimensions, and the placement constraints for each type. The detailed BIM model remained in the database. The algorithm pointed to it.
This separation matters more than it sounds. Working at LOD 100 inside the generative loop made the algorithm fast. Hundreds of layout iterations were computationally feasible because each iteration was manipulating envelopes and placeholders, not detailed geometry. When a layout proved promising, the link back to the database let the user pull the full BIM detail for any selected configuration. The trade-off between iteration speed and information depth was solved by reference rather than by simplification.
The Netherlands publishes an unusual amount of planning and building data in open formats. The BAG dataset provides building footprints, construction years, and use categories for every building in the country. AHN provides nationwide elevation data at high resolution. Cadastral boundaries are public. Zoning plans are available through ruimtelijkeplannen.nl. Soil and groundwater data are accessible through environmental agencies.
For a feasibility tool, this changes the unit economics of site analysis. The manual data preparation step that often dominates early-stage work is largely removed. A site can be loaded with its full constraint context in seconds. Setback rules, height limits, environmental constraints, neighboring building heights, and topography all flow in as data, not as manually entered parameters.
We integrated this directly into the Heijmans workflow. When a business developer or planner pointed the tool at a parcel, the constraint layer assembled itself. The algorithm could then run placement options for the four house types against the actual regulatory and physical envelope of the site, not against an idealized version of it.
This is why Hektar works well in the Netherlands today. Much of the Dutch data infrastructure is already part of how the tool operates. The site side of the feasibility loop is genuinely automated for Dutch projects in a way it is not yet for many other markets.
The choice to work with LOD 100 placeholders linked back to detailed BIM is worth dwelling on, because it represents a wider principle about how generative feasibility should be structured.
Traditional BIM workflows assume that level of detail increases over time. You start with massing studies at LOD 100, develop to LOD 200 for design development, refine to LOD 300 for documentation, and continue toward construction-ready models. Each level represents more committed information, more decisions made, more flexibility lost.
Generative feasibility inverts this. The early stage is precisely where you want maximum optionality. Hundreds of placements, dozens of configurations, multiple typology mixes. You cannot iterate at LOD 300. You can iterate at LOD 100.
But you also cannot make commercial decisions at LOD 100 alone. The detailed BIM model contains the answers to the questions that matter for commitment: structural feasibility, exact material specifications, MEP coordination, code compliance. The trick is to keep these two representations connected, so that the lightweight model for iteration can pull from the detailed model for verification whenever a decision needs to be defended.
The Heijmans workflow did this through the database link. The algorithm placed envelopes. Each envelope was a pointer. Pull the pointer, get the full Revit file. The two representations were the same product at different resolutions, and the user could move between them as the question demanded.
One of the recurring questions in this kind of work is what role the architect plays. The honest answer is that the role moves rather than disappears.
In a traditional residential project, the architect designs the buildings for the site. In a product-thinking workflow, the architect has already designed the buildings. The work has happened upstream, in the catalogue design. What remains for each project is the urban design question: how do these buildings sit on this specific piece of land, in this specific neighborhood, with this specific access pattern.
This is not a smaller question. It is a different question. Site geometry, parcel orientation, edge conditions, public space, and circulation all become the design problem, while the buildings themselves are mostly fixed. For Heijmans, this meant their internal design teams could focus on the urban scale and the site response, rather than redesigning row houses for every commission.
It also clarifies who the early-stage tool serves. Not the architect doing creative work. The business developer evaluating whether a piece of land works for the product line, the urban planner verifying that the proposed placement respects the planning context, and the design lead who eventually receives a starting point that already contains the technical commitments.
Three projects, three countries, three building systems, and a shared structural insight. When you have a product catalogue, generative feasibility becomes tractable. When you also have digitized site data, it becomes fast. When you have both, the time from "interesting parcel" to "informed decision" collapses from weeks to hours.
The differences between the projects are instructive. Bonava worked at the single-family scale with a catalogue of detached houses. The Vienna prototype worked at the modular scale with a configurable system across four functions. Heijmans worked at the row housing scale with four typology variations and full BIM integration. Different scales, different markets, different building systems. The underlying logic is the same.
What unites them is that all three companies had done the upstream work of treating their buildings as products. That commitment is what makes the downstream feasibility loop possible. A developer without a product catalogue cannot run a meaningful generative workflow, because there is nothing to generate from. Generative feasibility is downstream of product thinking, not a substitute for it.
For developers and construction companies that have not yet moved to a product approach, the Heijmans workflow points to where the leverage is. Investing in a catalogue, in standardized templates, and in centralized BIM is not just a cost reduction strategy. It is the precondition for being able to use generative tools effectively. Companies that skip this step and try to apply generative feasibility to bespoke designs end up with workflows that fight against themselves.
For markets like the Netherlands, where the data infrastructure is already in place, the question is no longer whether the technology works. It is which developers will commit to the product thinking that makes the technology useful. The early movers will have a meaningful speed advantage over the next decade. Smaller teams in particular benefit from this pattern, because it lets them operate at a scale of analysis that was previously available only to large organizations with dedicated computational staff.
The Heijmans project, like the Bonava and Vienna projects before it, was less about a single algorithm and more about confirming a pattern. Predefined products plus digitized sites plus a generative feasibility loop produces a category of decision-making that did not previously exist in early-stage development. Faster, more structured, more comparable, more defensible.
The product thinking did the hard work upstream. The data infrastructure carried the site context. The algorithm did the placement. What the tool actually delivered was something more valuable than any of these individually: a fact-based way for business developers, planners, and design leads to look at the same site and reach the same conclusion at the same time.
