123: ‘Bringing AI to the Building Code’, with Scott Reynolds

123: ‘Bringing AI to the Building Code’, with Scott Reynolds

===

[00:00:00] Welcome to the TRXL podcast. I'm Evan Troxel. This is the podcast where I have a conversation with guests from the architectural community and beyond to talk about the co-evolution of architecture and technology. A little bit of housekeeping up front here. A quick reminder that you can support the TRXL podcast directly through membership member perks include an ad-free version of the podcast with your own private feed. 

Ad-free full show notes with links and guest bios, right in your podcast app and ad- free TRXL AEC tech newsletters in your inbox. Each time one is sent out. 

Go to TRXL.co... that's, TRXL.CO. And click on one of the subscribe buttons to directly support what I'm doing here. Just know that I am grateful, no matter how you choose to support the show either by listening to the sponsored episodes or through direct support. I really appreciate you for listening. 

All right. In this [00:01:00] episode, I welcome Scott Reynolds, back to the podcast. Scott is a co-founder and CEO of UpCodes. He comes from a background in architecture, having worked for several years in Hong Kong and New York city at firms, including both Kohn Peterson Fox and Hassell. Being a Y Combinator alumni, he has leveraged both industry and startup experience to launch and scale UpCodes. 

In this episode, we discuss upcode latest product: copilot. Copilot leverages AI to make the building code more accessible. And I have to say. A much better way to interpret and parse the code. I had the opportunity to take it for a test drive myself. And I have to say, I think this is a game changer. 

I asked copilot about a project I'm considering doing here in my home in Oregon. So I set the parameters to the county I'm located in. Chose residential code and the code year and simply [00:02:00] asked it what the requirements were for my project regarding exiting and egress. It answered my questions quickly and presented the requirements in an easy to understand way, which may be the best interaction I've ever had with the code. 

Today's conversation covers the journey of UpCodes, the challenges of democratizing access to the building code and the potential for innovation in the compliance space. So now without further ado, I bring you Scott Reynolds. 

Evan Troxel: scott, welcome back to the podcast. Great to have you again.

Scott Reynolds: So good to be back. Yeah. Thank you Evan, for, uh, inviting me back.

Evan Troxel: Yeah, I think, uh, December, 2020, it was like lockdown time last time we were officially on the, on the podcast together. So a lot has changed. And I think the last time that we talked, it was really regarding the. [00:03:00] The lawsuit that you guys were involved in. Is there any update that you wanna provide before we jump into like the real topic of this conversation?

Scott Reynolds: Well, first I'll mention, wow, time really flies. I can't believe it's been that long since we, uh, last connected,

um, In terms of update, not, not a whole lot actually. It just continues to kind of drag on. We got a lot of, um, I'd say pretty significant milestones in terms of wins and more and more case law.

But, uh, these things always get dragged out. Uh, the American legal system, you know, allows for these things to span over years and years, so we kind of push forward through that. Um, you know, hopefully in the, sometime in the future there'll be some kind of, um, I think positive, you know, collaboration or, or end result to, to it all.

But, um, long story short, continues to, to, uh, drag on unfortunately.

Evan Troxel: I'll put a link to that episode in the show notes. You have been on the podcast a couple times before, and so like, I don't wanna dwell on that for too, too much here. That the whole idea of [00:04:00] copywriting, the building code was kind of the topic of that conversation and who should be able to or not be able to do that?

Obviously up codes, this is your, Livelihood and, and you are trying to make it easy for architects and other building design professionals to access the building code. You're obviously doing a ton of work to kind of democratize access to that and provide innovation on top of that, the way people, uh, engage the building code, uh, I would hope to make it easier, right?

This has always been one of those things where it's like you go to the wizard in the corner of the office who knows the ins and outs of the, and they, they have their three ring binder and they're flipping through and they've slipped the, the addendum sheets in and, and it's this, you look at that whole thing and it's like, there's gotta be a better way, man.

And obviously this is what UP codes is all about. And speaking of innovation, I want to talk about what you guys have just recently announced, which is copilot. And, uh, [00:05:00] so, so I'm just gonna turn it over to you, man, like, give us the update and tell us, uh, what is going on with up codes and copilot.

Scott Reynolds: Yeah, absolutely. And, and thanks for the, for the lead in there. So, so just going back to what you mentioned, just free and open access is a huge pillar of, of what we do and a lot of the previous years of development has just been bringing together this online library. So today we host over 5 million sections of code, so spans from building code, plumbing code, fire codes, accessibility codes, kind of through the gambit.

And we're just bringing on more and more. But as you know, you're back in architecture, I'm sure, you know, that's really, really hard to parse.

Evan Troxel: Hmm

Scott Reynolds: Historically, we've had things like a search engine, so you can go into a jurisdiction like Massachusetts, Florida, California.

And kind of cut across that jurisdiction, the codes, but ultimately it's still coming down to you to figure out what's relevant, what's not relevant.

Um, we do things like diagrams and [00:06:00] educational content to help people through, but with a lot of other industries, we had our kind of eyes on these AI models coming out. The LLMs, which seemed really promising for parsing large, large, uh, data sets, specifically text. And I think those are expanding to more things like images.

Um, but the, or what we are perceiving is the, the bread and butter of those LLMs is parsing text. And we looked at it and say, Hey, this, this could be a really big opportunity for us cuz we have this massive library of techs. Can we harness it? Can we, can we bring that into the product?

Evan Troxel: It seems obvious, right? It's like you've got this giant corpus of training data, which is all of the model codes that are out there, uh, different jurisdictions. You've already mapped what is appropriate for where, uh, to, when it comes to the different ways in which people engage the, the building code on every project, that is probably a little bit different. And [00:07:00] this whole idea of kind of augmenting the existing system to be more accessible to more people, uh, because, and this is all, like I said, we, we went to the wizard in the corner, right? Because they're the ones who had the expertise, the wisdom of working with the building code and code officials and kind of that handshake that happens when you submit a drawing set and specifications where they're working through all of those comments that come up. Ad hoc on the, you know, right then, and how, because the building code does get interpreted by different people. It's not just black and white. This is what you can do, this is what you can't do. It's like, it's full of creative workarounds and like, actually kind of interpreting the code is a creative process in and of itself, right?

And so there's so much going on there, and it seems like there's so much potential for a company like UP [00:08:00] Codes or somebody else to augment the existing system to make it. And I know we've had conversations in the past where it's like, could, could you, and I think co-pilot's the perfect name for this.

Could you make it so that you as up codes, ask me a series of questions as the designer and then present, uh, some, you know, a path to go down? And, and we've had some interesting conversations about that before in the past.

Scott Reynolds: Yeah. Yeah, a absolutely. And there's so much to unpack with what you just mentioned, so maybe I can

touch on a couple of the earlier topics.

Evan Troxel: Cool.

Scott Reynolds: so, so what, what you mentioned about bringing the, the codes together. Um, so we just adopt or, or host the adopted laws,

and that includes incorporating the amendments.

So the interesting thing when you compare, say like, like a generic, um, l l m, like open ais,

uh, chat GT or, or Google Bard, where we differ, I think in a pretty significant way is roping in the amendments. So if you [00:09:00] are, say, Massachusetts or, or, um, Connecticut and you have a separate set of amendments that get incorporated into the adopted model code, that's that kind of composite view of the code is what we operate on.

And I think it's a subtle but pretty important difference because it's bringing a lot more predictability and into the codes that, that it's look, that we're training it on and that we're bringing up his references in, in the answers. And then another point you, you raised is, is this, uh, kind of wizard, you know, in, in the office you have maybe two, three technical experts, let's say if you're a 50, 60 person size company.

And a, a big focus for us was how do we democratize the codes more and more? How do we make it such that if someone's just joined the workforce, let's say they're coming outta school, you know, first, um, maybe first position or a couple years in, or you're jumping between jurisdictions. So you're, maybe you're work in, uh, California, you want to jump into Wyoming or another state.

How do you actually [00:10:00] get familiar with those codes or a different project type? Let's say you do mixed use resi and you're jumping into commercial.

Um, how do we make it so these individuals can answer their own code questions? So exactly like you said, back in the day, you just go to that, that code expert who, uh, inevitably gets underwater with the amount of code requests coming in and.

And we, we see that role as being very, very critical.

But hopefully we can alleviate some of that pressure on the individual too, to answer, you know, across all people in the offices, uh, code questions.

Evan Troxel: there's other parallels in architectural practice that I'm familiar with that I think are all in this

category where it's like there's, there's a couple of gatekeepers in the office who do this thing and they are totally drowning, right? And so visual people who are doing like, you know, pre, you know, they're doing visualization on projects.

They're doing the high-end v-ray renders. There's only a couple of those people. If an office even has those, sometimes, [00:11:00] most of the time they're outsourcing that. Um, specifications writers are another people person, like role in this category where it's like there's one or two if a firm is lucky. A lot of times I think they're also hiring out to consultants. And then there's these, you know, senior project technical architects who. Are the ones who are the gatekeeper of, and, and not in a bad way. It's just like that, that's the role either that they've chosen or fallen into and and they are being inundated, like you said, with every single team coming to them.

And so by providing a tool that allows anyone, and, and so now in this category, the up codes category, I think of something like scape with the visualization example, right? It's like, well now anybody can do pretty good renderings. And that takes a huge load off of the visualization team because now they can focus on just the high end stuff, and they have time in their lives now to do some r and d [00:12:00] into the latest visualization techniques.

Same thing goes here. It's like if you can take some of the load off of those incredibly important roles of, uh, the, the person who really understands the building code. They can then focus on the really hard problems to solve, and not just the run of the mill day-to-day FAQ style stuff that they're used to fielding from every single person in the office. So I think that this is there, like you said, there's a huge opportunity here. Obviously you guys foresaw that and, and our building a tool to do that. But I'm also wondering just like, what have you seen as far as adoption when it comes to this thing from the the rank and file people in the office and actually successfully starting to navigate the building code, which is, is just kind of this, you know, encyclopedic, uh, undertaking.

Scott Reynolds: Yeah. And, and it is such a good point around the gatekeepers, or we might call them like checkpoints.

And you mentioned a couple, like in, in, in rendering or qa, qc that happened within Affirm.

But if you [00:13:00] zoom out, there's also these, um, checkpoints, um, externally like the plan reviewer or building inspector.

So you have these very, like highly leveraged. Individuals who tend to get bogged down, like you're mentioning, you know, going to like 

Evan Troxel: Bottlenecks. Yes.

Scott Reynolds: ex. Exactly. So, so how do we empower the rest of the office to get it maybe, you know, 60, 70, 80% there

that these kind of critical roles, um, can spend, you know, less time but, but very leveraged time to, to do review like qa q qc.

Evan Troxel: right.

Scott Reynolds: And a big focus for us is actually flowing that knowledge and information back, um, to those more junior individuals from these kind of very senior people.

Evan Troxel: Mm-hmm. 

Scott Reynolds: So you have institutional knowledge within firm cuz if you work on a certain project type, you tend to build up pretty deep expertise. But that expertise can be very asymmetrical over a firm.

So how do we take the expert in retail? How do we take the expert in commercial and help level [00:14:00] up the rest of the office? 

Evan Troxel: Mm-hmm. 

Scott Reynolds: So a big component for us is trying to capture those conversations. Capture the code research done so you can start to recycle and crib off of historical conversations.

Evan Troxel: Right, that every architectural project is based on that idea right there, It's like,

what can we take that we've done before and leverage that to give us a shortcut to get farther faster on this next project? Because the pipeline and the throughput all matters, right?

Scott Reynolds: and I'd say to varying degrees, right? Some, some firms are really good at that, really good at bringing the historical, uh, project and knowledge forward. And some maybe kind of let that slip between the cracks a little bit.

Um, and not by design, I think just, you know, because they weren't thinking about retaining more and more of that information.

But I mean, I was guilty of that when I was working, you know, trying to reinvent the wheel every time we have a project that comes in, Hey, let's, let's do something new.

Um, and starting from scratch. But I think a big component of that is trying to yeah, capture a lot of, [00:15:00] a lot of those projects.

Evan Troxel: Yeah, so, so tell us about kind of what, what this user experience is like with copilot now, or maybe set the stage with what it, what it has been. I think we've already kind of, everybody kind of knows maybe what it's like to flip through Codebooks and try to find the sections and try to find it and then try to decipher it and then try to apply it and then UP codes came along.

So let's start there with just kind of the journey that you guys have experienced over the last few years with, and now a shift, I think forward in the evolution of UP codes with, with the copilot product.

Scott Reynolds: Yeah, ab, absolutely. So where we started was aggregating the codes, bringing them together, the amendments, integrating the amendments, and kind of building up as broad of a library as we could, expanding to, to different jurisdictions, like different states, different cities. Um, and kind of, I mean, similar to like cracking open a book or, or a PDF or something like that, you're, you're still diving, you know, pretty deep [00:16:00] into the, into the code.

Now we, we brought things like, um, like search and you can start to cut through very, very rapidly through different things, 

Evan Troxel: Imagine that. Yeah.

Scott Reynolds: Right?

Evan Troxel: searching the building code, uh, incredible

Scott Reynolds: And I mean this, I guess this gets into different topic, but there's been so little innovation, especially in the code space and compliance space. And that's really what we're trying to, trying to lean 

into. 

Evan Troxel: Well, because people actively avoid it. I mean, it, the,

to me, the, the behaviors that surround the building code and just kind of the, the, the, the lore and the legend and all, you know, it's, it's not one of those things that you get trained in school as an architect to really dive into. It's always an you, you're aware it exists.

People will bring it up during critiques and juries. Oh yeah. Uh, you need more than one exit in that room kind of a thing. But it's always in passing. And then you get to a real project and it's like, now, uh, we are responsible for the health, safety and welfare of the inhabitants of these buildings as licensed or registered architects, and. Like this is real. This is the real [00:17:00] deal now. And, and then there's this, this giant book that you're staring at on the counter

and, and just surfacing the information that you need for your project in your jurisdiction in this construction type. But this occupancy mix and all of those things, it's like what a puzzle that we're all

faced with. And so I think up codes and the digitization of codes and what innovation could happen there just had had so much potential right from the start.

Scott Reynolds: and, and just like you said, that that puzzle, so you, you have, you have big books, you're trying to comb through it, and inevitably you're gonna miss a section a, a more stringent section that might exist in a different chapter

or, or different, different book. So going back to your question about, you know, what's, what was the previous landscape?

What does it look like now for us, AI and, and copilot is kind of a new portal into those codes. So it in a much more intelligent way can parse through all these different codes and very plain English, give you an overview. [00:18:00] And if it's simple enough, maybe it gives you the answer, but at the very least it's gonna start to point you out to the right places and brings that code section into the answer.

And that was a really big moment for us is, is when we realized, okay, it's not just a, it's not a black box, it's gonna spit out a code section. We're gonna lean into the educational component, we're gonna lean into getting people more and more familiar with the code. So it's almost more like routing people.

So it, it brings together maybe, you know, 10, 15 relevant sections of code referenced in, in the kind of plain English AI output, but highly encouraging people to get right back into the code.

But in a much more intelligent way in, in a much more kind of surgical and, and precise way of, Hey, jump into the fire code here, jump into the electrical code or the building code relevant to, to that question.

Evan Troxel: Bringing that information to the user rather than them going down the rabbit hole and trying to find it themselves. I mean, I, I was first thinking, okay, the code is [00:19:00] all about cross-referencing sections and I mean, this is what the internet is really good at, right? This is what http and hypertext and it's, it's really good at that.

I mean, we've all experienced getting lost in the internet by following links, right?

And it seems like an obvious application to something like the code, because the code is all cross-referenced as well. But it, it was all manual, but now you've. Just flip the script and instead of somebody going down the rabbit hole, you're bringing that information to them, kind of almost a recommendation engine or a suggestion engine that's saying, okay, you're looking at this, you probably need to look at this.

You probably need to look at this, and you probably need to look at this, or you do need to look at this. And, and just bringing that to the surface right in the very beginning

Scott Reynolds: Exactly. And I think the really powerful part of the AI model is it can go down those rabbit holes, hundreds of thousands of those rabbit holes in a couple seconds, and then choose the end result of the rabbit hole. Maybe, you know, five or 10. So you don't have to manually go down all the different [00:20:00] rabbit holes.

Um, I think that's exactly it, just the kind of scalability of the model to, to lift out the relevant information, just put it in front of you so you can make a better and and more educated decision.

Evan Troxel: so I, I definitely wanna talk about. Accuracy and I want to talk. That's just something that keeps coming up when we're talking about like chat, bt large language

models, training. It's just can you, can you trust? The results. Right. Um, so I definitely want to get there, but maybe before we get there, I want to talk about adoption because the whole point of democratizing this is obviously scale is going to be something that you're very interested in as the, the service provider, the, with this platform. And so and so tell us like what adoption has been like by creating a tool that has innovated on the building code. Because I think this could apply to. More than just up codes and more than just a building code. But anybody who's working on a, a tech solution in a [00:21:00] e c, because I think as a former head of digital practice in Affirm adoption is like one of the hardest nuts to crack in affirm. And people have to enjoy using your tool. People have to see the value. It has to be 10 times better than the thing they're used to doing. It has to, they have to see a case study to like prove to them that it's going to work before they even try it the first time. And so all of these things are kind of swimming around.

I'm just wondering from your perspective, what, what adoption has look like.

Scott Reynolds: Yeah, and adoption, I, I'd say, is significantly more than we ever anticipated.

Evan Troxel: Mm. 

Scott Reynolds: Um, so my background being in architecture and we started with a lot of codes kind of geared and oriented towards architects. But fast forward today, you know, many years later, we have over 650,000 individuals on the site every month.

So over half a million people coming on, and it's very, very diverse. So of course, architects like, I think, uh, no, that is the biggest, uh, user segment, but [00:22:00] it's GCs, it's trades, homeowners, owners, developers, plans, examiners, building inspectors, and then some surprising ones too, like students or insurance companies.

Um, so it's a really, really wide range of individuals on it. So going to the adoption side, I think more than we ever anticipated was. The kind of breadth of, um, how applicable it would be to, to these different use cases. And kind of a, an interesting topic for us when developing the product is how do you have a very opinionated product where you're, you're building it for a couple use cases where the audience is so broad.

And I think what we really enjoyed about AI is that it can be very broad and we can solve a lot of different use cases. So if you're a homeowner coming in, you're like, you know, I need a checklist for, for my, um, my deck or, or some kind of extension, or you're coming from, um, a daycare center and you want to understand like what's the, uh, exit [00:23:00] requirement?

Or of course, you know, you're a professional designing a building. Those use cases are very, very different. Or for instance, different context. Maybe you're a building inspector on site and you're on your phone or your tablet. So not only different workflow, but also different form factor of what you're actually using for the

product. So, The adoption is, has been a blessing, but also like a challenge in a way because you, you get pretty diverse, uh, demands

Evan Troxel: Yeah. The user base is huge. I mean, when I was just thinking, I've done some remodeling in my house, I recently moved from one state to another. different different code. That they've adopted here. And it's like when you're running a mechanical vent out of a bathroom, what's the diameter, what kind of, what do they accept?

You know? And, and what you might find on the shelf at Home Depot is not necessarily what the code requires. Right. And so it's, it's like, as a homeowner, you're right. I mean, it's, that's one type of user that you probably didn't start [00:24:00] out looking to like as a, as a target audience, right? You start more with like this mid-sized, large firm. Uh, I, I could just see how that has probably grown, like you just said. Uh, there's just so many different use cases for this. And by democratizing it, it actually opens the door for normal people to understand how to access and, put it into practice. The, the building code. I mean, that's, that's just phenomenal.

Scott Reynolds: And most of the growth and adoption to date has been organic. So things like word of mouth, so people sharing it with colleagues, sharing it with friends, sending links through emails and things like that. Or, uh, through, you know, finding through Google. And that's driven most of the growth. But as a result of that, um, you know, we're, that growth hasn't been intentional.

Like, and other companies, you know, 

Evan Troxel: it is. 

Scott Reynolds: Exactly.

Evan Troxel: Yeah.

Scott Reynolds: And at one point in time we mapped out, okay, what are the sizes of firms from sole [00:25:00] practitioner to some of the biggest architecture firms in the country, and what's our distribution compared to the, the actual distribution? And that curve was almost exactly the same as, you know,

what makes up our, our industry.

Evan Troxel: So

you have this perfect cross section of the industry mapped out and the adoption, you're, you're seeing it in, in all of those different kind of, i, I guess, horizontally across, which is what the code also is doing, right? It, it applies to e all of these different scenarios. And I That's, that's pretty cool to see that,

Scott Reynolds: and in an interesting way, architecture has a, an unusual distribution of those firm sizes. So it's, it's overrepresented on the small and medium-sized firms compared to larger firms

when you compare that against other industries. So it's, it's. And the type of work done by those different firms, you know, varies pretty dramatically.

So it goes back to that challenge of how do you build for all these different use cases when they do vary so much. And there's actually this very big [00:26:00] representation on the small and medium, which is great because, I mean, this goes down another rabbit hole. But, uh, when it comes to user interviews and connecting with the community, it's, it's really nice when people are so invested in it.

And we can jump on the phone with small practitioners and maybe 10, 20, 50 person firms, but then also firms that are hundreds of people big. But it, it does change, uh, pretty significantly.

Evan Troxel: Yeah, it, it just makes me feel good. Scott, that you guys have gone after this incredibly. Unsexy ignored for the longest time problem in the industry. And to see the adoption that you are is really reassuring to me. And it just shows that the, we have to get the fundamentals right for the really cool stuff, I think, to even catch on because the fundamentals are what affects the majority of the time of an architect and an engineer, and the day-to-day life of those professionals. And then when they [00:27:00] see the value there, I think they're gonna be more open to seeing the other topics that we talk about on this podcast and that are going on in. That are innovating on top of innovation, inti inside of a eec. So I, it actually, that, that just makes me feel hopeful that there is a, is a way forward because adoption, like I said earlier, is, has always been a struggle in a e c because, uh, we're so busy doing what we're already doing and so it really does have to make a difference in the day-today first.

Scott Reynolds: Yeah. A a absolutely, and exactly like I said, is not a glamorous space, right? Code. I mean, some people love code. Some people, um, get in there and, and, and spend, you know, their whole day in code and absolutely love it.

But there's a huge percentage of, of the user base or just in any firm who, you know, this is not their favorite part of the day when they're jumping into the code.

Evan Troxel: right.

Totally. 

Scott Reynolds: w we're very conscious of that and try as much as possible. We call it getting [00:28:00] outta the user's hair. And basically, when it comes down to the usability, the ui, the ux, how do we make it as streamlined as possible such that they can focus more on the code? The code is so complicated, we don't need to make the tool itself more complicated to make their day more challenging.

Evan Troxel: sure. Of course.

Scott Reynolds: And that, uh, goes through everything. So things like the pricing model, trying to make it as, as, as straightforward and cheap as possible. Um, the, the, the account management, setting up projects, bookmarks, all of that kind of surrounding ux, it's, we're trying to constantly make it more and more and more simple so that they can focus on the code.

Evan Troxel: Yeah.

Scott Reynolds: And to your point about adoption, like it, it does need to be, you know, 10 x as good as is what they had before. And I think what we've really tried to lean into is the net promoter score. So for the folks listening, it's, it's just a way to kind of understand, are people enjoying the product and would they recommend it to other people?

The simplest way to measure that is [00:29:00] saying, okay, on a scale of one to 10, what, how likely would you be to recommend this to someone else? And it's very simple, but pretty powerful. And through, you know, through the years, we've always maintained being an, uh, a hundredth percentile in terms of nps when it comes to software.

And I think with something that has the potential to be relatively dry for people with code, that, uh, investment in UX and and enjoyment of the product is so critical. I mean, I think it's always critical to your point about adoption, but especially in, in code.

Evan Troxel: you, you've provided a perfect segue. Let's actually talk about what it's like to use up codes for those who are not. Initiated, uh, on the up code site. And then I think this also is, is the point at which you wanna start talking about the addition of copilot and how that maybe has changed things with, with the UP codes interface.

Because it also could be that somebody has used up codes in the past and now [00:30:00] maybe there's an entirely different way to, to use it. So jump into that part.

Scott Reynolds: Yeah, absolutely. So, so to cover the past and what people might be familiar with, we've, we've always leaned into democratizing code and, and putting it out there, um, for free, and then building more sophisticated tools on top of that, that free access tools that start to automate, start to help with collaboration and, and project, uh, management.

So the big difference now with the co-pilot launch is providing an entire entirely new entry point or portal into the code. So instead of cracking open, um, let's say Florida or, or maybe Washington State, instead of going to that jurisdiction, um, clicking on the building code, uh, maybe searching, combing through it, that entry or that user journey can be completely revised by starting in copilot.

And now you can just say, you know, it can start very, very broad, or it can be very, very specific. Now you, you got a text box [00:31:00] and you can say what, um, you know, or generate a checklist for my egress, um, and maybe throw in an occupancy type. Um, and, and a building type.

And it'll start to spit out, okay, you know, check out these 10 different sections and it, it links out and references to those sections.

So that's, you know, something on the, on the larger scope, or it can be very tactical, you know, going to a, a building inspector, what's, um, you know, what's the minimum width of, of a corridor, uh, in a hospital

or, or maybe on the single family resi, what's, you know, what's the handrail, uh, extension past the last, uh, the last stair?

And it'll bring up those sections. But also just answer your question in, in place.

Evan Troxel: this whole idea of natural language as an interface is huge. And to, to truly democratize something and for someone in a, in plain language, be able to type in a request or a query or a, a command is just. [00:32:00] Such a big deal. Like anybody in an office can now use a tool like this. Anybody, right? Anybody can form a question or whatever the, the input typology is. I think normally it's gonna be a question, right? But it's like any, anybody can ask a question. And I think that's the most powerful thing about what we're seeing with all of the ai, la large language model products that are out there is just, okay, what comes back aside? Just that interface, just being a prompt is huge.

And what you're talking about to me takes me back to the days of multiple search engines on the internet like Yahoo and Alta Vista. Which was a directory of information. And like you said, it's like you dive in one level and then that presents another level, and then you go into that next level and it presents another level deeper and you keep going down and down and down. And then Google came along and completely flipped the model. And all you had to do was search for [00:33:00] a term and it surfaces results based on that. You didn't have to click, click, click, deeper, deeper, deeper anymore. You, you still could do that. But the very first interaction was just the prompt, the text box on, on a white screen.

Right. And to me, I think this is, it's really powerful to simplify the interface that much where it's just a text box.

Scott Reynolds: And that freeform text box makes it more approachable by a wider audience and firm

because, I mean, using a really simple example here, but glass versus glazing or the kinda the lingo that you, you do in the vernacular, you pick up through years of experience, but now it's much more approachable. The, the exact phrasing matters a little bit less when you're starting.

Now the phrasing will matter a lot, of course, like when you're getting to the code. But for us, if you're saying. A guardrail versus handrail or, uh, different concepts. And you don't phrase it quite right, it has a lot of buffer [00:34:00] to still get the answer right, like you can, you know, there, it, it provides a lot more, um, uh, ability to parse messiness in the query, I guess a wider funnel at the top.

So it, it can bring in more and more people from, uh, from the firm and on a, in, in kind of related topic, like you don't know what you don't know.

Evan Troxel: Yeah. 

Scott Reynolds: And you kind of mentioned this earlier before, but I just wanna kind of circle back to it. But this chatbot actually has the ability to ask you questions back, which I think is a really, really powerful thing.

And now for the first time, um, for us at least, we're having a back and forth. So you might ask a query and you might say, what's, what's the width of the corridor? Well, you know, that varies dramatically. Are you talking about a single family? Residential home? Or are you talking about a hospital or something commercial and what's above it and what, what are the, um, occupant loads?

So before it would be very, very hard to parse that. We would just have to [00:35:00] pull up everything under the sun that could be related to that. And, and there's a lot related to that.

But now we can say, okay, well you might wanna look at these sections, but even better, what, what's your, what's your project type?

What, what are you working on? Where are you located?

And starting to 

Evan Troxel: Establish that Context. Yeah. That that is, that is cool. I think that one of the examples you talked about a minute ago was like, um, provide a checklist of. Things that I need to pay attention to. I think that that is so powerful because that would be a question that I would go ask the wizard in the corner, right?

Hey, do you have a checklist? Do you have a, like a, a, a rule book for this kind of project that you can give me as a starting point? And now I can ask the software to do that. And the software knows about code updates. I would assume it knows what's changed and how recently and, and things to look out for.

And I think it could probably be even more appropriate in its response than even somebody who's been working in the code because [00:36:00] things do update and you can't know everything about everything. Like you just said, we, we don't know what we don't know. And so for it to bring that to our attention early is, is incredible. I think of other use cases that, that you could. Ask a system like this early on in a project. There's so many, it's, it's just like, what do I need to be aware of? What are the code sections that people miss? I, I could just see there being so many kinds of queries in a system like this to really gain someone the experience they need right when they need it on demand, rather than having to have the, the years and years of experience, which isn't a bad thing, but it's not something that's actually happening either.

Right? Like you said, people are kind of avoiding this, this whole section of the practice for the most part. And this is opening doors to people having a better understanding of the code and by providing a tool that makes it easy to apply it on their project is a big deal.

Scott Reynolds: E. E, exactly. And on the topic of updated code, we update over [00:37:00] 7,000 sections of code every single month. So 5 million sections on the website, over 7,000 get updated a month across all the different jurisdictions. So it's very much a moving target

Evan Troxel: Yeah.

Scott Reynolds: and there are really good checklists out there. You can find like, I think it's Los Angeles County, um, and, and a couple of other ahas have very, very good checklists.

Challenge being, they're very static

and they, they're kind of frozen in time. Now, maybe in a year or two they could get a, get an update. But that's a one size fits all static checklist that, you know, tries to cover this large swath. The reality is everything's dynamic. The, the foundation, the codes underneath are constantly changing.

And your specific situation where you located your project type occupancies, is gonna affect that checklist.

So for us, we, we had a lot of user requests coming in for checklists, and we always knew we wanted to tackle it and make that kind of feature, but couldn't wrap our heads around how do we [00:38:00] make it scalable?

Like, how do we not put out

things that could just be a blog post? Um, and this is starting to, uh, provide that way where it's, it's kind of infinitely scalable based on your inputs. And for every individual, they're gonna get a different checklist because they deserve a different checklist and they need a different checklist.

Evan Troxel: So let's talk about accuracy here, because you're talking about something that is starting to get more specific around project types. And, and, and let's just say, you know, for, for the topic here that the checklist is, um, you know, it's tailored to a specific project type in a specific jurisdiction. And so give us what what are the, I mean, it does seem like accuracy is a potential pitfall here. It could give you the wrong, how do you double check? What are you guys seeing as far as accuracy on the output? What's the feedback that you're getting? Because, uh, if you have a a young emerging professional using a tool like this, I, I think the, the natural inclination is to [00:39:00] accept it as the answer. Whereas like somebody who's been practicing for 30 years might say, oh, I would never do this. Uh, it missed this kind of a thing. And is there a way to then like, reinforce the model with additional training based on that experience that does exist out there?

Scott Reynolds: Yeah. And, and just to zoom out a little bit, there's, um, a site you can look at. I think Washington Post might have posted the article, but you can see what data went into Train Chat GPT from OpenAI and 

Evan Troxel: Google Bard

How did they 

find that out? I don't think that they published that themselves. Did they? I mean, OpenAI didn't, but, but sounds like some investigative reporting happened here.

Scott Reynolds: So it was actually a third party who provided the data. So it's called Common Crawl, C4 Data Set and Common Crawl, just like it sounds. They go around the internet and they scrape and they bring together massive, massive data sets, kind of like Google Search would do for, for its search results. 

Evan Troxel: Mm-hmm. 

Scott Reynolds: Um, they combed the internet, pulled together into a huge data [00:40:00] set, and that's the data set that went on to train, Chat GPT, and Google Bard.

Now, uh, common Crawl actually offers a way to see what websites have been scraped. So we went in there, uh, didn't really know what to expect, who said, you know, did our data contribute? To these models,

and as it turns out, we're in the top 0.01% of websites that contribute data. So, um, I forgot how many million, millions of tokens we, we contributed to it, but our, a lot of the laws and the content we host was very, very, uh, substantive in terms of training these, these models.

Evan Troxel: I would imagine this plays back into that lawsuit. We started out talking about potentially

because it's like, is this proprietary data should something that, that is required on all projects be considered proprietary data that, that no one else has access to? And so using it as training data, I mean we've talked, I've at least thought about, I don't think we've talked about it on this podcast before, but the whole ethical side of [00:41:00] what the training data is, where it's coming from, was there permission, all of those things.

Uh, I mean obviously there's, there's a lot going on on that side of things.

Scott Reynolds: yeah. Yeah, absolutely. And. The, um, I, I guess from our perspective, all of these adopted codes enter law and fortunately all the case law and the judges have come down on the same side to kind of firmly put that, um, into, into the public domain. So when we're looking at these LLMs and, and more generic ais, it's actually high quality data like the American laws that are actually training it along with a lot, a lot of, uh, other things and the other areas that are not, let's say, like law.

I think that is a really interesting topic, right? Like what goes into these models? And to kind of circle back to the question about accuracy. So we have the codes we host, uh, and they're out there, you know, for free in, in, in the public. But then we incorporate other information to give those answers.

Evan Troxel: Hmm.

Scott Reynolds: Um, in addition to setting up [00:42:00] filters.

So when you're jumping into a question, we can start to fence in around the right up-to-date data cuz these. Uh, generic, um, LLMs have a snapshot. I think it was, uh, probably roughly last time we spoke in 2021, I believe was the last snapshot they took. So

Evan Troxel: Right.

Scott Reynolds: going back to 7,000 sections updated a month, we can say, okay, you're in California, but we, you're using the most up-to-date code for this answer.

So now we've, we've kind of constrained it, we've roped it into a jurisdiction, we've roped it into a certain time period. Or you can go historical. You can say, let's, let's use a historical set of codes for different permitting date. And that's a, a, a really significant way to increase the, the accuracy compared to the generic, uh, llm.

So that's what I was gonna mention before is despite contributing all this data, it was a snapshot from a while ago, and you get kind of older out of date codes, but also just very generic across the whole US [00:43:00] where the reality. Is it changes pretty significantly, you know, to your, your example about the, uh, the pipe, uh, piping size moving states.

Evan Troxel: right.

Scott Reynolds: So, um, and then the kind of another category I'd say is weaving in more content. So very soon we're gonna bring in our educational content, the diagrams, which start to explain and unpack different code concepts, and then that becomes yet another kind of source of information that we can feed into, into the AI response.

Evan Troxel: Yeah. The the new features that are, are showing up in what Open AA is talking about, where they draw a diagram, feed it into the system, and it makes a working website off of a, a really poor napkin sketch of, of a website, right? It's like I could see application of things like this in architecture, right?

Where somebody can. Draw a very simple diagram and feed it into the system and have that be the basis of search results. But also, like you're, you're talking about like maybe potentially training data or [00:44:00] capturing the wisdom of the individuals who sit in the corners in these offices before they retire. To apply that to the tool set in the office to make it easier for other people to get down the right track sooner in the things that they specialize in, I think would be absolutely incredible to be able to, to, to somehow do that. And so in which ways are you guys capturing, or, you know, like threading in the, the additional information, is there a way to capture the knowledge of individuals and, and actually get that in there somehow? Is it feeding existing drawings or models or anything into the system to be able to do that?

Scott Reynolds: Yeah, great. Great question. So I'd break that down into two different areas. So one is the content up codes has produced, and I think we have now over a thousand or 1,100, um, diagrams that start to, you know, unpack the code and that, and that's, you know, available on the site, um, [00:45:00] currently, and that's gonna add in a whole nother layer.

But those are things produced by us 

Evan Troxel: what kind of diagrams? Before, before, before you move

into the part two. Like what? Just give us a couple examples of what kind of diagrams you're talking about.

Scott Reynolds: yeah. For, for sure. Um, so things like calculating an occupant load, like how do you do that?

Um, kind of layering it on top of the code, giving examples, giving diagrams, um, a high level overview, trying to.

Evan Troxel: deal. Yeah. 

Scott Reynolds: Train up and kind of elevate people's understanding of the code

or highly technical things like a, uh, like an assembly or a detail.

So here's like a fire rated wall. How does it interface

with, say, a penetration or a duct coming through the wall? What, you know, what does that look like? It's kind of hard to picture that when it's just a wall of text when you're looking at the code.

So bringing up examples and, um, yeah, yeah, again, like diagrams or assemblies or kind of like line drawings, and then a plain English overview of what that actually means.

Evan Troxel: I think this is such a big under, you can't understate how important this is, or overstate, I don't the right word, [00:46:00] but it's, it's like the. The aversion, because this is a text-based resource in a very visual field,

is I think the kind of obvious observation that I can make right there. It's like, this is why so many people avoid this.

And specifications, it's like, uh, text, no thanks. I don't read books. I draw drawings and I read drawings and I talk about things in three dimensions. And, and I can just see the kind of misalignment that happens in our field. And so to be able to marry diagrams with text is gonna be such a huge part of adoption, like successful adoption.

If you can do that at scale, I mean, that just seems like an incredible, um, I don't know, like just, it just is gonna unlock this for so many more people.

Scott Reynolds: And it is one of our most, um, popular features for exactly that. You have these highly creative individuals who are working [00:47:00] in, you know, at least 2D creative, but more, most likely in 3D creative. And then you throw a phone book in front of them and expect them to go through and be excited about digging through hundreds of pages of, of text

Evan Troxel: No, that's a

paperweight man. Yeah. Literally Geez. So I, I interrupted you, you were, you wanted to break my question down into two pieces. Do you remember what

the second piece was? Yeah.

Scott Reynolds: Yeah. So, so it's what additional data can you train the model on? And the, the first component of that was our own data that's going above and beyond the code to, to help parse it and, and train the model. But number two is, is coming from the users. And we're very keen and aware of the privacy aspect of that.

And this, you know, we can get into a huge, uh, kind of interesting, uh, rabbit hole about, you know, other things like OpenAI and what does privacy look like. There are you contributing to training their model. But the way we look at it is within a firm. So if you are, let's say like a large or, or it doesn't really matter, but [00:48:00] any architecture firm, how do you better recycle that historical context that all the conversations you've had in the past?

And that's exactly where we're moving, is to say, you're gonna utilize that your data is gonna train your version of the model. Or it's gonna inform the answers for your firm, but not everyone else's answers. So you can be a lot more confident to put more data in there and it'll be, uh, kind of siloed or have a firewall.

So,

um, your firm will k keep reaping the benefits, uh, versus sharing it. Um, now that, that's kind of where we're netting out or landing, I, I do think there is a downside to that, but it's kind of the nature of the industry where firms can be a little bit competitive with one another. They don't necessarily want their details or, you know, their decisions to, you know, uh, disseminate to to other, other firms.

So, you know, personally, I, I think we could benefit from, from sharing notes a little bit more,

uh, from kind of [00:49:00] collaborating

a lot like the software

industry does, but, uh, at the same time we, we need to kind of respect what, uh, the users are requesting.

Evan Troxel: It is, there's a double-edged sword there, right? Because the, the whole idea of that being your secret sauce, your ip, when it comes to how you produce deliverables, but then at the same time, to your point, like you can raise more boats and make a stronger profession by sharing this information. I think about the high par model, at least as it was kind of stated early on, which was like, encode your knowledge into a function and then sell it on our marketplace. I don't know if that's gone anywhere on in high par, but, but, then you could potentially monetize that as an income stream because you do have expertise there. And it is valuable. And it is useful and maybe it's a very small amount, but at least then it kind of justifies the work that went into using that information for someone else's benefit.

Right. Like actually capturing it, actually using it to train the model, but then somebody else [00:50:00] benefits from that. Couldn't you benefit from doing that process? Absolutely. And, and maybe, maybe there's opportunities there. I I, I don't think you're trying to create a marketplace for, for firms with building code stuff, but it does seem like, um, there's a lot to talk about there and, and, and to get outside of a firm's echo chamber and have those kinds of conversations, I think is really important at the national level because there are benefits to sharing that kind of stuff versus keeping it all inside the, the silo.

Scott Reynolds: Yeah, a absolutely. And there's a good analogy in, in software development with open source.

So there's a lot of open, open source packages and they all build on one another, like building blocks. And it provides a really, really robust foundation that when you launch your product, you can utilize a lot of these packages and you can give back and you can contribute to existing packages, uplevel those, someone else might come along and, and, you know, take the baton and, and run with it.

Um, or, or companies or [00:51:00] individuals contribute new. Open source packages. And it's a really interesting study because I think on balance, like you're saying, the, the rising tide can potentially all boats and I think it really has in software and it's, it's, uh, a little bit of paying it forward, um, contributing back into the ecosystem.

And, and I do see that it's, it's a little bit difficult where your, your knowledge or expertise is kind of what you sell when it comes in, in terms of architecture and, and design. But I think there's probably some balance we can do there where we are sharing notes, we're lifting the whole industry as a, um, you know, by sharing all, all the notes, but retaining maybe some of them and retaining some institutional knowledge.

But, uh, I do really appreciate how open a lot of the software developers are in terms of like, putting things out there from small to big. Like even Facebook is putting out and, and Microsoft pretty, pretty large. Um, uh, open source packages.

Evan Troxel: Yeah. [00:52:00] Maybe nuts and bolts question. Uh, how are you actually, what kind of tools are you using to create and train your own? Chatbot. I, yeah. I'm interested in this personally. Uh, I don't know how willing you are to, to talk about this stuff. Maybe this is your own secret sauce, so feel free to just say no.

But I, I'm in, I am interested in, in learning. How, because, because if a firm out there has information, are there ways that they could even apply it, start to apply this kind of thinking to the resources that they have to do some of this kind of training?

Scott Reynolds: Yeah, absolutely. And maybe because there is a little bit of secret sauce there, maybe I won't go into the specifics of our own implementation, but just talking in general, um, there are a lot of packages and, and tools out there, whether they're open source or or not, that you can start to combine. And I think it's when you combine them is is where you get a lot of the kind of interesting innovations.

Evan Troxel: Hmm.

Scott Reynolds: Um, Google early on had a [00:53:00] really good, uh, kind of phrase, it's combinatory innovation, and it's taking these innovations in adjacent industries, combining them in a unique way that presents a whole new, uh, opportunity in, in your own industry or your own space. And they did that a bunch with things like search or, or Gmail or, or drive.

Um, new things came up that they could have a very kind of insightful take on, on those products. And I think in a similar way, when firms are thinking about it, the, probably the, what will help them most is seeing the landscape, keeping their finger on the pulse and saying, what, what can we combine that can give us a new opportunity to create a, a new, a new tool?

That being said, the landscape is changing so rapidly, like every week, right? Like I subscribe to like a weekly update for all the ai, uh, updates. And it's moving so fast

that you do need to be very, very nimble in a way that you didn't before because there's things coming on the scene every [00:54:00] week, and they can be more powerful and you don't want to invest too deeply in something, uh, that you, you know, tool that maybe came out a month ago because it might be surpassed in, in, in another month or two.

And you need to faster than ever be combining these different tools together.

Evan Troxel: so, so yeah, another double-edged sword that the whole idea of getting in there and messing with this stuff so that you understand it is really important. Because if you don't, if, if you're, if you hear that and you think, okay, I'm just gonna wait, like this is clearly moving so fast, it's a freight train.

I can't just grab on and go with it because it's just moving too fast and whatever I invest in now could potentially be obsolete in a very short period of time. That's not, I don't, I don't think that's the right approach. I think the right approach is to, Dip your toes in, get your feet wet, and learn how this could potentially apply because your subconscious will then take that experience and just start spinning the gears on it and [00:55:00] something else will come out and you'll be like, oh, well this unlocks that thing that I ran into and now I can take it further. I think one of the, one of the things that I saw early as a pitfall, a potential pitfall was, Train a, train a thing with all your data, and then you can throw your data away. It's like, no, you're probably gonna have to train another one later. So keep all of that information handy. Don't get rid of it because, because I mean, uh, every architect out there is sitting on mountains and mountains of data that they don't know what to do with. And so now there's potential applications for that. So if you do, do some training, don't toss the training data. You're likely gonna have to train it again or again, or again, or a different product, right? So, uh, a, a couple things to be thinking about when it comes to this, but I think it is important to get started so that you can leverage it when those aha moments present themselves, because you already know what to do in that circumstance, and you're not starting from scratch three years from [00:56:00] now, because you're not gonna wait any longer then.

Scott Reynolds: It it is. Exactly. And, and just to highlight one thing you mentioned of, you know, sitting on mountains of data, no one knew, but these mountains of data and data sets would be the gold lines of the future. Because these LLMs, they kind of burst onto the scene, require these, these, uh, proprietary and or, or otherwise just, just data sets.

So absolutely don't, like, don't, um, you know, throw those away. Like there is tremendous value there. And, you know, for better or worse, um, our industry has been a little bit guarded in terms of sharing data, like we were just mentioning before. The end result of that is the, the data can be very siloed, but very valuable.

So it's gonna be a very interesting next couple of years where we're different people look to connect different, uh, data sets to build these tools. And I don't exactly know what that would look like, but it could be firms partnering, firms collaborating, maybe, um, you know, providing APIs [00:57:00] to different, different tools.

there's that component of sitting on these, these gold mines in terms of, uh, getting involved, getting your hands dirty, building the tools. I, I would highly recommend that, that as well. And it's, it's kind of like company building. You are, you're most likely gonna go through some pivots. You're gonna start in one place, and it, you almost never end up in the same kind of trajectory where you started.

You're gonna learn things along the way. You're gonna soft pivot or hard pivot from there, and you're gonna be adaptable. But same thing with AI and a lot of these new tools, you don't really know how to adapt or, or, or pivot if you don't have familiarity and institutional knowledge of those tools.

So if you jump in, you get familiar, maybe the the ultimate end product that you'll ship in the future is not what you started with, but at least you got started.

You, you, your team is familiar with it. They can start to pivot, they can start to change. And when that real opportunity comes along, you can jump on it much more quickly.

Evan Troxel: So carve [00:58:00] time out to do this thing like that, I think is the hardest part for architects is like, instead of just being, uh, somebody who watches this happen from a distance, is to get involved, uh, and, and realize that there is pot, there is a high potential future value in getting involved in this because if you strictly are just somebody who watches it from a, from afar, it will pass you by. And, and I, I don't mean that in like, you could never get started. It, you, it could be too late, but you will be much farther behind in the learning curve than somebody else. And, and the whole light, you know, the. On, on some level. Like there's a lot of hype around this stuff, but, but you're here today to kind of talk about the value that it's added to the product that you make and that you're putting out into the world. And so maybe I'm not the right salesman for this. You're, you're way better, in a way better position to be the right salesman for this, especially when it comes to copilot and [00:59:00] up codes. Um, just talk about the value that it's created because. Nobody saw this coming. Right. Scott this is one of those things where we all had this data sitting around because we're, we're data hoarders and we grew up in the, we, we saved as we save, as we save, as, we have all these different versions of our files for all the years.

And the millennials can thank us later because we, we knew how to file structure and directories worked and all that stuff. And my kids today don't even know what a file is. They don't know where it is. They don't know how to like it. It's, it's funny to think about, but, um, but now because the, all of that data has been hoarded, it can be used for training and especially in your case with up codes, being able to use that for a product that is available today.

Like, I mean, I think that's absolutely, you're, you're a great case study in kind of making the case for jumping into a tech like this that's that's just recently presented itself and you're already taking advantage of it to add value for architects across the board.[01:00:00] 

Scott Reynolds: And, and I do want to, um, note that we see this is the early innings. Like this is just the, you know, I wouldn't even call it a V one, I'd call it a, a v 0.1. Like this is the very first iteration, and over the coming months, the coming years, it'll, it'll constantly evolve and, and constantly get more and more sophisticated.

Um, and our original goal is to be a tool that augments professionals and, and, and folks trying to parse through the code before copilot. Uh, in a survey, I think we were around, uh, five hours a month. We would save per individual with all the existing tool and jumping in, starting to kind of integrate that into the overall product.

I think we can move that from five hours dramatically more. Maybe it, maybe it's 10 or or 15. So, I think getting in there, seeing what it can do gives you the ability to a, you know, start saving more time right away or providing value to the end user, but then also helps you work with the end user to [01:01:00] define the roadmap.

And that's a whole nother topic, but I think really important, which is if people are interested in getting involved, you can do it within your own company, but you could also get on a customer advisory board or user research or just collaborate with some of these companies or, or products working in the space.

And we work really, really closely with the community and, you know, going back to getting it in their hands, getting it out there, it opens up that opportunity to collaborate, say, you know, how can we make this tool better for you?

And they get to see kind of how the tool's being created and get a little bit more exposure and then we can, you know, make a tool that is hopefully a little bit more applicable to them.

So, uh, so yeah, I, I'll just go back to saying it is still early days. We're really happy we move so fast cuz we're starting to learn. And get so much kind of valuable feedback that that's starting to queue up the roadmap for the next couple months. And then who knows for the next couple, couple years where, where it goes.

Evan Troxel: The opportunity to get involved in the creation of a [01:02:00] tool that helps yourself is like designing it from, with input from the inside to me is much different. It's a much different scenario than having somebody else from the outside who's not in a e c create a product, come at a e C with it and try to sell it to a e c. There's a totally different landscape of, of like solving this for, for us. By us, us being the community that you're talking about, I think is, is super valuable and for you to be so accessible and available and a wanting of that is, is a testament to the kind of company that you are. and and I think that, that, that should matter to architects and they should see that there's value in that collaboration and that partnership to make, make tools for our industry to make it better.

I think that that's something worth, worth repeating.

Scott Reynolds: And it always blows me [01:03:00] away. We'll, we'll jump on a call and one of the very first things we say is, okay, this tool is for you. How can we, uh, change the tool or, or better, uh, create this tool or, or, you know, uh, modify it to make your day easier. What exactly would you like to see? And, and don't sugarcoat it, you know, say, you know, and it doesn't need to be like, end result, but just talk to me through your pain points.

What are the existing pain points and which ones are worse than others? And the, the surprising part is, is the reaction to that question. And clearly, you know, they've a, never seen it before or b

rarely heard it. So there's a lot of shock when we first jump into these calls and it's like, whoa, like, You know, I've never been asked that before, but like, let me think out loud and I'll, I'll list these things and it's, it's so beneficial.

And, and that is the end result. Like the only ambition here is to make that tool as valuable and as helpful for you as the end user is, is possible. And the only way to do that, to keep your finger on the pulse of, of you know, what people want is just simply [01:04:00] ask them, what, what do you want? And it's so simple, but so few people do it.

It's, it's just kind of astounding to us. And it, you know, how simple of a process but valuable that, uh, that is.

Evan Troxel: Well, I appreciate your ambition. This has been a fantastic conversation. And is there anything else that, that you wanna put out there on this episode to point people toward, or any topics that we haven't quite gotten, uh, out in this conversation that you think are, are worth wrapping up with?

Scott Reynolds: Um, I think we covered all the, the major, uh, topics there. And I, I would just encourage people to, to, you know, get on there and, um, you know, reach out with feedback and just, just engagement no matter what component of, of the product or, or adjacent spaces. Like, we're always looking to iterate and improve the core product.

Co-pilot, of course, which just launched, but also like the, the diagrams we were talking about before or the code calculators and things like that we're, we're just constantly kind of shaping and improving it, but also looking in other spaces, other things we [01:05:00] might tackle, uh, in the next couple quarters.

So yeah, I would just highly encourage, you know, whether it's reaching out to us at UP codes or any of the companies in the software world. In ac it's a, you know, very small world. There's only, you know, a handful of companies working to make software for architects. So I think just getting involved, um, uh, connecting with them, speaking with them and, and just making it a much more.

Collaborative effort will, I think, help everybody in the space.

Evan Troxel: Great. Well, I appreciate the conversation today, Scott. This has been fantastic and, uh, I look forward to what you guys come up with next.

Scott Reynolds: Great. And, and so good to connect again and, um, looking forward to staying in touch.

Evan Troxel: Right. ​