AEC Is Too Small a Frame
It's encouraging to see A16Z talking about the AEC sector. Even though at some point in our journey, Giraffe stopped seeing ourselves as an AEC offering.
Why? Because design is too small a part of the urban system. We've struggled to name that system - settling often for 'city making'. The financials show the relative sizes: AEC fees are only 10% of construction costs (by rule of thumb), which are about 30% of asset value (by the same rule of thumb). So even if the AEC software market is 10% of all design fees, it is well less than 1% of asset value. Real estate agents, by contrast, can take 2–3% of asset value as commission.
Thinking about real estate and buildings as an AEC or design problem misses the sheer size of the sector. But it also misses the magic of the sector. The real asset sector — which is created by AEC professionals, but is far larger than them — is only one sector, true. But it is the sector. It's the sector that defines the transportation sector, the housing sector, and massively influences the financial sector. The real asset sector is the one that defines human beings' consumption and production of a new planet in the Anthropocene.
At Giraffe we take this systemic view: this is why our customers are governments, large asset owners, developers and capital managers, and — although to a lesser extent — AEC professionals. In this broad view, the systemic currents that define real assets are so big that the AEC industry has struggled to navigate them. Construction productivity is down or flat and has been for decades. Dispiriting for smart designers. The remainder of this essay will consider AEC professionals — although I think the landscape and classes of problems are roughly the same for developers and policymakers.
There is technical stagnation across the sector. As A16Z say — most buildings you've been in were designed by software built in 1997. (This understates the problem a touch. Most buildings you've been in were designed without software at all — the median age of buildings in the west is more than 40 years.)
Autodesk — the incumbent — is, relatively speaking, a small business. It did less than $5B in revenue in 2025. Hudson Yards, which is a big development sure, but not that big, cost $25B. So did Sydney Metro. So did hundreds of other projects around the world. And many, many thousands of construction projects that cost a total of
What is happening in this enormous sector? Why is there so little software, and so much fragmented human brain labour working away, paid by the hour. What little software these experts use is old, and small, and relatively speaking — crude.
Fee structures and business models, liability and insurances, incentives and innovators' dilemmas have all contributed to the stasis. But, we've always taken the view that the problem is fragmentation. Fragmentation by discipline and by the intensely local nature of real estate.
Fragmentation means no one is very big. Even the biggest players are small. It also means they are separate - with low ability to coordinate.
This has led to a systemic lack of R&D. Google invested about $60B in R&D in 2025 — 12× Autodesk's entire revenue. Meta spent 16× Autodesk's 2025 revenue, just on the Metaverse. (And whilst attending a meeting as a legless egg with a human face in an infinite void has its charms — more efficient, resilient cities need R&D too.)
The consultants, charging by the hour, with firm margin and utilisation mandates, find it very difficult to do R&D. I just read an annual report where a $200M R&D target was touted - now this is admirable, and not a trivial amount of money, but relatively to other sectors it is tiny. By my reckoning that is 12 working hours of Microsoft's R&D.
This lack of R&D meant the industry was stuck in stasis, until the LLMs — which reduced the cost of R&D substantially. I'm not talking about deep scientific R&D (biochemistry, or cold fusion). AEC consultants don't need cold fusion. They mainly do calculations that are very well understood, and then do pictures and PDF them. They are in need of SaaS and the cost of SaaS production has fallen through the floor.
Post the LLM, the SaaS market is fragmenting. You can build small local apps that maybe only work for one organisation in one state. (It is almost like the real estate market.) And, economically, it makes a lot of sense. If an organisation has a
LLMs the scale problem of fragmentation is solved. Against the size of the real asset sector software development is tiny. But the 'separateness' problem fragmentation problem remains.
It is not too difficult to automate any single point problem in AEC. An algorithm that sizes ducts for an asset class can be put together in a few weeks. In a person-year or two that will be extremely robust. It will reference local codes, it will adjust to certain edge conditions, it will consider material sizes and installation difficulties, maybe even logistics constraints. It will be able to adjust itself to different structural systems.
The problem is what do you do with it? You can use it internally and derive a local, and probably temporary, competitive advantage. But to bring it to market is hard. Revit is too crude to plug it into, for all the reasons A16Z said. Rhino is better, but still hypertechnical. You could put it onto the internet and wait for signups.
That is where Giraffe comes in. It is a layer for point solutions to be woven together into something meaningful. Real estate, more than any other sector, is a weaving together of different point solutions.
Look at this example. It's a simple Giraffe polygon driving multiple agents in this demonstrator application. It should open with the Timber Agent active — and you can see some trivial engineering automation. But look at branch3d.com for a real version of this — here it is integrated into Giraffe.
The toy MEP app doesn't do useful work at the moment, but if it was a connection to an endra.ai endpoint (with a potential MEP consultant wraparound to manage the liability and improve the knowledge assembly line), that dramatically accelerates my capital deployment, whilst reducing my risk and fees.
Now, for the first time, capital and government can be drawing in a design package and get AEC services directly via API. This is very rational for them: it is clean, fast, and hopefully cheap. It is also, therefore, rational to invest in R&D to build and provide these services.
Because these services are automation-first, most of the legacy cruft of Revit is technical debt — at best useless, at worst actively slowing you down. Autodesk has distribution into the AEC space, but the actual economic buyer of automated services is the developer, asset owner and the policy maker.
Giraffe is winning these city makers by being an AEC model that can function as a financial model, and can orchestrate the APIs that will redefine the AEC sector.