Advancements in computational architecture coupled with improvements in user experience are making parametric design more accessible to architects with limited coding experience and more applicable to everyday typologies: multifamily housing, office buildings, and neighborhood planning. Several tantalizing generative design tools exist behind proprietary doors, such as that by WeWork. Others are in beta testing, such as Finch, or available on the open marketplace Hypar.
In October 2017, Dallas-based TestFit, Inc. released its eponymous generative design tool to the public, which allowed users to test fit residential unit and parking stall configurations for multifamily housing. The current release enables users to test fit retail developments and master plans, as well as to make manual adjustments to massing, vertical circulation, and unit placement. Last month, the startup announced it secured $2 million in seed funding from Parkway Venture Capital. The now five-person company was co-founded by CEO and architecture graduate Clifton Harness and chief technology officer and computer scientist Ryan Griege in October 2015.
ARCHITECT spoke with Harness to learn more about TestFit, the evolution of architectural design, and the impact of the former on the latter.
ARCHITECT: What need does TestFit meet?
Harness: Right now, 90% of buildings that get drawn don’t get built. We’re trying to draw them a lot faster and get rid of all the wasted opportunity costs in architecture, real estate development, and general contracting. We want to reduce the friction substantially by using generative design.
TestFit is not built on Dynamo or Grasshopper. Why did you choose to go that route?
It is built from the ground up, thankfully. We wanted real-time generated design, and Dynamo and Grasshopper are extremely slow.
About how many algorithms does TestFit currently run?
[Laughs.] Ryan [Griege] says, “All the algorithms.” I don’t know—20 or 30 or something. A lot of them.
After a user enters project or site parameters, how does TestFit decide what solution to present?
The first thing we do is try to conform to every single parameter inputted. We’re at well over 100 parameters—most Grasshopper scripts aren’t even a fraction of that. For example, in solving unit mix, we’re trying to achieve the lowest amount of error, which in and of itself is a very hard problem to solve.
We’re trying to be compliant with vertical circulation, so we have [guidelines] to place stairs [that draw] from the International Building Code. We’re trying to solve the parking ratios. That’s a recursive algorithm in and of itself: If you draw the site plan first and you’re way under parked, then you have to grow the parking garage a little bit, solve it again, and then you go through that process until you hit your metrics.
How do you envision an architect using TestFit, versus a developer using it?
We built a lot of co-creation tools, like our manual mode and our unit configurator, that [give] architects a higher level of detail, more control. Developers are not that picky: They’ll take the first or second iteration of what they’ve done, and that’s good enough for them to get started on the financial feasibility. TestFit is helping developers validate assumptions. It’s trying to help architects craft buildings more quickly.
Does a developer need an architect to conduct initial feasibility or financial studies anymore?
I don’t see the role of the architects disappearing. [TestFit is helping architects] do their job from a data-driven approach as opposed to a subjective trace-paper, slow workflow. One of our earliest adopters, Collegiate Development Group, in St. Louis, has done 300 studies inside TestFit in the last two years, and that’s enabled them to grow significantly because they can kill off deals a lot more quickly. [Looking ahead,] I expect architects will start receiving sites [from developers] that have a much higher likelihood to succeed because they’ve gone through the first iteration in TestFit. If you can’t make it work in TestFit, it’s not going to work.
Is there a risk of users accepting TestFit’s solutions as the be all, end all? Or does TestFit check every possible configuration such that no solution exists outside of what it finds?
Absolutely, there are trillions of solutions that can exist outside of what TestFit generates, and TestFit is not going to generate the best solution. It will generate a solution 1,000 times faster than an architect can generate a solution. Typically, your designs get better over time through iteration. We simply created a co-creation tool to let people iterate more quickly. We have not taken the other stance of “let’s generate a trillion options and allow people to sift through them.”
How did you decide which solution TestFit would initially present? Can a user say, “I like that iteration, but I want to see another one”?
TestFit is deterministic, meaning that it will produce what it will produce given the parameters. We have a couple things that enable people to swipe through different unit layouts. It’s user-generated optioneering. But TestFit is not ever going to produce an “optimal” solution. It’s like “optimal” to who? Optimal to the developer, the city, the tax base, to carbon? We’re trying to satisfy all constraints and present a solution that is as close as possible to what the user has requested, given the parameters.
A user has to input a lot of parameters before running the tool. Will people become too busy in finding the solution that they forget to check whether they’re asking the right question?
Let me try to unpack your question. There is a tremendous value in tinkering with buildings in the feasibility stage. [Let’s say the] user is asking, “What are some possibilities for this 5-over-2 apartment building?” TestFit will generate maybe four or five different options they can look at, but TestFit’s never taking a stance that any one of these options is better than the others. But it does give users the ability to tinker, [and developers have said] that it gave them the ability to do something they’ve never done before.
What will this round of seed funding allow you to do?
Before we got funding, TestFit was a company that had four employees and was paying taxes and made money. We built a customer-funded business. [Now we’re going to be] basically pouring gasoline on the fire to grow a lot more quickly in our offerings. We want to [explore] office, self-storage, retail, and more complicated adjacency studies. I get emails daily asking about hospital design. So, we need more engineering and horsepower to get all this stuff built. We’re hiring; we need C and C++ developers.
Do you anticipate integrating other features, such as building performance or a solar study, into TestFit?
There’s a lot of stuff already available; I love the Ladybug Tools guys and they’ve recently figured out a way for people to plug into their system in a better way. Sustainability is definitely on our minds. But we had to build a sustainable business first. If we get massive adoption of our software, I can guarantee you that we will be [incorporating] total cost of ownership analysis, energy analysis, carbon cost analysis, how far away is the factory from this building, what’s the carbon footprint of shipping? We can get into all that stuff, but we still need to build out the core technology first.
You created TestFit in part because you spent a lot of time laying out plans for spec projects in your early career. Does automating the process take away learning opportunities for emerging architects?
I’m skeptical on whether TestFit would be a great software for students to learn. It’s kind of the same argument with Revit. You need to learn how walls go together and why walls are 4-7/8 inches wide. We’ve been testing TestFit in education with interesting results. I would caution [students, interns, and emerging architects] from relying completely on the algorithmically generated stuff because you don’t understand why it is the way that it is. You still have to take the ARE exam and understand why you need vertical circulation every 250 feet and [other things] to be an architect.
That’s an interesting conundrum in which you value learning what it takes to build a building, yet you design tools that architects will use because they want the fastest way to solve a problem.
Maybe as an intern you learn how to draw a parking lot, but you only need to do it one time before you realize that it sucks. The counting of parking spaces absolutely should be automated—let’s not waste our lives counting parking stalls. I was 24 when I basically sat up at my desk from drawing parking lots and thought, “I don’t want to be doing this for the rest of my life.”
What distinguishes TestFit from other generative design programs?
I’m pretty sure we were the first generative design tool that you could buy and use right out of the box specifically for buildings, back in 2017. We’re a feasibility tool. At the end of the day, you need to solve a business problem that is valuable for a large number of people and I think we’ve proven that by making sales.
About how many clients do you have?
About 100 firms use TestFit in 35 states, in six countries. The pie chart is 45% real estate development firms, 50% architects, and 5% general contractors.
What do you envision as the future role of the architect?
Last year, I visited 100 Fold Studio, a nonprofit architecture firm in Lakeside, Mont. If AmeriCorps is building a small office building in Cambodia, 100 Fold typically is the architect. [They were designing the] windows, so 100 Fold looks at the climate and says, “You don’t just want a hole in the wall because you’re getting blazed by sun all day.” The firm takes this parti of the big office box and says, “We’re going to provide these [light] shelves.” The people there are like, “What is this thing that’s hanging off the side of the building?” 100 Fold says, “Let us build it this one time and if you guys don’t like it, we don’t have to do it ever again.” And then the west façade becomes the coolest façade on the building.
That is the value of an architect looking into a design problem. We’ve got to house billions more people in urban settings over the next 20 years, and the way that we design right now is too slow. Why are we manually dimensioning things in Revit? Why are we making door schedules in Excel and linking that into an AutoCAD file? A lot of automation needs to be done on things that need to be automated. Moving forward, the role of the architect will get way more into detail on logistics for how this building is going to get built—and with off-site manufactured parts, [similar to] what Katerra is doing today.
I get a lot of flak on social media. You can find a lot of critical comments on what we’re doing. Some guy was like, “OK, you keep building your rinky-dink thing while us real architects solve real problems.” Well, we are solving real problems—it’s just not in a way that you imagine a technology company would solve it. What we’re doing is a little bit controversial, and I’m OK with that.
Final question: Who chose the voice-over in the latest intro video for TestFit?
[Laughs] When you’re a customer-funded startup, you don’t have money to hire a firm to explain your video because you want to eat, pay rent, and have good credit. One night, I built out this whole video, watched it, and thought, “We need audio here.” I was at the very end of the creative process so I thought, “What if I do a voice-over that’s a ridiculous, theatrical kind of thing?” It was awful. I put it on YouTube, and we got comments like, “If you want people to take you seriously, you should hire a voice-over guy. This makes it sound like a joke.”
We took that to heart and found a professional voice-over guy who does the Hollywood thing. We were laughing hysterically as he was recording the lines we asked him to record. So we kept it. That’s part of our voice. We’re not taking our marketing too seriously. We’re trying to be real people. We don’t have everything figured out.
This interview has been edited and condensed for clarity.
