Articles
Urban Development
May 13, 2026
Most software conversations about generative design focus on the algorithms. The mathematics of how the engine produces configurations. The speed of iteration. The cleverness of the optimization. This is the wrong conversation. The single most important determinant of whether early-stage feasibility software is useful is not how the algorithm works. It is what data the algorithm has access to.
This post argues a simple thesis: the value of generative design in real estate feasibility is proportional to the quality and authority of the data layers feeding it. Without authoritative data on parcels, regulations, soil, flood risk, archaeology, noise, and infrastructure, generative output is decorative. With that data, generative output becomes defensible.
The structure of real estate development creates an asymmetry that anyone who has worked in the industry recognizes. Decisions made at the beginning are cheap to change. Decisions made at the end are expensive. The cost curve is not linear; it is closer to exponential.
A typology change in week two of feasibility costs nothing. The same typology change in month six, after the financial model is built and the architect has produced schematic drawings, costs weeks of work. The same change after the application for bygglov or omgevingsvergunning is filed costs months and sometimes the project itself.
This means the question is never "how do I make better decisions later?" The question is always "how do I make better-informed decisions now?" Every constraint surfaced at the first sketch is a constraint that does not surface at month six.
The categories of surprise repeat across projects. Knowing them by name helps explain why each corresponding data layer earns its place in a feasibility platform.
Cadastral surprise. The parcel boundary you assumed is not the parcel boundary that exists in the registry. The buildable area is 12 percent smaller than the back-of-envelope number. Yield drops accordingly. This is among the most common forms of late-stage rework in residential development.
Regulatory surprise. The detaljplan, kommuneplan, or omgevingsplan permits a different category of development than the team assumed. Residential intent meets a use designation that requires a planmonopol process. Years are added.
Geotechnical surprise. The soil under the site is postglacial clay. Foundation costs triple. Building heights compress to keep the project economically viable. Typologies that were on the table are no longer on the table.
Hydrological surprise. The site sits within a 200-year flood projection. New residential setbacks are required. The ground floor program changes. Stormwater infrastructure costs increase. In some cases, the buildable area shrinks again.
Cultural surprise. A fornlämning, a historic structure, or a protected archaeological zone overlaps the parcel. Excavation surveys are required. Construction setbacks are imposed. Sometimes the site cannot be developed at all in the form proposed.
Infrastructure surprise. A high-speed rail line, an airport noise contour, a buried pipeline, or a planned utility corridor crosses the parcel. The buildable envelope shifts. The typology choices narrow.
Demographic surprise. The site is in a market segment that does not absorb the unit mix proposed. Sales velocity assumptions need revision. The project pencils differently than the original underwriting assumed.
Each of these surprises has a corresponding data layer that can surface it at the first sketch. That is the entire argument for deep data integration at the feasibility stage.
One subtle point that often gets missed: not all data is equal even within a category. The difference between authoritative and aggregated data is the difference between defensible decisions and reasonable-looking guesses.
For cadastral data in Sweden, Lantmäteriet is the legal source of truth. For cadastral data in the Netherlands, PDOK Kadaster is. For flood risk in Sweden, MSB is. Aggregator platforms often wrap these sources behind their own APIs, but they are not the authority. When the question becomes contentious in a permit hearing or a board meeting, only the authoritative source carries weight.
This is why feasibility platforms that take their data integration seriously connect directly to the issuing agency rather than through third-party data brokers. The two approaches look similar in product demos. They diverge sharply at the moment a decision needs to be defended.
For more on the specific authoritative sources Hektar integrates, see our inventories for Sweden and the Netherlands.
This is where the data argument and the generative design argument converge. Generative software produces output by exploring a possibility space against a set of constraints. The quality of the constraints determines whether the output is meaningful.
A generative engine that does not know the parcel boundary cannot produce a feasible block. A generative engine that does not know the soil type cannot propose a viable typology. A generative engine that does not know the flood zone will produce scenarios that fail at the first regulatory review.
Add the constraints, and the same engine produces output that survives scrutiny. The building positions respect cadastral geometry. The typology selections respect ground conditions. The block configurations respect flood setbacks, infrastructure corridors, and archaeological zones. The output is no longer plausible-looking; it is defensible.
This is the architecture underlying our Vinnova-funded research on detaljplan compliance intelligence. The research treats data and regulations not as validation steps applied after generation but as constraint structures that shape what the generative engine produces in the first place. The same principle applies across every market we operate in: the deeper the data and regulatory integration, the more meaningful the generative output.
If deep data integration is obviously valuable, you might reasonably ask why every feasibility platform does not already have it. The honest answer is that data integration is hard, expensive, and unglamorous.
Each authoritative source uses its own API, its own authentication scheme, its own update cadence, its own format conventions. WMS layers, OGC API endpoints, GeoJSON exports, custom XML responses. Some require authenticated access. Some require legal agreements. Some change without notice and break consumer integrations.
The work of building and maintaining these integrations does not produce demo-friendly screenshots. It produces resilience. It is invisible until it stops working, at which point its absence becomes the most important thing about the product. Most early-stage software shortcuts this work by relying on third-party data aggregators that obscure the source. The shortcut is visible the moment a decision needs to be defended.
We have chosen the harder path: direct integration with authoritative sources, country by country. The cost is real. The payoff is that our generative output is grounded in data that holds up under scrutiny.
A reasonable question: if more data is better, why not integrate every available layer for every country?
The answer is that data integration has a hidden cost beyond engineering work. Each new layer adds runtime complexity, increases user cognitive load, raises maintenance burden, and creates new failure modes when upstream sources change. Adding layers reflexively makes the product worse, not better.
The right test is whether a layer is decisive often enough in early-stage decisions to justify these costs. A layer that surfaces a constraint affecting one project in five hundred is rarely worth integrating. A layer that surfaces a constraint affecting one project in five is almost always worth integrating. The boundary between these cases is where careful product judgment lives.
For our current Swedish stack, the answer has settled at 13 layers from 6 authorities. For Dutch projects, 18 layers from 3 source families. These numbers will grow over time as we add layers that meet the decisive-often-enough test. They will not grow indefinitely.
If you are evaluating early-stage feasibility software, the most important question to ask is not about the generative algorithm or the visualization quality. It is about the data layer architecture.
Specifically: Which authoritative sources does the platform connect to directly? Which categories of late-stage surprise can it surface at the first sketch? When the data source changes, how quickly does the platform adapt? When you need a layer that is not currently integrated, what is the request process and the realistic timeline?
The answers to these questions reveal more about whether the platform will serve your work than any feature list. Generative output without data depth is decorative. Generative output grounded in authoritative data is the difference between guessing at scale and making decisions you can defend.
The fashionable parts of feasibility software are the generative algorithms and the AI rhetoric. The decisive part is the data layer. Every late-stage surprise has a corresponding data layer that could have surfaced it at the start. Every well-grounded feasibility decision is built on top of constraints sourced from authoritative providers and integrated deeply enough to shape generative output.
This is not exciting work to demo. It is the work that determines whether the product is useful.
For our specific data layer inventories, see the country posts for Sweden and the Netherlands. For more on how regulatory data shapes generative output, see our Vinnova project announcement. For comparisons of how data integration differs across feasibility tools, see the five-tool market overview.
