Interview with Scott Reynolds, Co-Founder of UpCodes
Interview with Scott Reynolds, Co-Founder of UpCodes
Welcome to Construction Physics, a newsletter about the forces shaping the construction industry.
This week’s Construction Physics is an interview with Scott Reynolds. Scott is the co-founder of UpCodes, a startup building tools to make understanding and working with the building code easier. I was interested in Scott’s perspective on how the building code could be improved, as well as what the construction startup landscape is like.
This interview has been edited for clarity.
Construction Startups
Scott: 10 years ago there was so little traction and funding in the space. Even today, we'll go talk to some of the investors and the VCs, you pitch them and nine out of ten times, you're starting from a blank page. They won't know about construction. AEC, they really have no idea what that's all about. What's the typical workflow, who are the users, who are the segments? What does a construction project look like? What does it take to go from RFP and schematic all the way to getting it bid, to the GCs, to getting approvals and occupancy? So that whole ecosystem, you get into that meeting and you have to build the picture from the ground up.
Whereas, a lot of our contemporaries, and we went through Y Combinator, when they're working on say a B2B horizontal app, selling it to developers or something, the VCs know that whole ecosystem. You go in with a very clear context, and they know exactly what you’re talking about. So you can dive right into what you do in this space, but for us, and I think all construction startups, when you're pitching, you have to spend half the time just painting the picture of what this ecosystem actually looks like and how you fit in it. So it's just consistently been a theme for us, as we've gone out to raise money and talk to those investors.
Brian: That's interesting. Something I've noticed, I follow the construction startup scene a little bit, and it seems like a lot of the people that are successful at raising money are people who have kind of one foot in that software world, or had previously successfully raised VC. There's a big modular construction startup that I think is run by some former Amazon folks. Katerra, where I recently worked, was started by former electronics manufacturing folks who were in the venture capital world. It seems like for people that are directly from the construction industry, it's maybe a tougher path.
Scott: I guess I see that in two ways. One you're right, there is a disadvantage, but I think there’s also an advantage to it, just because you get exposed to new problems that software engineers haven't been exposed to, so you can see opportunities to make businesses and products where other people couldn't.
I think the best possible scenario is when you can pair up with a technical person, I think it really helps quite a bit. One of the big success stories was PlanGrid. And they did exactly that, two of them came from a technical software engineering background, and two of them came from the GC side. It was really a good pairing, and I think they did really well. Because they could see the opportunities, but then weigh them against the reality of building software, and the difficulty of actually shipping a product.
And we found the same thing. I'm coming from an architecture background, I did my B. Arch at Syracuse and then was working day to day, and kind of realized there's so many inefficiencies in this workflow. And I was doing architecture, so I wasn't dabbling too much in engineering or construction, but even within architecture, there's just so many inefficiencies. I think I'd come up with six or seven ideas that I would pitch to my brother, who was a software engineer at PlanGrid actually. And he's just, “Yeah, it's interesting, but it's way, way harder than you would ever anticipate”. And we landed on building codes and thought, “Oh, you know, maybe that's feasible”. So we started to put together a working prototype. That's kind of what led us down that road. But without him having been that sounding board to be able to get a reality check on these concepts and ideas, it would have been really difficult to choose an idea.
Building Code Inefficiency
Brian: Can you talk a little bit more about what led you to building codes, and what the vision is, or the disconnect between how it works currently, and what sort of an optimal situation could be.
Scott: Sure. So when I was working as an architect, we had a physical library of code books, and then we had kind of an eclectic mix of PDFs saved to the company server. It fell onto each individual in the office to put together the required code and go find the documents, go find the most up-to-date information, whether that came from the library of codes, whether it came from the company server with all the PDFs, or just going out to government sites or online resources.
It was just such a hodgepodge of patched together information. And that's just assembling the information, but then you have to understand and analyze it, and the difficulty of figuring out what does this language even mean? And how do I apply it to the project?
And I was fortunate. We had code consultants on our projects at KPF at the time. But we were still making mistakes - it's just a completely brute force manual and analog workflow to push through this compliance component. And then you go put your application into the plan review, and the reviewer just goes through and marks up everywhere you're incompliant, where you made errors interpreting the code. So I was just scratching my head. Like, there's gotta be a better way to actually do this research.
That's when I reached out to Garrett, Garrett being my brother and co-founder. And we started to hack together the first baby step, which is just to get this information together in a single database that you can make searchable, and that you can keep up to date. You can keep it in the cloud. So when these amendments and errata come out, you can just ship it to the cloud. At the time, as simple as it sounds, that was still a big step for a lot of people. And it just started gaining traction from there.
But going back to your original question, where do we see this going and what, what do we think it should be? Basically working towards much more of a TurboTax kind of workflow, where it could be a very user-friendly interface. You start with inputs or questions about your project, and then it starts to do these calculations and automate the curation of these code sections and figure out what's actually applicable to your project.
Scott: Let's say I’m in Chicago and building a hospital. It has these occupancies, this many people, this construction type. What do I have to follow? What do I need to follow in schematic and design development, CDs and CA. And then for the GCs, what they need to do during construction, and then even into occupancy. So instead of trudging through physical books, it’s putting all of these codes at your fingertips, and also automating what you want to have at your fingertips. So you don't have to do that manual research yourself.
Brian: It makes a lot of sense. I'm on the structural side, which is much less code burdensome, but even there, you're dealing with dozens of references, and tracing down the relevant code sections, and making sure you interpret them correctly. It's a very labor intensive manual process, and it’s sometimes a roll of the dice with the building official.
Scott: Exactly. Every department interprets it a different way. Even within departments, whatever official you get is going to interpret it a separate way. That's a major problem, because if you have no clue what comments you're going to get back, or how they're going to interpret a certain section, that’s a massive issue. If we can bring transparency and clarity to both sides, and more consistency in how it's interpreted and how it's applied, we can design much more efficiently, and ideally get that permitting time down.
Code Interpretation
Brian: Why is there this variance in how code officials interpret? Is it a question of different departments focusing on different things? Is it just, one day a code official decides to do it this way, or this department has a person who is a real stickler about this thing. Do you have a sense of what the source of that variance is?
Scott: I think it’s probably coming from everything you mentioned, but I think the biggest bucket would be the way it's written. If you look at the code, it only ever gets more complex. I'll make an analogy to software. When you're writing software, you're typically refactoring. You're looking back retroactively at what you had done and revising those things. As you shift something, you have new insights, you want to try it a new way. So you go back and you'll change the old code to mesh with the new code, and maybe even delete some old stuff, maybe rewrite it, but you're constantly trying to pay down what's called tech debt, so that you have a clean code base.
Now, if you compare that to the building code writing process, it's completely different. The building code writing process is just a rubber band ball of appended and globbed on code sections. You can see it, there’s some great examples of code sections where you can see, almost sentence by sentence, where a different committee at a different time added a sentence and added a sentence and added sentence, which makes it incredibly complicated and really difficult to parse. If you give it to five different building officials, and all of them interpret it a different way, you know there's something wrong with the underlying language. So I think there’s a huge amount of work that can be done in terms of cleaning up, refactoring and just making it as crystal clear as possible.
Brian: Yeah. I mean, the code is such an important document for a lot of reasons, but one of the ways is that it's this medium or this filter through which all these different parties communicate. It's the way that the designers communicate with the building officials, but it's also the way they express their intent to the contractors, and the way the architects talk to the engineers. The lack of clarity there really slows down all that interaction. And it can be the source of a lot of problems.
Scott: And if you look at general law, you have all of this case law on paper that is open for the public to view. Lawyers on both sides of an issue, they debate, and the judge sits and tries to figure that out. That's all public. But in construction, you don't have that at all. You're talking to your plans examiner, but that conversation is not public - when you try and clarify a section, no one can reference that conversation you had in the future.
Brian: Yeah. Everybody is doing it independently of each other. You don’t converge on any sort of consensus. It's just like a random walk. That's really interesting.
Using UpCodes
Brian: Is there a standard use case for your software? Like a really easy piece of low-hanging fruit where someone can kind of adopt it and get a big win?
Scott: I think there's two big ones. One is the code calculators, that TurboTax workflow. It takes your project inputs and then it spits out the code sheet. That’s probably the clearest win and that's primarily on the design side. It’s mostly architects. And then secondly, I'd say building inspectors. And for them it's just ease of access. Instead of lugging around all the books in their car, they can just be on their phone and search across all the codes, pull up bookmarks, and do that whole workflow. Those are the two where you see immediate adoption and then immediately getting ROI.
Brian: I knew that building inspectors were a user, but I wasn't quite sure how big a portion they were. Have you been able to talk with building inspectors about how they use the code? Have you learned anything interesting from them?
Scott: There's so many different user segments, they use a mix or a grab bag of different features. For the building inspectors, those code calculators aren't going to be nearly as useful as say the bookmarks and the search engine. And one feature they use is a feature called code compare, where you can compare two different codes to each other, and it shows you what the differences are between them. Either historical editions or even cross jurisdictional, what are the differences between jurisdictions? Getting this archive of different code is pretty popular with them.
Building Code Updates
Brian: On the subject of how the code kind of accumulates provisions over time, you've been working on UpCodes since 2015, is that right?
Scott: Yeah, I think, yeah, either late 2015 or 2016.
Brian: So you've been through a couple code cycles now, through the IBC 2018, and then just now the 2021. Have you seen how provisions get added to the code, and what that process looks like?
Scott: We’re not involved too much with the actual authoring process. But we do receive the end results, and look through it pretty extensively because of the products that we work on. We need to be able to map out the different sections as they change across the country. So if you're looking at handrails, for instance, how does that section on handrails map across the whole country, who changes it, when they do change it? What does it look like when they change it? So we dissect quite a lot in terms of who is making changes and what those changes look like.
I think that sheds a lot of light too, because in some jurisdictions you can see changes were very necessary. If you're building in say Florida, you have to accommodate different weather, different climate, than say the Southwest. Or if you're building in California, you need to take in seismic concerns and the like. Okay, that makes sense.
But then you have another bucket where you just can't wrap your head around it. There is nothing to the climate, to the construction type, to the people, or anything that would justify having a different riser height requirement, which is a thing. I think it's in the Massachusetts residential code. And so you have these bizarre changes to the code, which makes it more difficult for people because that code varies more and it's harder to get across. It'd be nicer if we could kind of converge on a more unified code across the country and then tweak it sparingly where we need to.
Making Code Clearer
Brian: To backtrack a little bit, we were talking about how much the interpretation of code provisions vary. Where do you see the role of tools like UpCodes, or any tool, in being able to kind of make that interpretation clear for everybody, for code officials, architects, and engineers. What kind of potential do you see there?
Scott: I think there's a ton of work to be done there. One of the recent things we released was code diagrams, where we unpack the code section visually, so we give a diagram and an illustration of what it means. Whether it's abstract and a high level diagram, or it's a detail, or an example of an assembly or something like that. And then a plain English overview of what does this section actually mean, and how do you approach this? That's authored by both people internally, and experts in the field.
It's trying to kind of democratize some of that knowledge. If you're an expert on say stucco detailing, it's really a shame that that knowledge and years of experience can't be shared with more people. So what we do is, we bring them on the payroll, pay them whether as a contractor or bringing them in-house, and then try to get a download of those interpretations. Same with building inspectors and plans examiners, but trying to bring people together and just write it in plain English and connect all these different sections together. Just bring the experts to the table and get them to unpack it and diagram it and discuss it, and then share that on the website.
Brian: It's kind of an interesting situation, but a huge amount of how the code is interpreted and how you need to build something is essentially socially constructed. It's either up to what the building official decides, or in things like engineering, you're required to follow the standard of care, which means you need to do what a reasonable engineer would do. Which, obviously has issues, but the upside is that if you can get enough people to agree on an interpretation, then that becomes really a powerful tool for getting everybody on board.
Scott: For sure. And there are forums online that start to get at that, but it's difficult, because you don't know who's writing on the topics, you don't know if they actually know what they're talking about or not. We've dabbled with that idea - “Do we want to crowdsource some of this?”. It's a little tough because you can imagine that being a little bit misleading. So there's just a little bit of moderation that might be required there. And unfortunately we haven't really taken a deeper stab into it.
Brian: Yeah. You need to get everybody to upload their architect’s stamp, engineer's stamp. Have that next to any piece of advice they give.
Scott: Exactly. I don't know. It's interesting to think through the incentives, maybe they do it because they get their name out there. I do like the idea of compensating people for doing that, or creating incentives. Just another area to explore in the future.
How Fast the Building Code Changes
Brian: Talking a little bit more about code provisions and how they change, there's pluses and minuses to a code that changes a lot. If it stays the same, maybe you have bad provisions that don't get updated, or it's not taking into account the latest and greatest information. But on the flip side, if it doesn’t change everybody knows how to do any given type of construction. Do you think our code changes too fast or too slow? Or do you have a sense of how fast it changes versus maybe what's optimal?
Scott: Almost a hundred percent of the time from our users, whether it's the building departments, planning departments, architects, engineers, they say it changes too fast. Actually, I shouldn't say changes too fast, but a lot of people don't like the forced three-year revision cycle. I think it just doesn't give enough time for the building departments to get everything together. And it seems like not enough actually changes. A lot of people kind of want to see six year adoptions and of course, a particular jurisdiction can choose which versions to adopt. When we see people adopting, it actually tends to be in that six year range.
Brian: Yeah. A lot of jurisdictions will skip the new edition, either because they just updated or the new provisions are just really burdensome. And so they deliberately choose not to adopt them. I'm thinking particularly of the 2020 energy code.
Scott: I think that one actually changes a little bit faster because of the new construction methodologies and new technology that's available, it moves a little bit faster than other segments. I actually think the energy code might be justified in changing a lot, but it doesn't mean everyone should update every single publication.
Codes and Trust
Brian: Something that I wanted to talk a little bit about is the role that trust plays in how a lot of this code gets interpreted. Because it's impossible for every code official to thoroughly review every set of plans or check every calculation. You know, it's impossible for an engineer to verify that every model that the code has is correct. So a lot of this is based on trust, either trust in the design professional or trust that some standards organization knows what it's doing. And a lot of the kinds of issues that face construction projects are where that trust breaks down, where the contractor wants to do something and the designer maybe isn't sure if it's the right way to go.
Do you have any thoughts on the role that the building code can play in kind of making that easier, and making maybe less of a burden of trust being on one particular party?
Scott: What comes to mind, is it would come down to both the building code, but also liability and how we structure documents. I think a lot of the time, whoever's shouldering the liability is the person most concerned with the code interpretation. If it's a contractor implementing something, or if it’s the GC, or if they're trying to pin something back to the architect, who holds that liability at the end of the day? I think that is gonna factor a lot into those disputes
And then another fascinating development, some jurisdictions in I think Texas, in New York City, do self certifications. It's basically saying “Okay, I'm comfortable enough with my knowledge and application of the code that I'm going to sign it with my seal or stamp, and I'm going to skip plan review”. I’m not sure if it’s a good idea or a bad idea. Certainly it makes projects move quicker - you're exchanging speed of the project for increased liability on the architect, or whoever put their stamp on it.
If we're doing this in a very old school system, I'd be a little bit nervous because there's just so many error points and opportunities to make a mistake. But if we can create the guardrails that make it increasingly difficult to make mistakes, whatever those might look like, then I think the self-certification totally makes sense because then the risk is diminished quite a bit.
Brian: Yeah. The more interpretable you make your code, the more feasible, something like that becomes.
Scott: Exactly. Because if the underlying code is crystal clear how to interpret it, then there's so much less danger or risk in doing it yourself.
Software
Brian: Jumping back a little bit, you guys are a software company, working on the building code. Do you see any potential in making the building code a little bit more, I guess, programmable and make it so it can interact with pieces of software a little bit easier? Whenever I have to make a new spreadsheet and reimplement the same code provisions, I always wonder how many times some given code provision has been reimplemented in some piece of software, and is there a way to make so we don't have to duplicate that work over and over again.
Scott: It's a super interesting topic. We actually spent a lot of time working on that, and we use it a lot today. It’s only in use internally, but I'll share as much as I can. In part of the products and the features we have today in this TurboTax kind of workflow, you put in information about your building, you'll get calculations and a code sheet spits out on the other end. But what it also spits out is a customized code book.
It basically takes the whole building code and then starts to treat it more dynamically. We'll start to emphasize certain sections and then deemphasize sections by collapsing or removing sections. Really trying to treat that as a living document based on your inputs.
So for say a high rise residential in Massachusetts, one third, two thirds of that code book will not apply to you. So we can parse the code book into parameters, and the software starts to understand on its own what's applicable and what's not. Once it has a little bit of understanding of what do the sections actually do and what do they apply to, then for any combination of inputs it can give you a completely different code book on the other end.
ICC Dispute
Brian: You've been involved in a situation with the ICC, what can you tell me about that?
Scott: So when we were starting out, we did a bunch of research and found the building code is not copyrighted. We looked at case law, and it seemed clear to us that in terms of the ICC codes in particular, they weren't copyrightable. The ICC was formed from three different organizations, two of which had litigated this exact same issue, but they litigated it and lost both times. So we're like, “Well, that seems pretty clear, we're good to go”. And wee started the company and then lo and behold, we got slapped with this lawsuit.
In effect, they're saying “Hey, despite the fact that the code was written by volunteers and government officials in these committees, we convene those committees. We bring those people together and therefore we have copyright, we're the exclusive distributors, and we can sell the books”. And they do sell books. In the US they sell that to the tune of hundreds of millions of dollars a year selling these physical books. What we've come to realize over time is that they've successfully created a stranglehold on this industry.
Scott: Probably five or six, either individuals or companies have reached out saying “Hey, how do you, how do you guys do what you do? Cause we tried to do something either, you know, exactly what you're doing or something similar, and we had a bunch of lawyers knocking at our door, giving us threats and saying, we couldn't do that”. This is before the lawsuit went public and all that stuff. And what it turned out happened is that they've successfully stifled anything from happening in this area of industry.
So when we're talking about the lack of construction productivity over 50 years, a portion of that, the compliance portion, has been artificially suppressed by a lot of this legal action and legal intimidation by these companies. So that was super frustrating.
They brought the lawsuit against us, all of the case law pointed in the direction that we were in the clear, but in the American legal system, you have to pay your legal bills and go through that process. So we've been embroiled with them for almost two, or maybe even over three years now.
Brian: And you recently had some sort of court victory?
Scott: Yeah. A couple of months ago, near the end of 2020 our judge gave a summary judgment. And in very clear text, in multiple ways, it said that you cannot copyright the law. The I-codes, when they're adopted, go into public domain, and everything is in the clear and you guys are good to go. So it was a huge victory for us. Not just for this lawsuit, but then also just ensuring that this kind of existential threat that was looming over our heads is nullified, that they can’t continue to throw lawsuits at us. When it comes down to the fundamental issue, can you copyright the law, can you copyright building codes? They pretty decisively said you can't.
Brian: That's obviously great news for you guys and what you're trying to do.
Scott: Yeah, for sure. And hopefully it's not just good news for us, but everyone else. Hopefully all these people that we talked to in the past, or other people, will have that freedom to go out and create interesting tools, because at the end of the day if architects, engineers and GCs have more products and more software and more tools at their disposal, the whole ecosystem will benefit. So hopefully we see a lot of cool innovations and startups in the future.
Brian: I think a lot of people would be surprised to the extent that billing codes are essentially authored by private organizations, that in a lot of ways don't really have competition. The ICC is kind of the only game in town, and basically every state adopts some version of their codes. Maybe they modify it a little bit, but it's essentially some version of the International Building Code.
Scott: Yeah. And just a small nitpick there. They actually don't author it. They convene the committees that author it, but it's volunteers. So professionals and government officials come together and then they contribute their time for free to actually author those codes. So ICC organizes and convenes them, and then puts it into a book and then sells it back to those very same people that authored it.
Brian: So they’re sort of like the Elsevier of the construction world.
Scott: Precisely. It's like people donating their papers and then having to pay to access it or access to their colleagues work. That's a perfect example.
Future of the Building Code
Brian: I’ll confess that I'm quite biased. I'm a big fan of UpCodes. I use it frequently even as a structural engineer, which, there’s less of a code burden on our work, compared to disciplines like architecture or MEP. It's extremely useful. If you're working with a lot of different states, a lot of different versions of the code, it's a really useful tool.
Scott: Awesome. Good to hear.
Brian: So my last question here, and we kind of touched on a lot of this stuff, but I'll finish up with it. What's kind of your optimistic future of the building code, and how does UpCodes fit into it?
Scott: Basically, it's no matter who you are or how well versed you are in the code, It won't be intimidating, and is completely accessible. So not only can you get it for free, but you'll have tools where you can just put in inputs, you can go through a nice user interface, a nice GUI, and put in some inputs, and it just spits out what you need to follow in plain English. So anyone can do it. It's not a hurdle for individuals or professionals, whether you’re an intern, a mid-level project manager, or a principal, anyone can do it. That's kind of the vision and that's what we're working towards.