Interview with Anthony Hauck, cofounder of Hypar

Anthony Hauck is cofounder and COO of Hypar, a generative design software platform for the AEC industry.

Brian:

Can you talk a little bit about your background, and why you decided to start Hypar?

Anthony:

Sure. So I started out in architecture, and around about 1997 or so swung into more of the technology side. I worked for 12 years at a company called Einhorn Yaffee Precott, as their IT director, and I was a principal there. I joined Autodesk in 2007 on the Revit team, and within about a year and a half, I was leading product management on Revit, and then eventually about 25 other products. I started Revit LT, Revit Server. And I forget what it's called now, but it started out life as Collaboration for Revit. It’s now called BIM 360 Collaboration, or something.

In 2018, I talked Autodesk into starting up something called the AEC generative design group. And I'll give a little shout out to Jen Carlisle over at Flux at the time who gave a presentation about the so-called building seed and talked about a building that would be generated from requirements and its environmental constraints.

Anthony:

It was pretty clear that if someone managed to pull that off, and then connect directly to a factory that was producing the building components, there really wasn't much of a need for drawing sets. And of course that's what AutoCAD and Revit have always been kind of focused on, producing some kind of physical documentation. So, when I left Autodesk, it was a couple of months after Ian Keough (who invented Dynamo), we had both worked on something called Project Fractal, which was kind of the first AEC generative design product that was being spun up inside Autodesk, which eventually became Project Refinery.

After I left Autodesk I got back in touch with Ian and asked him, “so what are you doing?” And, he said, “well, I'm thinking about a lot of things.” And I said, “well, I'm gonna do generative design.” And he said, “that's one of the things I was thinking about.” So what ended up happening is, Ian was my first post-Autodesk consulting client. And then I consulted for about five months, until we decided to make each other honest partners.

Anthony:

But the reason that we wanted to start a company was that from our time at Autodesk, we could just see the same thing happening over and over again. We both literally had the experience of showing up to visit a firm in the morning and being showed some technological project they were working on that was differentiating and game changing, and was really gonna separate the firm from the pack, and then going and having lunch and then going to another firm, literally down the street and seeing the same thing and being told the same thing about it.

There was all this repetitive investment going on, around the industry, the same issues that were facing all the same firms at the same time, and no one was benefiting from investments in technology that could then be shared, which is what's happened in the software industry for the past 30 years. So you get things like Facebook creating the React framework,  and then they share it and now everybody can make React applications. So we started to think what if you took that kind of software sensibility, where you could protect people's IP, but allow them to share their work and have it work with everything else that other people were working on. Like most software does by adhering to certain public standards. Web standards are the obvious one, we can all see in the last 30 years how quickly the web has added capabilities because everybody's building on each other's success.

Brian:

Yeah. It’s a super common criticism in the construction world, which is just, everything keeps getting redone from scratch over and over again, it's interesting that that was making its way into the software as well. 

Can you give a brief overview of what Hypar is and what it does, and what sort of things might be possible with it that maybe wouldn't be possible with other more common design software, like Revit or CAD?

Anthony:

So probably the easiest way to understand what we do is to look at other cloud services like AWS, Azure, Google Cloud, etc. All those services are providing a base set of technologies that people can mix and match, to become some other application. So AWS started internally as something to support buying stuff from Amazon, and everyone quickly realized that that in itself was a business, that many people might want to make sites that did things like that. So one way to think about what we're doing is in AWS for AEC. 

We think there are a bunch of things that everybody wants to do when they put up a building, like have a structural system, route pipes, put up a facade, etc, and that those things don't necessarily need to be reinvented every time - there are standard ways of putting these things together, either from regulatory frameworks or best practices, and that people shouldn't have to carry all that around necessarily in their heads or look it up every time. So what we made is a cloud platform where not only are those services available to folks, but people can write their own services to put on the platform and concentrate more on the core expertise they're trying to deliver. 

One of the things we noticed when we started looking into the history of generative design, which goes back to about 1963 or so, and looking at all the huge numbers of papers that had been written, this really remarkable intellectual history, really great ideas, and none of it, absolutely none of it available today.

Screenshot of Hypar

Anthony:

And we thought, what can we do to knock down every single barrier that's preventing this from actually changing the building industry? Because right now, very little of that stuff has been directly translated into commercial technology. So, what we're trying to do is provide all the technological building blocks for people to deliver new AEC software, which will improve the quality and speed of decisions in the building industry. 

And it’s sort of analogous to when Paul Graham's original company was going around, trying to support eCommerce in 1995. And they said “Hey, we have this great platform for eCommerce and you should use it to build an eCommerce site”. And their customers said “Wow, that sounds great. What's eCommerce?” They had to kind of alter their pitch to say “We have this platform. Would you like us to use it to build something for you?” That's a lot of what we do right now. Most of the interest that we get is from building product manufacturers, design builders, and general contractors, because they all have lots of procedures that they use humans to carry out, but that they recognize should be automated, things like pipe routing and material optimization.

Anthony:

Our kind of public product is a space planning application, but all of these things are reducible to a combination of common practices and human intervention. One of the things that we believe is so far unique in the industry is that in Hypar, you can combine those two things together. So you can do things like generate a building system, move some stuff around by hand where you want it. And then if the building changes, we preserve all those edits that a human has put in. So what we're looking at is a system that allows people to mesh their expertise with the analytical capabilities of software.

Brian:

So when a building goes together, a lot of it is like very mechanical decisions. You're just doing what the code tells you to in this given situation or you're doing your standard procedure, or using your standard detail. And Hypar is kind of a way to turn those sort of standard ways of doing things into a series of computer functions that you can then stitch together and generate your building almost algorithmically, with human intervention at sort of the key points where it requires some sort of judgment. Is that a good way of characterizing it?

Anthony:

That's exactly right. 

One of the things that we had to do at the beginning was, if people are going to just sort of add things into the system, we wanted to make sure that everything could talk to one another. So we created this library, we call Elements that represents building objects digitally. And we open sourced it and  made it extensible. So- to us to add things to the library for their use. The idea is to have some kind of Lingua Franca that everybody could use, so that your structure talks to my duct work, talks to that sprinkler system, etc. Essentially, the way Hypar conceives of a building is as a set of interacting systems that are representing the building's functions. And they can be as simple as a core and shell, or as elaborate as fully routed mechanical systems.

Brian:

So when thinking about a building as a series of functions, how does that kind of influence where the rubber meets the road in terms of how the building actually gets built on site? Do you still end up with like a series of construction documents at the end of the day? How do you think about what that looks like?

Anthony:

Yeah, we're in this kind of tough, extended transition period where we've got this intersection with the regulatory environment, which has nowhere near caught up with technological innovations that are available. And so ultimately out of all these processes, you still end up with a set of construction documents, unless you're controlling the process front to back as a design builder, for example. And the reason all these piles of paper exist is essentially litigational defense, and because of how these contracts are structured.

Most construction is things like strip malls, garden apartments, all these building types that are almost cookie cutter. That sort of bespoke, high design building is a really a tiny minority of what gets built, right? And those sorts of standard buildings should be more and more verticalized. They often are in a lot of places around the world, and even in the US, there's a lot of modular factories now springing up.

Anthony:

And so there's this possibility of working in a virtual environment, making all the important decisions, and that feeding directly down into a factory that produces everything you need to put that building up. We think a lot more of that is going to happen, and that these innovative systems of speedy construction are going to become more and more common, and they need to be integrated with design decisions around a project.

The challenge is meshing those standard methods with your unique project circumstances. How do those come together in an efficient way that leads to a humane outcome for everybody who's going to experience that building. We think that things like Hypar provide the ability to do that. 

Anthony:

It also makes it less influenced by the experience of the individual professional. We literally have customers who say “We have a person, he knows everything about this thing that we do, and he's been in the business for 30 years and he's gonna retire, and we need you to pull everything that he knows out of his head and put it in something we can keep and then hand over to our other project managers.” So they're at least as good as this guy was when he was still working. That's the kind of thing that's going on right now with some of the demographic shifts in the industry.

In my working life, I've been through three worldwide downturns. And every time that economic downturn hits, people leave AEC because they get burned by the cyclic nature of it, and they don't come back. And so now we've got these three floating demographic holes moving through the industry. There's a reason why construction is looking very, very closely at robotics, and investing in it, because they can't find the people. And the intellectual capital of the folks sitting in offices, making the big decisions, that's getting a little thin on the ground too. So the question is, what do you do? You can provide as many incentives as you can muster to try to get more people in the industry, but it doesn't seem to be working.

We have another customer who came to us and said “We see this huge business opportunity in Europe with these highly designed and engineered systems that we sell. And then we look at our engineers, and we look at a 30% projected year on growth of our sector, and well, I don't think we can grow our engineering staff 30% year on year.” So they can either leave money on the table, or they can try to automate something and raise the productivity of their engineers so that they can keep that opportunity in house. We just see an opportunity where the aspects of decision making that are amenable to digitization, should be digitized, and we're doing everything we can to make that possible.

Brian:

Talking a little bit more about generative design, I’m interested in what you think the opportunities for generative design are. Is it just finding little optimizations that maybe would be too time consuming or difficult for humans to do? Is it more about new ideas, things that people wouldn't be able to find without some new tooling to explore it? Is it some other thing that I haven't thought of? What are your thoughts on that?

Anthony:

When I think about generative design, I think about an exploration toward an optimal solution in context. Meaning that the thing that automation never captures is a value system - no software is ever gonna fully capture what all the people involved in that project want. So for example, if someone says, I want to build a clinic, there's probably some deeper reason there. Maybe there's a high instance of a particular type of cancer in this area, so we're gonna attack that. And so the building is just an instrument for an aim.

And so the things that I'm hoping generative design starts capturing is what best serves the aim you want. So it's less about form finding and more about solution finding. So although we don't do anything like this yet, it seems like a tractable problem to say, given enough information, what is the most effective response to the scenario I just outlined? Is it one big hospital with centralized care, or is it many little clinics distributed across a wide area, because it happens to be rural and it’s hard for people to get to a big central hospital. So those are the kind of solutions that I would hope would grow out of a platform like Hypar that lets people actually be more effective in the decisions they make.

Brian:

So you kind of see it as being able to do a really broad exploration of a solution space for a particular problem, way beyond what people might have considered if they didn't have the tools to do it. If you want to see what the price is of 10 clinics versus one big hospital, that's a huge ask to do it by hand. Nobody is gonna do it. They're gonna use some sort of intuition, or it's gonna be the result of some other messy process. But if you can just really look at a broad swath of the solution space all at once, that kind of enables new things, new opportunities that you wouldn't have had previously.

Anthony:

Counterintuitive solutions, right.

Brian:

Do you have any ideas on how to extend your system into the construction process or are you kind of more focused on keeping it on the design side?

Anthony:

No, we're deep in construction, and the reason that's occurred, which we didn't understand when we started the company, is that the people in the field, whether they're manufacturers or contractors, come up with best, most efficient practices, because they're working against the fee typically. So the more efficient they can get, the more fee they keep. The kind of epitome of this process was when after the last big LA earthquake, when Route 10 collapsed, the incentive structure as I understood it was a million dollars a day bonus for every day it opens up early and a million dollars penalty for every day it opens late. And that highway went up so fast, and has been up to this day without problems.

Brian:

We had a similar thing in Atlanta where there was a fire under Route 85, and it basically collapsed. And that thing went up very quickly, because that's the main artery of the entire city.

Anthony:

Yeah. Once you've got those things in place, everything is aligned to try to come up with more efficient solutions. Those efficient solutions are just riding around in the heads of key people in the company. And, turning those into automated procedures is what ensures that that level of care actually gets to every project.

We've just done a project for a large construction company around material optimization on site. So we built something for them so that they can just drop a project in and get out like, okay, here's your quantities, here's your optimal material sequencing. So we actually found that in manufacturing and construction, there was a much higher appetite for what we’re offering.

Anthony:

On the design side, in some ways it’s still more of a challenge. Most often design firms are still looking at what they deliver as high priced time for money, instead of delivering value. And so when you go and tell them “I have a time saving device”, they're like, “Hmm, not really sure you get what we do.” But I think there’s starting to be a realization in the design industry that an enormous amount of value is being delivered at a very low return. In one very large worldwide firm, I talked to their head of interiors and she said “I have someone on my staff who has 30 years experience in space planning. She can spend an hour with a client and save them 10 million in leasing costs over three years, by showing them how to more efficiently use the space they have. And when she's done, I get a thousand dollars.”

Brian:

One thing I want to ask about, especially because you spent so much time at Autodesk and working on Revit, is your thoughts on Revit and BIM, and the idea of a building as a structured database of information, and how that relates to what you’re trying to do.

Anthony:

So with Revit, what people asked for, and what they got, was something that would produce a coordinated set of construction documents very well. I remember when the  industry shifted over from hand drawing to CAD, and yes, I'm that old, there was this two, three year window where all of a sudden we were all making money hand over fist, cause it was so much faster to get these drawings out the door.

And then the owners figured it out and then the sort of race to the bottom with fees began. And the same thing happened with Revit - people who were good at it early on could kick out insanely profitable projects, it was nuts. So when you're talking about coordinated construction documents, it's brilliant, and there will always be a place for that, because it remains important to the industry.

As far as turning that into a comprehensive database to govern all things digitally about a building, or the idea of a digital twin, I remain skeptical about it. I know there's a lot of pixels being spilled on what a great idea this is, but, I think the important thing about any model to always keep in mind is that what you want to use the model for is very, very critical. There was this, frankly, fantasy that I shared at the time that there was gonna be this design model and it would get elaborated into a construction model, which would elaborate into a fabrication model. And it would be just like this one gigantic model to do everything and it never happened. What ended up happening was you ended up with a constellation of models, around a project, all for particular constituencies. So I don't think that's necessarily a bad thing because they're being built for different purposes, under different sets of financial incentives, etc. The one place where you'll see some sort of consistent model that's designed for a few different purposes is typically in design build where somebody controls the whole process.

Anthony:

Revit's very good at making construction documents, but fundamentally it's never been a design decision tool. It's always been an environment for clearly and consistently documenting decisions that you made by some other means. Now with some of the things they've done with generative design for Revit, that starts to kind of poke at that idea a bit. But trying to both carry along the baggage of this thing that is designed to produce coordinated construction documents while trying to make it do something which frankly it was never designed to do, that's an uphill climb, especially when you have a highly devoted, very large base of users who can't be disrupted. It's one of the reasons we work with Revit - things from Hypar can go into Revit, things from Revit can go into Hypar, because we're, we're not here to dislodge Revit, because it does a lot of things really well. We're here to augment all those decision processes that finally land in Revit for documentation.

Brian:

Lately it seems like there’s a lot of enthusiasm for no-code tools, which sort of enable you to make programs without having to be a programmer. And Hypar seems interesting from that perspective, because in some ways it is a very no-code tool. You can get a lot done with it just by importing Excel files or just using dropdown menus, stuff like that. But of course it also is a very powerful API and you can program it directly. And then it has stuff kind of in between, with things like linking to Grasshopper. So I'm curious as to your thoughts on the value of no-code solutions for things and what your thinking around that is.

Anthony:

This is kind of a perennial discussion inside Hypar, on how far you can take these kinds of visual programming or no-code environments. Because culturally we're very community oriented and we want more and more people to be able to do powerful things. But on the flip side, there's a reason that you don't really see commercial applications written in visual programming languages. You see ad hoc programs for particular purposes on projects that people do, and they might use it on more than one project. But a commercial piece of software that's made up out of wires and nodes, it's not really out there.

And that's not to disparage Grasshopper or Dynamo or anything like that. These are very valuable tools. The point is that it is hard to do powerful things with simple interactions. I mean, I would love the answer to be, yes, it is absolutely possible to make a no code environment that satisfies what people need for buildings, along with some human intervention to make it all work. We hope that the library on Hypar will become so extensive that only people with outlier needs are gonna need some custom extras to do what they want, but the jury's still out.

Whether we can get it all the way to the point where there's so much on the platform, that people can just go and grab their structure functions from here, their wall type functions from there, and boom, they have a building, that remains to be seen.

Anthony:

I think it's much more likely to happen in a modular environment or a standardized building environment. So for example, let’s say some big box retailer wants to automate their process. They generally have procedures for everything. I know of a project years ago that did some substantial automation around planning out Pizza Huts, because they have binders and binders of procedures for how a Pizza Hut goes together. I think in those kinds of confined problem spaces, there’s a lot more possibility for no-code solutions. 

But if you're gonna use no-code to build the next museum in Paris, I expect that's not the case. Maybe, we'll see. Maybe you can get enough in the no-code environment that the manual intervention will get you the rest. That's why we've spent a big investment on doing that to let the humans kind of bridge the gap.

Brian:

One thing that kind of comes to mind when you talk about the combination of the algorithm and the sort of human intervention is the idea of a centaur in chess, where you can get a pretty good performance from the combination of a really powerful chess engine and then an expert who can kind of review the decisions that the chess engine makes and use that to inform the move that they choose.

Switching topics, construction software licensing is kind of famously very restrictive. It's a long history of needing to get a specific dongle to get your software to work, and just very restrictive licensing in general. With Hypar in some ways you've kind of gone the other way, where you've made big portions of it open source and freely available. And obviously in some ways that’s a function of the sort of business you're in and the problem you're trying to solve, where being more open benefits you to some extent. So I'm just curious as to kind of your thoughts about that.

Anthony:

Early on in Hypar, Ian and I had a sort of ongoing discussion week on week about this thing we're building, and whether it should be entirely open source. And what we eventually decided on is that we made an open standard, and a lot of the code we write that runs on the platform is open, but the platform itself is not. And it wasn’t about a proprietary use of the tech, it was because we realized that if we open source the platform, everyone would grab it, put it on their servers, inside their private data centers, and no one would ever see anything that got put on that. Which was directly contrary to the philosophy we're trying to bring, which is about sharing your expertise, and building mechanisms to allow you to make money doing that.

The same way you do on projects right now, people pay you for your expertise. Now with Hypar, people pay you for your automated expertise. So we wanted to provide all the tools to allow people to do that. Ultimately we want to support a robust ecosystem of both free sharing and sharing things for money, because it's definitely helped the software industry grow beyond all reckoning in the last 20 years.

Anthony:

So we said “well, why don't we keep the platform proprietary so that there is a central exchange.” The things you make on Hypar, you don’t have to share, but it’s literally a matter of checking a box. It's up to you whether you want to share the code publicly. The mostly unspoken secret of any open source project is that there's a small core of people who actually keep it going. And then there's the occasional contribution from other folks that go in there that need something special, but there's always that core group.

We know of a graphics project where someone wrote it three times. And if you read the code, on the third time, he decided to open source it. Because he knows everything about this problem, and he could just write out the answer, and he was sick of writing that answer again and again. So he wrote it and open sourced it, so whatever job he took, it would be available to him. But everybody was happy to pay him to write it again because he knew what he was doing. So we think there’s an opportunity to increase the leverage of these experts, by creating a platform where they can share their expertise.

Brian:

Sure. That’s interesting, the idea that you could design a building by leveraging a huge marketplace of individual building functions. Like, “I need to lay out this particular kind of medical office. So let's see if somebody has written a function for that. Oh great, they have. Oh, I need some system for how to design my layout of ICF walls. I've never done a project like this, but I'll bet somebody else has, let's go pull it out. Oh, and it's written by a PE, and here's their credentials”, and stuff like that. You can imagine a ton of cool possibilities with that.

In that same vein, it often seems like building design software is pretty uncompetitive. Like with Revit, Revit has something like 80% market share among architects, and you could make the argument that AutoCAD before that was similar, though I think AutoCAD ended up having perhaps more competitors. And if you compare that to something like mechanical design, where you can rattle off like five or six different softwares that are all kind of competing against each other. How do you think about that with regards to Hypar, and how the future might look?

Anthony:

We hope that we're providing an environment where those kinds of things can play out to the profit of the industry. When I've advised on what AEC is like from a business or investment perspective with regard to software, I kind of use a Cold War analogy. There was this kind of land grab, and a couple of big companies got their constituencies, and there's very little leakage along the edges, because switching costs are very high. And they're basically dependent on the growth of adoption, and the growth of the building industry itself to keep revenue growing.

We would hope that we make those kinds of borders a lot more porous. Part of the demilitarized zone between all these different constituencies is the file format issue. Autodesk is, of course, rather protective of its file formats. And to be clear even if Autodesk open sourced the Revit file format, you would have a pile of numbers and you wouldn’t know what to do with them.

What we'd like to do is provide a more frictionless marketplace. Because everything is based on this data protocol that we invented and shared, people will be able to enter into that marketplace very easily and provide a solution which has a low switching cost. So we're gonna see how it plays out, but what we hope it leads to is this ability for all that stuff I talked about from 1963 on, getting quickly into the market and having its day in the sun against all the other things that are having their day in the sun.

There is a little bit of a model around this, around when AutoCAD put out an API. so you could make your own first class DLLs that AutoCAD would treat as part of its software. And in the first two years, oh my God there, the stuff on the market was terrible. Even some of the stuff that came from auto Autodesk wasn't complete, and there's about two years of the market kind of sorting that out.

Anthony:

And people that couldn't improve their stuff to the standard of care dropped out, and the good stuff stuck around. I think the same thing kind of happened around the Revit API. There's a lot of stuff that shows up, some of it doesn't survive because maybe it's not very good or people don't have the resources to make it very good. So we're hoping that we're providing an environment where a lot of this stuff can happen at high speed. And so advantages can be quickly gained and things that aren't working very well will, either improve or quickly disappear because no one's using them.

Brian:

Cool, yeah. Well, we’ve gone well over time. To kinda wrap up, what is your vision for building design and construction more broadly, where would you like to see it go?

Anthony:

That the humans are focusing on the hard and unique problems, and that the machines are taking care of the easy routine problems.

The downside, if people are interested in what the flip side of that is, a book by Nicholas Carr called The Glass Cage is a very interesting take on what happens when you let tech do too much, and necessary expertise erodes out of your professional class because of it. But where I hope the building industry goes is that this meshing of automated capabilities and professional judgment, that just makes better buildings for everybody. Because we need a lot of them. We need them fast. And the alternative of watching the built environment, because experts are spread thinner and thinner over all the necessary buildings that need to be built, is a kind of constant degradation of the built environment. That's not the future I want to see. I want to make sure that all the equipment is out there that lets us scale what we know about buildings to every building that needs to be built.

---

These posts will always remain free, but if you find this work valuable, I encourage you to become a paid subscriber. As a paid subscriber, you’ll help support this work and also gain access to a members-only slack channel.

Construction Physics is produced in partnership with the Institute for Progress, a Washington, DC-based think tank. You can learn more about their work by visiting their website.

You can also contact me on Twitter, LinkedIn, or by email: briancpotter@gmail.com