The Real Reason I Changed the Name of Copilot CRM

Hey everyone, it's Mike Andes. And today on the podcast, I'm very excited because for the first time ever, I'm introducing some members of the leadership team at Copilot. And so I want to first off go over introductions. We're going to be talking about the recent rebrand from Copilot over to homeworks, what that all entails, and then also talking about exactly how we think software can solve many of the constraints that home service businesses have in sales, operations and admin. So if you read already read the copy and paste millionaire book, you already understand those are the three departments of every home service business. But today I want to dive deep into the problem space of why we think software can solve many of the constraints you're seeing in your business from those three different angles. But first, I want to introduce you to some very special people. Some of you might have remembered Josh from last Blue Collar summit. He spoke there and kind of told his story. But also today, Dan, he's our VP of engineering. And so I'll go around the horn, but Nathan is our VP of design. But if you could just each three of you kind of introduce yourself and just talk about what you've had in the past. We have a lot of CRM experience, Fuel operations.

Data visualization. So give you your background and then we'll jump into more homeworks related things. Go ahead, Dan, we'll start off with you.

All right, well, I'm coming in with about 20 years experience doing software development.

I think the first thing I ever did is help my brother build an e commerce website.

But yeah, I've had a long career. I ran a software agency for about 10 years, just kind of building software for small businesses.

And it was a lot of what we called field services, work mobile, phlebotomist, medical scheduling.

Home inspections. So it was a lot of orders coming in, need to go through different statuses, get completed, get assigned to somebody and then reporting off of all that. So I've been kind of living and breathing this type of software for a long time. But yeah, I had a little detour. I started building a business intelligence data visualization product which led to getting acquired into a company where I, where I met Nathan. So that was a bit of a turnaround. They were growing, doing a lot of exciting work, but they were running out of money, had a bit of an engineering fiasco with losing money, stability issues.

So that first year was really wild and it was really all about turning that around, cleaning that up, building a team around that sort of. That led to Another acquisition, a series of other kind of shuffles, and.

Really meeting some of my favorite co workers that I've ever worked with who were kind of reassembling here to continue on.

I think the unique thing about like the team currently as it stands is a lot of you all have worked together before in some way, shape or form, like Ford with Josh and Nathan, and years before that, Nathan and Dan. Then a lot of the engineering has worked together before.

Yeah.

And so super unique. And yeah, from the engineering side, over the past little bit, you've kind of assembled a lot of that original cohort back together. What's it like working with them again? And what level of like, trust in those team members do you have just kind of built up from those years of experience together?

Yeah, it's amazing. I mean, over. Over a, you know, 15, 20 year period, you. You kind of. Something with software is that you really learn who you can trust with certain types of problems. So when you hand someone a specific problem, are you going to be just constantly worried what they're going to break, what they're going to do? So I think there's kind of a mix of people's integrity, how they kind of communicate, how they work in general, but also do I really trust their mind with how they solve these types of problems. And I think what's amazing is, I mean, one of the people on our team I think I've worked with since 2009, and then a few of us, I think, have worked together like nine or 10 years. And one thing that's amazing is a lot of software has a lot of turnover, people coming and going, quitting, personality differences, whatever. But I think kind of what's been amazing that I've seen over my career is like, a lot of our teams stay together because it's working and it's going really well. So, you know, we don't have every single person that we've ever worked with, like, you know, that we've loved, but it's kind of amazing. I mean, actually, it's a lot of credit to Nathan. We love. Some of us just loved working together so much and it was working so well. We were really talking about, you know, what would it be like if we could ever be applying this somewhere, especially somewhere really fertile and like, you know, ready to. Ready to, I don't know, receive what.

We could exactly get in the band back together.

Yeah, it's funny you say that, that, that is, that is, that is a thing that we said in the years where we weren't working together. But I feel like that analogy of working with people, your collaborators, it really is like a band in a lot of ways. There's a lot of really talented musicians and sometimes the most talented people don't make the best album. So that thought of knowing who you can trust with what problem and even how they're gonna think about it, I know if I hand this to one person, they're gonna do it one way. If I hand it to another person, they're gonna solve it a little bit a different way. And there's a lot of time of getting that band to gel together. And so you can really speed up the way that you can start engaging with problems and getting to the real meat of what you're trying to get to. If you already have that familiarity. Like, we already know who's going to play the power chord, who's going to come in for the solo. Like, we've just done this together so long that you're like, you're like, yeah, like, we know, we know who's going to hit the three chords, we know who's going to hit the melody. And you can tell I'm straining my music analogy. But the, but the, yeah, it's great to get back to working with people. I could run through all the names, but like, it's been awesome to see that dream realized of like, kind of like work together and scatter to the winds and now actually have an opportunity to come back and build something we're really passionate about.

Well, very early on when I was recruiting Nathan, he said, I've got this dream and hear me out. And we talked about it for months.

Yeah.

He said, I've got this group of folks that are just incredibly talented and wise.

There's a lot of package recruits. It's like, if I come along.

I.

Was like, I believe you, I trust you.

And it's truthfully, because the people that we work with can do. I have so much belief in the front end developers and the designers we brought on Dan can speak to the back end folks, but they're the kind of folks that I don't have to know the specifics of the problem we're trying to solve. I'm like, if it has to be built on the web, I know they can do it. I know they can do it, and I know they can do it well. And I know that I can't deliver on the design promise I was telling you about. If I don't have those kind of folks, I'm sure we can make great music with lots of Musicians. I know these ones and I know we can make some great.

I think there was something else really special too. Just beyond the talent that we recruited. There was a really good core team with Steven Parker and a lot of the folks who've been here and Lindsay. That was one of the things that brought me to Copilot was just knowing there was really good bones. We just needed to bring in some.

Gray hair, slightly brutal bones.

There was a great foundation that we were building on top of. And the team that was, that was already here has a lot of like area specific knowledge. Has a lot of knowledge. If what they don't have like in a deep software expertise knowledge. They know the product, they know the people that they're serving. And sometimes that can actually outrun, you know, people who have like a bunch of product experience and like have been doing it for 20, 30 years. It's like, yeah, but do you know the problems that your users are having right now? And we really have a team who's very much steeped in that.

I know we kind of got off track. I was introducing Dan. Dan has introduced himself. Nathan, now that you've talked a little bit, give us a little bit of your background.

Yeah, I'm a band leader.

Did you.

Get your album today?

Yeah.

Background. I was a designer who couldn't get work as a designer and so I was doing freelance logos and that turned into we don't need business cards, we need a website. And so I was like, I got it. Okay, I gotta figure out how to do that. That seemed kind of interesting. Did that for the better part of like five, six years while working other gigs and then landed my first professional job at Sprinkler, joined the design and experience team as a front end developer. Forked off from that, that was an interesting band breakup and went with a design team there, started getting into design systems, bounced around a bit and landed a design systems role actually where me and Josh worked previously and came over from there when Josh presented the offer to me.

Very cool, Josh. Josh has already introduced himself to the audience, but can you give us a little bit of background?

Yeah, yeah.

And as really the first, again, gray haired individual coming into the team, but realistically bringing many of the talented people that are on the team today and giving a little more credibility on the technical side. And again, I've said this publicly on stage, but having the credibility of you behind what we were trying to do allowed us to reach out to all these talented people. And so I've said it before, but thank you so much. Each person, including Nathan and Dan, even last night, when we were talking around dinner, mentioned just your caliber, your leadership, and that's a huge reason they're here. And so I wanted to say thank you.

That means a lot.

But maybe give a bit of background and then we'll jump right in.

Well, thank you. That means a lot. So before copilot, I was at activecampaign, actually, of course, where I met Nathan. I was there for a few years. I was a group product manager there, kind of working across the entire business and some of the bigger problems they were trying to solve. Before that, I ran a business in Chicago for about 10 years, similar to Nathan, kind of in the agency space. So we're building custom web apps, ultimately built a web app in the recruitment tech space that was acquired by careerbuilder.com and so I worked there for a number of years, kind of integrating that software. So I spent 10 years in the agency side of the business, really learning how to grow a business and learned a lot, and then kind of brought that experience into my first kind of real product role at Career Builder, where I was a director for a number of years and just learned a lot about the trade, you know, of how to actually be a product person. You know, I'd always had, you know, business skills, but, like, actually learning the trade of product at Career Builder and then brought that into activecampaign, where I worked for a number of years and met some really incredible people, but then ultimately was recruited through a technical person you had here, and then been a copilot ever since. Also, I run a business in our town, Drift Salon with my wife. So really steeped in just small business and how to ultimately grow businesses. That I think has translated really well into copilot as well.

I want to go back to a couple moments, and this one, I was going to say this for later, and I was like, you know what? We'll do it live. So last night I was talking to Dan and I remembered something that I had totally forgotten about, and I wanted to bring it up and go over with you now. And that was.

When Dan was contracting at the beginning, kind of like getting involved with the team, seeing the issues. We started, we were in the middle of bughal, or kind of coming out of bughl, I would say, but still having a lot of problems from architecture. Back end was certainly our weak point. And I remember we were considering, like, we need a leader on the engineering technical front. And so we were looking at a few different candidates, Dan being one of them, contracting and when he came on, you're like, hey, go kick up some dirt. Go kick up some dust. Make up. I knew he collected. And so there was a couple initial conversations that were. It was pretty tense. And I think I talked about this with Dan last night. I really appreciated the conviction that he had on what he knew was true, to push that thing through and kick up some dirt. But I remember. I remember after the first one, you're.

Like, this is good.

The second one, we had a conversation and you're like, I don't know if this is going to work. I just don't know if it's gonna gel. I don't know if he's the right fit. I really appreciate all three of you. And I mentioned this individually. Nathan, too, like, your conviction in your individual expertise, whether it be design or product or engineering, to push and actually see things through the way you see it. And I was talking with Nathan last night, like, strong beliefs held loosely, but then being willing to stand up for it, defend it, push through it, and then be willing to also take the criticism back at you and change your beliefs. But I was just reminded of it last night, of that instance and the change that we've seen on the back end and the rewrite and everything that's changed, I believe is a product of the three of you and your leadership in your individual contributions to your individual design, product, and engineering side. But I wanted to go back to that moment because.

Did you remember that?

Of course.

I didn't remember until last night.

And you were like, this is great fodder for my content. This very challenging moment that we all experience together and we've grown.

I had enough challenging moments.

No, you know, I think the point you brought. I'm going to keep stretching this analogy. We could go to a sport, but I think hockey.

Yeah.

It really is a testament to the trust and the belief that you have in people, the people that you work with, that you can bring that full version of yourself and that full conviction. Because I think it can be really easy to be like. To just roll with whatever it is for Dan to come in and be like, I don't want to ruffle any feathers. It seems like they're going this way. I'll just do my little piece here. And there can be really talented teams that, like, they carton off. Like, here's my area of expertise. I just do my thing here, and that's great. And it doesn't. It doesn't become stronger than the sum of its parts. Like, this is very good. And this is very good, and this is very good, but they don't all mix well together. And so they just kind of operate in excellence by themselves. And I think it takes a lot of humanity and a lot of, like, willingness, like you said, to have a strong belief held loosely. Am I getting that right? To be able to present to Dan, like, I really don't think that's the best solution for the design problem. And for him to be able to be like, that's great, but, like, databases don't work like that. That's a nice picture you drew. But we have to find a middle ground here. And the ability to do that and to continually re. Engage with those challenges, I think, are what allows us to reach the full potential of all the talent we have for these different silos to kind of connect together and be able to tell a cohesive story across the product we're building.

Yeah, I think that there's a really. We talk about this a lot. A really healthy balance, and I think friction between those disciplines of product design and engineering is actually really good. It needs to be healthy. But, yeah, I think I put Dan in a really challenging position intentionally. And it was tough at first. And the way I saw Dan handle his business with grace and with his expertise, really. I think I remember after that second conversation, just seeing how he worked through and kind of healed some of those relationships and, you know, just really stepped up the plate. It was obvious that he was the guy. But, yeah, sorry I put you in that tough spot.

It was just getting to know Dan. I totally forgot about it. He's, like, such a nice guy. He would never do it.

I was like, go ahead.

And I don't think there's any name calling.

No, no, no.

Of course.

Of course.

Well, when we were talking about, like, this band and this kind of, like, this coming together of all these different people, I was just thinking. I was like, it's not that everyone agrees or it's people you really admire that actually represent a lot of skills you respect that aren't the same that you have. So knowing that, like, you know, that person can do this thing, and I think I came in feeling like, oh, Nathan, vouchsafe. And I come in, and I'm pushing on this thing. And I definitely remember the one, too, of, like, after, I think one meeting, Josh was like, no, this is exactly what we're doing.

Josh loves chum in the water. He's like, not bad.

And then after the second one, he's like, yeah, so about that.

I think the thing that I'm actually amazed by though is like all those team members that were on that call still with us today, still working with alongside and to be able to have the hard conversations. And obviously there was change that was required because we had gone through so much on the back end and there was so much frustration on my end bringing in Josh then. Josh doesn't have the technical chops to do what you've done or on the design side to be able to have those conversations but then still have those team members as contributing parts of the team now, I think speaks to how you handled it. Yeah, well.

And I think, I think there's this, you know, Ian mentioned, like, if we've been doing this for 10 plus years and some of us together for 10 plus years, you develop a. This is how we can do this. And this is what we know works. This is what we really know will be successful. And that's not always an exact prescribed play by play, but it's principles, it's guiding ideas, it's kind of. And you know how that works. And I think to some extent it's like so cool to get the band back together, but there's other things where it's like, if we're gonna do this, let's really do this and let's mean it. And I think, I think that was also a little bit of a moment of you're brand new, you don't know exactly how to build all these relationships. Like, yeah, should I just go with the flow of what's here? Should I insert the thing that I really believe in? I think that's always hard the first 90 days or whatever. Like, are you burning bridges? Are you building alliances? Like, what are you doing? And I think, I think it's messy. I think what was really cool is the way that Josh manages a team in. I think I've seen, I've seen heavy handed managers, but they're still just squashing the conflicts and just avoiding it though. And they'll leave a problem unsolved just.

Just to avoid the conflict.

Yeah, just to avoid the conflict. And Josh has this amazing way of kind of being like, hey, you said something that seems important. I think there's a disagreement here that's important. Let's figure that out. And I think just.

I think.

Encouraging us to find our way through it and not just, let's avoid squash, you know, whatever. So I think, I think that has to be messy a little bit and I think that has to be a little bit uncomfortable. But I don't know, I think we all could be doing other things. And if we're going to assemble this dream team and we're like, and there's this company that's just ripe for big change. Like, we're either gonna do this or not.

Like, I don't.

Didn't want to. I didn't want to watch another company just kind of. Yeah, you didn't want to be a conflict aversion. Just, like, not do it right.

And you said that at the time. You're like, I could do other stuff. Like, this would be great, but kind of like, I don't want to do. I don't want to do this. If it's like, Dan, go over there and you play with the engineering toys and we'll figure this out. Like, not an interesting opportunity. You're like, no, if we're going to do this, it means we're going to be not just competent in each of our areas. Areas, but competent, you know, like walking into the chaotic space that there is of, like, yeah, there's going to be this product requirement which doesn't quite match this design and doesn't quite match the engineering constraints. And, like, we're going to work through it together. We're not going to have, like, someone who won the. Who had the last word in the meeting just be like, well, I guess that's what we're doing. And no one evaluates it. Like, I think there is a ton of value in not. Not avoiding it or not even getting so good that you don't come to those points, but developing that. That competency of, like, how are we going to write this song together? And I think a lot of the. The friction that came out of that wasn't. It came from everyone trying to bring their best. But, you know, we had. We hadn't worked together for a while. And, like, I might start. I'm going to keep stretching this band analogy. Like, I started working on a song, but I'm going to write all the words first. I'm going to get down my lyrics. I like this piece. I like how this ties into here. And Dan's like, but we got to start with the chord progression. Like, let's start over here. And we were both trying to, like, grab the wheel a little bit and be like, this is how I'm used to doing this. And us trying to find the footing of like, all right. When we work together, how do we incorporate both of these ways? Because they're both valid ways to get to a correct solution and trying to bring both of those viewpoints all three of the viewpoints in product to get to the best solution. And I think we very much have developed those. The problems that would have, we would have gotten hung up on six months ago, we're flying through like literally yesterday in like a, hey, we gotta touch base. There's this legacy concern and there's this front end concern and how are we gonna all do this? And it was like, you know, 15 minutes going over it and it was like, yep, that was great. And I think you even called out, like, this is great. We just walked out all the solutions, talked about the possibilities and we picked, we decided on it, execute it, put a pin in, like, well, if we wanted to go that way, we'd do that. And like, that wouldn't have gone that way six months ago, nine months ago.

It's not even about being right too. Like, I come out of some meetings now or I'm like, I'm really saying to myself, I'm like, wow, like I came in, I thought it should be this. Nathan disagreed with me and he was right. And that was magic. Like, everything that just happened. Like, I'm so glad that we had. When you have, you know, four or five people in a meeting and they're all representing different disciplines and there's this little bit of disagreement, but there's so much respect now and the ability to kind of like figure out where to land. Like, okay, we've heard everybody, now we're choosing this path, but everyone, like, I think that's the beauty is when you can take in all the information, have all these disciplines represented. And then now we're gonna like, okay, let's go with this path. But we kind of know why we're doing that. Like, we're starting here and then we're going to move forward.

Yeah, I think it's really important to have really strong opinions from all the various disciplines. And it's a continuous thing, right? Yeah, it evolves as well. It's been so cool just to see how much it's evolved over the last couple of months where we can, like the exact same thing as you said, just quickly get in a room and have all of these really strong opinions, get to a unified decision. We haven't had a single moment where somebody's raising their hands. I don't agree with where this outcome. And that's. That's a hard thing to do in business, but it's really important. When I ran a business in Chicago for a number of years, I had partners that were actually very similar to like this trio Very different people with really, really strong opinions. And they were my close friends. People always say, you know, don't work with your friends, don't work with your partner. I work with, you know, run a business with my wife. I couldn't.

Right.

Yeah.

Okay.

Yeah. I couldn't disagree more, you know, and it's all about, you know, being able to work collectively through those things and. And have thick skin too, you know, because when people really hold on to tight beliefs too hard, that ends up hurting the business, you know?

Yeah.

I think after the Black Friday launch and our conversation there and now switching over to homeworks, I want to kind of fast forward to that moment more present day. But before we do that, I want to go back one more time, Josh, because you kind of joined when we were in the middle of Bug hell, where every couple weeks we're going down. Every single week there's incidents. And not to say that we are perfect by no means now, but certainly come a long ways because of the. The skill and talent, the people we brought on. But it's been about a year and a half since you've been full time. Over a year and a half since you started. Started working with us. Walk me through your evolution as you brought in more skilled team members and your role as a leader now that you have disciplines covered like design and engineering. Where at the beginning we did not.

Yeah.

And just where has your role changed in bringing these skilled people on over the past year and a half?

Yeah. So one of the things we talked about early on when I came on was having a really clear product vision. And that vision is still held true today. But the most important part is having a really reliable and stable code base. So really working to build the stability. And that's right when I came in is in the middle of bughal and we did not have a stable platform. And building a stable platform is a continuous effort. So as we started to bring in additional skilled people and get a handle on what exactly is that? This code base, what do we need to do to build it? We've been able to move slightly into the second phase of that, and that's being incrementally better and incrementally better than our competitors. So as we're building a feature, how can we get to table stakes? So we have the features and functions our customers expect, but how can actually be a little bit better than else in the market, but also incrementally better as a team? And that's one of the things that we've really, I think, started to get really good at is, you know, constant iteration, constant conversations about, like, how we can kind of work better. And so we've really seen the team evolve into, you know, a production machine. And the last phase of that really is being ultimately fundamentally different in the market. How can we be fundamentally different as a team on how we work together, which we're continuously seeing, but, you know, fundamentally different in the market. And how can we kind of infuse you and your knowledge and experience into the platform? So, you know, speaking to how that looks in the market, but also how we operate as a team, I think we really kind of root ourselves in that.

The team has grown relatively slowly, but that's also intentional. And as we've kind of brought in new pieces in one specific area, we've been able to kind of flourish in those areas. We made a big bet on the need for design. We have probably more designers compared to the engineering as far as the ratio than most teams. But one of the biggest challenges at Copal, we have a lot of features and functions, but a lot of times it's like spaghetti. You know, the user experience is really challenging. So one of the things we worked on early, Nathan, he really advocated for having several really experienced, solid designers so that we could design the product and get out ahead of engineering. And that's really, I think, starting to pay dividends because we have a lot of design work to do. So, yeah, I think just slowly starting to build that team, starting to kind of gel together and actually starting to deliver a solid code. It's been really rewarding.

Yeah. Really good experience.

Okay, so let's look now a little more forward thinking and think about the brand, changing the homeworks. So it was several months ago. We were like, hey, this, this co pilot thing is not going to work.

It was the day I started.

I was like, before I take the design job, I was like, can we talk about the name? I was like, kind of a little. There's other pilots.

Yeah, yeah.

Actually, I didn't take a job at a company like as head of engineering because the name, they refused to change their brand. It was a bad brand. Yeah, it was a known bad brand. And I was just like, can you talk to like a brand, like. And they were like, no, it's perfect.

And I was like, all right, this.

Is not my area.

But I was like, again, it's one.

Of those things like, if I'm going to do this, I don't want.

Yeah, it was one of the first questions. I was like, Josh, So like, I'm interested. I go the name. He's like, mike's totally open to having a conversation about how we think about the brand. You know, better position. I was like, oh, great, that works for me.

As long as he's good enough. Yeah.

So maybe from leading from that side of things, in terms of the design and the branding, where was your mind when you're like, there's obviously a problem with this, but also then knowing that that change was going to be fundamentally changing product, it was going to change engineering, it was going to require a lot of work, and there's so many other things we have to do in the platform. And so walk me through that process. I know you kind of championed and led that side of the rebrand and bringing on the designers and the brand experts. So kind of walk me through that process in your mind.

Yeah. So I think from a high level, like, in the past years, since this whole AI thing has kind of taken over a lot of. A lot of everything. Copilot was a very, like, loaded namespace. And we realized that that may not be the right word to match the value add that we're providing for our customers. And I think even specifically in our space, there may be a poor association with like, like, a mismatch of like, hey, isn't AI really cool with what we're kind of offering in terms of what we're solving? So it didn't seem like there was value in being like, oh, happy accident. We might get some familiarity with AI that would be beneficial. So I think we knew that as a general direction that, like, we wanted to move to something that spoke more directly to what we were offering. And we also knew that it wasn't critical at the moment. Like, we had a lot of big problems to solve. We had engineering stability to solve. We had to get a handle on where is the biggest value for our customer base. And this was going to be an opportunity for us to correct this branding. But I think as we worked through it, we kind of, like, partnered and we're like, we would really like this to not just be a coat of paint. It's a fresh set of colors and it's a new mark, and that's great. But how can we pair that with something that we're really, you know, proud to offer? You know, you spoke about joining during BUGH and the challenges that was for you stepping into the. The software space. And we really wanted, when we unveiled this new name, to have a really positive association with, like, we really feel proud about what we've stabilized, what we've built and that this for anybody who was joining new, that they kind of would start the dream here, right that they wouldn't have to. They would inherit all the benefit of what we learned going through bughow and getting to a stable platform. But it would kind of be a fresh start, a page turn for us to put our stamp on this set of features. We think is. Is equivalent to other offerings in the market and something that we're starting to differentiate ourselves with. So I think it was about, I guess I'm trying to flash forward to when people are going to hear this like four or five months ago now maybe, maybe, maybe a little more. We got hooked up with one of the designers on our team, put me in contact with a local designer and we, we started working through a bunch of concepts that we felt were.

Would better embody what we were trying to provide. And the name, I think we were batting around names like well before we started on this.

I think the name kind of stuck. But it was homework. I think that was the initial part and people liked it. But there was like it's going to be a backpack and we know it likes homework.

Bad connotations.

So. So like it was there all failed high school.

So like it was like kind of halfway there. We had a bunch of like, kind of like half started ideas and.

Working with Brian was, was, was great that we, we got a chance to like bring all of our half cobbled ideas together and he really made it shine. And, and Josh found the S at the end of the name which I think really made that single. So yeah, we're really proud of the mark and the opportunity for it to be not just a new brand and some new swag for us to wear. Although I am excited about the new hats, you heard it on camera, which means Mike's gonna make some hats. But I'm really excited about the point to which we brought the product that we're really happy to put our stamp on it and really happy about it. It not being a finish but a start of a new. A new race, a new album. If I'm going to keep stretching that, like a continuation of that story, but a chance to turn the page and really reintroduce that product.

I think the brand too, given the fact that it's a chain, it has the links of sales, operations, admin in the logo, it ties in well with not only our ideal customer and the people we're serving, which is homeworks, but also I think fundamental to the changes we made over the past year. In the business, which is we need like a chain to have the dependability and reliability that when you need it, it's there and it works. And so many of the conversations we've had with our members throughout Buckhow and throughout past year and a half at the copilot is I just want it to work like the way that is supposed to work. I just want to work exactly like that. And so I think that was where it was kind of a double sided meaning for me. It was like, yes, you can grow without breaking, but also we will grow this business. Yes, for our members without breaking. And I think that's fundamentally like it's been two years since, you know, basically Black Friday 2023 to Black Friday 2025 actually. Okay, you go, go use this. And this tool will not break. And I think again, it's the links of all the team members we've compiled over the past year brought together that I can even have the confidence to be like, okay, now I can put my brand back on this and say, go do this because it's going to be the best thing for your business. And so when we look at sales operations, admin, I want to go a little more future casting and think about, we think about sales. I need more leads, I need to get more customers. How can software solve this problem? And I was talking with this with Nathan last night and he was asking me kind of getting into software and I was like, it's the most scalable way to help as many people as possible. Because assuming that we have a good backend, we can scale this to tens of thousands of business owners that I'm helping. Instead of traveling one by one to a turnaround or even writing a book where they have to find the problem, diagnose, they have to then prescribe the solution and then they have to go execute versus all three of those things can be done with a button click. I say, okay, I see that you have a problem with your profitability, I see that your pricing is off. Here are the people you should raise prices. Click this button and we'll do it on the back end. And so I see software as a much more scalable form of helping the owners that I care a lot about. But let's talk about like zero in on some of these things that we see as problems in home services and in sales operations, admin. So sales getting more leads. I know that one of the things that we've talked a lot about is instant quotes. The ability for someone to instantly get a quote on someone's website and immediately put their card on file. It's on the back end, it's accepted. And I think one of the things I value a lot about Nathan is your perspective on this should just be done for you. You should not have to put this together and pull this. I think it's very evident in the unscheduled work recently. So I want to talk about unscheduled work in a second. But first let's talk about sales and because I need to sail before I go to unscheduled work. So when I talk about sales. Where do you see software as you've seen over the past 612 months, working inside the platform as our opportunity with instant quotes and other aspects of the design to make this a more seamless transition from a lead to a customer.

That's a great question. I know you have some thoughts on this, so I want to rebound off of you because I think you, you've highlighted with, with some of the, I think some of the software you've used in the other, in other spaces of like seeing the value of how extensive that like lead management and how awesome that kind of like mobile first version of that can be.

Yeah. In the sales domain it's all about speed. Right. It's all about how quickly you can get leads in the door, but also like how high quality those leads are. So that's one of the reasons with the instant quote forms being able to grab a credit card as they're filling out that lead, it means it's going to be a much more high quality lead. You know, they're signaling high intent. So it's all about reducing friction in those things flows, getting as high volume as you possibly can, but also making sure that volume is really high quality.

Yeah, absolutely. And I think we want to build a platform that doesn't mandate that you only have, that requires that you have high leads, that highest quality lead, because you might be at a point where wells run dry. We'll take names and numbers and we'll start working hard. But we wanted to build a platform that met you where you were at. If you're mostly booked up. It's like we just want high quality leads. So we need to build a platform that allows you to be like, hey, to get, to get the quote. Like you're going to give us a card number, you're going to tell us what services you want and we're basically going to be at a completed estimate ready to schedule for you. But if you need a wider expansive, you know, like we're trying to fish. We're trying to fill up all of these boats like we can. We, we're going to build a feature set that allows you to like target specific areas, target specific items or services, you know, like whatever meets the needs of what your inbound looks like. And trying to do that in a way where the platform is integrating the thing that you're collecting in terms of leads. So you're not going, great, I got this customer and they want these things. And now someone in my office has to go take that name, add it as a customer. They'll match this with an item. It's all tied in as part of one cohesive link unto another. So all that work is just flowing directly into the system. So you can get, if you have a high quality lead, you're basically like a scheduling point. You can skip the estimate that can go on the books tomorrow. Or it could be someone where like, yep, I'm going to work these leads. And this, this comes right in and it's basically the shape of an estimate. I can send it out and follow up tomorrow. But it shouldn't be incumbent upon you. You shouldn't even have to press the button, Mike. It should, mostly if you wanted to, it should just turn into the thing that should be in the system and you can tailor as your, as your workflow needs. But really solving those problems where your business is and allowing you the flexibility to pick and choose which, which of those is the right solution.

Yeah. Something that strikes me about what you just said, like it's already ready to go. We've spent a lot of time talking about what's the best way to represent your offerings, what services you offer, what pricing you offer, obviously without overcomplicating it. We've also talked about do we need satellite based square footage analysis or can it be small, medium, large? We're hovering around all these things to try to figure out what's the best way to represent the pricing for that yard or for that home. And then how does that come through where someone doesn't have to spend time copy and pasting? Because a software can say, we have lead forms, it's another thing. And we have estimates, it's another thing for those things to all work together. And I think that's just a big part of all of our discussions is what's the thread through all of this and how does that impact conversion? How does that impact the experience? How does that impact the time for the office staff or whatever?

Yeah. To that impact understanding conversion rate. So understanding the data in that Entire journey flow from when it's a kernel of opportunity into an actual customer. And being able to see where there's drop off is something that I think we're gonna invest quite a bit in, you know, so that you can kind of tweak and tune your messaging.

Yeah. Like for us at Augusta, for example, it was almost a forcing function because every single time someone calls and asks for an estimate or submits an estimate request form that doesn't have instant pricing, immediately, there's a cost to the business. And this is where I think software wins in so many cases. That might cost you a half of a penny in terms of processing power to submit an instant quote form. Get it into stripe, that card information goes into your platform, creates an estimate. It's already done for you versus in the past if I had a 30% close ratio, I mean 7 out of 10 estimates that I do all this work for don't result in any revenue. And so now there's actually a threefold cost of any sold job because of all the admin time that went into jobs that weren't ever accepted and the tire kickers and the people that are lower priced. And so I think one element of instant pricing is it needs to be a simple service. It needs to be something that is small, medium and large or buy square footage. There's a certain constraint to that for those that have project jobs. And one thing that Dan's been digging a lot into recently and as we look into 2026, that we look to solve is the estimator dilemma. And that is I get to a job site, I need to be able to build out this estimate. And this is where the price book starts to really start forming. Talk me through what you saw as you from kind of outside home services at the beginning as you dug into the price list. Because our price book, one thing I found really interesting, it was almost a real joy to see all three of you kind of as you learn the home service is take your discipline and what you're so skilled at and like, oh, like I can solve this problem in home services very easily because I have this skill that I can match very well with it. So I was really interested to see how you came up with even the pricing models. Like here's the different ways to do pricing. I think it was like five or six of different ways. But walk me through price book and where we're going with it and what we're trying to solve in terms of estimators.

Yeah, yeah. And it's still. And we're still finding exactly where it's going to end up. But it was a really fun journey because you have.

You don't want to come in and just dictate like what the software is going to be based off of what it's already there or off of one conversation. So I think what was really interesting there is, we came in and there was. Nathan's team was doing user research and it was really. This is actually something I love that Copilot's doing in general is asking customers, telling us, show us how you do this, how does this work today? And I remember sitting down and someone showing us the spreadsheet that showed, I don't know how many entries. It was 100 entries of different pricing at different levels. And we were talking just about lawn mowing. So you're looking and it's like, okay, this price and then it's this price and then it's this price. But there's, I don't know, 100 different price points of different things. And sometimes you could just say, okay, let's just model that exactly in software. Let's just directly let somebody enter in a million things. But then the question is, well, where did, how did they make that spreadsheet? Like, what was behind that? And so that led to all these other follow up conversations and then you and I talking, saying, well, okay, why is there different pricing at different level? Why isn't it just square feet times dollars and like, why would I need this thing? And that led into just learning so.

Much about the car sitting in the backyard. All of a sudden it's a 45 degree angle, right?

So yeah, then it's like, okay, there's all these complexities that maybe only an estimator could figure out, like the shape of the yard and do we want to try to model all of that in software? So I think that's another big thing with software is do you try to model the world. Exactly. Or do you try to model just enough of the world to really help you do your job? And it can. It's okay that it's a cartoon and it's not the like pixel perfect. You know, it's a high fidelity, it's.

Like a nice 3D rendered cartoon. It's like K Pop Demon Hunters style. Like it's a high fidelity cartoon.

Yeah. So I mean, so something that just got me really excited is, you know, you, you really breaking that down for us. And I think that's another wonderful thing about, you know, an owner of a company who knows the business and Isn't just this kind of disconnected leader, you were able to dive in and say, well, yeah, you switched to a different mower at a different yard size. And there's just this. The scale of that.

When I saw their graph dropped, I'm.

Like, no, don't do that.

Don't lower your price because you got a bigger mower, Right?

So then we're starting to say, okay, how do we accurately measure the efficiencies of moving to a bigger mower or a more efficient mower? And so you could say, all right, you're doing a push mower. And then at this point, you switch to the. You switch to this more efficient mower, and you could technically, one square foot higher yard. You're suddenly, you know, doing it in half the time that you were, you know, so it's like tax brackets and anything else. You don't actually. Like, you don't want to be like, I can't make a dollar more, because.

So, yeah, you're like, no. No one would ever charge less for, like, a slightly. So we're just trying to figure out what's a good representation of the world and how does that translate into software in the end, we're still having that conversation.

Absolutely.

And that's only one service, you know. Right. Because, like, that's. You could create a whole algorithm around mowing. It's like, well, then my plumbing service, my H vac, my painting.

Right. And that was the next question, too. Like, does that exact, like, yard size point. Is that the same for something?

Is the shape of it the same? Yeah.

And you said, no, it doesn't. So then we're trying to think, okay, we have to make sure we're not coding ourselves into a corner or forcing people into software that doesn't reflect their business. We're also trying to avoid a scenario where someone has to go spend a bunch of time.

Exactly.

Creating these spreadsheets. Usually, if someone's telling us their user story, and they're like, yeah, and then I spend three hours tracking. I'm tracking my unscheduled work over in the spreadsheet. Right. So the segue into that we did. We're like, okay, well, what happened there? Why did our software let you down? Technically, you can do estimates. Technically you can do these quotes.

But.

But why are you spending all this time trying to model all of your pricing somewhere else? And then someone has to manually plug that in. And so, yeah, that was just an exciting process. I think we now understand at least that one.

We understand that slice very well. Right. Like I think we have that slice very well covered and I think, you know, like you kind of brought up like two big things at the same time where you're a little pump fake, where you talk about estimators dilemma and then we talked about some of the price book challenges, but much like we talked about with teams and areas like these big problems, they're intertwined, right? Like there's a challenge right now in the software for an estimator where they know that what they're selling internally is composed of many, you know, like many sub pieces that have their own price. Like some of them are priced simply. It's like I have a quantity and I have this. Some of these are priced very complexly because they're labor plus maintenance over some kind of scale. And sometimes there's like a variance of like how many times are you doing this service recurrence notion. But our software right now kind of forces you down a path of like you can show your end customer everything or you can collapse it into like one thing and there's trade offs. Like do you show everything that goes into making the cake or do you like collapse all that but then you lose the granularity of like, but I know how much each of these prices or I don't want to do the math on a spreadsheet and then collapse it down into one number that's one off for this job. And so we realized to do a good job at solving that challenge for an estimator required us to engage with, all right, what are the challenges for pricing each of these smaller pieces? So we're engaged in trying to solve both of those. And both of those are problems that an estimator has when they go out to have a meeting. But it's also a problem connected to the instant quote stuff that we talked about of like, well, if, if it's not a bespoke problem, like all the things that go into like what a lawnmower costs depending on size and scale, you can tie that to your inbound, right? If you did all the work to model all of that, it can run in the background for you and generate leads. So I think trying to see how these workflows are all interconnected has been a really a guiding light of not getting too lost in the weeds of like finding the perfect algorithm to model this thing and understanding like, yes, we need to understand all the inputs so that we can distill it into the optimal user experience for what, what someone who's actually engaging with modeling of prices when they're doing estimate work when they're, when they're charging, when they're trying to set up a form.

Yeah. And so like looking at a project instead of just being like, okay, this is going to cost $1,200 for this, you know, project now, it'd be a function of being able to add, okay, it's going to take five budget hours, it's going to take three yards of material, it's going to take two yards of debris, and I'm going to charge a dump fee. And now those components of the recipe being visible to us on the back end, invisible to the customer.

Exactly. And finding a way for you to feel like that work that you did to spec out that project, if it's a project you do frequently and the numbers kind of go up and down for you to like, for us to pull you in to be like, it's good to model it this way instead of it collapsing into a number, because you can save this and use it again and fine tune these things and let the software take some of that burden off of you. And it's been very important for us to understand how connected these are, even the value of saving it. But also seeing are your budget hours that you're estimating lining up with what you actually put on the visit, what you actually charge to your customers. You had kind of spoken early about the vision for starting to invest in reporting and for us to be able to give feedback to our customers, like, how well is this going? We need to draw this steel thread from. What did you, what were you pricing this at? What did you put on your estimate then? What was the actual amount that you charged? How much did your, did your folks use in terms of budgeted hours on the actual job site? Like, how many hours did they log in field force and for. It's great for us to give those tools, but you're, it's great tools that you might be flying blind with if you can't step back and go, oh, all of the moes this month, we came in, you know, 10% budgeted hours over. We need to adjust or we need to like charge more for this. It's actionable information and we can only get to that accurate. Look at how it's going if we've given you the tools to accurately log those things. Right. If it's, if it's a collapsing in the price book and like, you can't accurately model, so you can't share an accurate estimate because it's, it's limited by internal, external well, then what we'd be measuring would be a really poor approximation of what actually happens. So a lot of this investment into the connectivity of, like, all of these sales, operations, admin and those being able to talk to each other really set us up for being able to step back and go, how are each of these functions working for your business and how are they connected?

Right. So we talk about sales getting the work. I want to talk about a little more operations doing the work and admin getting paid for the work. And I think that when I see what we've done recently with the wait list, I think it was one of probably the most requested thing we add to the software for the past year and a half. And we just had to focus first on dependability and reliability. Now we have a wait list. We obviously have iterations to improve on that in the future. However, as it currently stands, a wait list is simply there in order to be. The job is accepted. I don't know exactly where I went on the schedule, but I've got to put it somewhere so I can put it on the wait list. And now it is able to present, hey, you're coming to the end of the range of time that you said we were going to put you on the schedule, and it would alert us and notify us. I understand the wait list, when we were building this out, when was the notion for you, Nathan? Or if it was elsewhere, where there's a missing gap between, I have an accepted job and I want to put it on the schedule, and there's a wait list, but there's something in between. What was that and what problem were you trying to solve? Because in my mind, I just simply go to my estimates, I look what's accepted, I filter down, I click in and I say, okay, I'm gonna schedule that. And I pull my calendar and I just find where to go. What was the problem you were trying to solve between Waitlist and the schedule and accepted job?

Yeah, yeah, absolutely. I mean, to rewind. We were asked for Waitlist. It was number one. And what. Whatever tool we were using at the time to track those requests. And the immediate challenge was everyone came into that call like, let's talk about Waitlist. And we heard kind of two things, but, like, a bunch of different things. Like, no one. No one was. They were all saying wait list. And people were pointing at different things. Some people were pointing at what we delivered as Waitlist of, like, I have something. I've created an event very, very frequently, a visit, and I don't know when it's going to land. I might know when it's Dubai, but I just need to put it somewhere it shouldn't go on the schedule. I just need to put it somewhere. Great. That's the wait list that's available for you right now. Probably by the time you're watching this, it's available for multi step programming.

There was this other real problem that often was referred to as a waitlist, was basically tracking work that had been accepted but had not been scheduled. It was unscheduled work. And to your point, when I think I started talking about this, we heard from some people internally, some people externally who spoke about like that's not really a problem. Like you said, I just go to my estimates, I filter down for approved and then I see that list. I usually do a date filter because pretty much everything's been scheduled that's you know, a week or more old. And then I just walk through each estimate, I click through the estimate, I go look at the line items and I see if there's a visit, connect to it. And that's true, you can do that. Like that is exactly how you would have had to deal with dealing, how you would have had to deal with scheduling.

And I think if we stopped there and we just did that, everyone would be happy.

Sure.

Yeah.

And this is when, when, when unscheduled workers were presented to me, I'm like, what is this? Yeah, because this is where we come back to like fundamentally different is like there was a problem there we were, no one's actually solved this. Like I look recently for a couple weeks is how everyone does it. The way we talk about, which is either I get a notification, email, text message or an alert saying this estimate was accepted, go put on the schedule.

Yep.

But there's this gap and it came as a result of talking to members. And be like, some people use a wait list and they need to put it on the range, others will just throw it on the schedule. I'll get to it sometime.

People have like a specific spreadsheet, they have whole like metadata.

This is another spreadsheet thing where we were interviewing someone and they're like, yeah, I put it all in the spreadsheet once it's accepted and then I have this whole system and you can see these very beautiful, savvy people. Yeah, these very smart people who see the need to do this because they don't want those things to fall through the cracks and they could try to do it that method. But that's kind of a loose approximation of like, well, the last week accepted. But some people were meticulously tracking this. And once you see people building their own systems like that, some people were.

Doing it in the system. Some people were like, I use a day like Saturday, December 9th. Like, they're like, that's my. That was effectively their unscheduled customer. They're like, we just. We make sure it gets off the estimate. So we just put it here. And this is our. This day in the calendar represents our inbox, like our holding ground for things to be scheduled. I think fundamentally, like, there was a gap to us between the workflow ending for estimate. Right. Like you've presented, you had the conversation with your potential customer, it's gotten approved, the train has reached the station on the end of the estimate journey. But the next step in our software was like, it's on the schedule. Right. Like, it exists on your calendar. You can dispatch from there a lot of really valuable pieces. But there was a gap in between there where you have to do the function of, I have work, but it is unscheduled and I need to resolve that problem. It's almost like a new inbox. And that's where unscheduled work came from. So having a view that is doing the heavy lifting for you of like, we're going to filter down your estimates. It's just going to be the ones that are approved and only the ones that are approved that you haven't already scheduled. So this is your inbox of work that you have to schedule something for and allowing you to get a valence into that of like, by estimate, by customer, by property. So maybe you sent out three estimates to the same customer. A little back and forth. You can still, you can, you can use our new workflow to collapse those into a single visit if that's more optimal. And some of the stuff that we know is part of that, that challenge is right now, it's being collected. That's an awesome step forward. What you can't do yet is you can't see how it relates to existing routes, to existing recurring work budget hours scheduled. Yeah, exactly. And so this is really just the first step in building out a competency of like, to put this on here. It's great that I have a holding price for it, but before I can add this new recurring lawn, I need to evaluate where do I have capacity in my routes, where can it fit in geographically? And that's all stuff that we're looking into to how can we continue to engage with building or closing the gap between the Estimate is complete to this is actually on a schedule and I trust it.

And even when we look at the systems of the book where it's built to lead, that's the goal for the system is build this in a way where everyone else can run the sales operation admin without me being there. And when I hear spreadsheet and I hear, you know, very competent people building cool spreadsheets, I think owner stuck in business. Right. No one else is going to be able to understand that granularity and then first off, be able to take the estimate, be like, okay, put it on my fancy spreadsheet and then figure out where to put it.

Yeah.

And so I think we've solved the first problem which is okay, if I am out of town and I need. I have eight estimates. I walked in on Monday morning and I tell my office and my admin, hey, go and schedule the jobs.

Yeah.

Right now there's a bundled term of open up the estimates page, filter it down by date, figure out, click into each estimate, go to each line item and then from each line item pull up a different screen with your schedule and figure out where it fits. And so I think the thing that really made it the most simple for me when you said is now you tell them to go to undischeduled work and from that page you put it on the wait list or the schedule. From one page you can have your.

Intern do it today. You do not have to teach them the historical workflow. And you said today, like today they can do that. Like today in time they can't. But by the time they're watching this, you can go tell someone who has no experience in copilot software and you can just land them on this page and be like, just two actions. Like you can add it to a.

Schedule or add it to the waitlist and future state. Because I think some people will see waitlist cool and obvious unscheduled work. Not really understand what that's all about because I do the scheduling and I have this fancy spread. Cool. I think the part that you spoke to there is the future of unscheduled work. And that is we solved getting on the schedule or getting on the wait list, but we didn't actually schedule figure out when should it be on the schedule. That's very important.

Yeah.

Am I booked out five weeks? Which day of the week should it be on? Because on a recurring route. And so that's certainly something future state we're looking at for recurrence as well as project based.

Yeah, I mean like, to your point of like trying to stay in the problem space, we have given you a new set of tools to deal with, like, to accurately gather. Okay, here's the problem. And that's a huge step forward of like, you can, you can bring someone in today and just be like, just work through this, just schedule these things. It's necessary, but it's not sufficient. There's all those other things of like, to get this on the schedule, I need to know what my routes are, I need to know what the recurrences are, I need to know how close these things are or who's at capacity or who's available to work this week. And all of those things are things we understand as part of this problem space and as we're building out more competency in this area, we're going to be bringing those experiences in and hopefully taking a lot of the heavy lifting that some other areas that the schedule page, the dispatch page that you have to go to to get a look at those things, that it can be a little more streamlined if that page doesn't have to be doing all of that work.

Yeah, I think in the ideal situation, when we think about built to leave, building the business to be able to run without you, where you don't have to work 80 hours a week in it, and you can build the business without breaking in so many other areas and facets of life. I think about all the things we talk about in terms like instant quotes. The job comes in estimates accepted, cards on file. That was five steps in the past that I had to figure out as the owner, train someone as an admin person, and three out of ten I'm going to get accepted, which means the other seven, I still have to go visit them, talk to them, have an estimate, or go drive to their property, spend the gas, the fuel, the equipment to go, you know, drop an estimate, do a design. We solve, that estimate is accepted now. Now I need to teach an admin on how to do scheduling, figure out filtering, go in this spot, then you pull it over here. Here's how your dispatch board works. And I think we've solved that problem. I think going forward though, the big unlock is going to be that third step, which is I can take you from job accepted to on the schedule at the appropriate time without anything in between. That's where I look at software and say, we solved 12 steps. Then the past was an admin person, the owner get involved, the estimator got involved. The project manager had to figure out, when can we fit this on the schedule. And that's something I think that is going to be super valuable. Service business owners.

Yeah, absolutely. And when we're very interested. I think this is a good example of where the problem that you're trying to engage with requires you to kind of look at multiple things at once. Like, I can look at my inbox of unscheduled work. That's great, that's doing seven steps for me. But I also need to look at routing. I also need to look at the budgeted hours and those constraints for this week. And currently the platform, like most platforms, requires you to like get into this multi tab workflow. You're like, I get one view here, tab over here. Maybe you're doing window painting and, you know, splitting your screen. We really think there is a lot of value in being able to see multiple slices at the same time. So a lot of the design and experience work that we're looking into in 2026 is how can we introduce the ability to like see a slice of one thing and the context of another thing so you can solve your problem without having to leave the context you're in.

I want to step back for a moment. As we wrap up, I want to spend some time on the engineering side. I think mostly because that's been such the deficit in the past in the area that I personally could not really say go join copilot is because I did not have that skill and I did not have that competency in that area of the business was weak. When you hear all these things that we talk about from the engineer, you're. I know you're connecting things already and you're like, well, I could do this. So when you think about that and like how fast Nathan or I or Josh from a product perspective and feature set are thinking into the future, what are some of the limitations you think of from an engineering perspective that even in the future is something that you're like, we're going to have to solve these problems to do what we're talking about here.

Yeah, I mean, I often think of engineering's job is to sort of be transparent in that way, because if there's bugs, if things are going down, everyone's so aware of your hosting provider, your.

Database, clear what the problem is.

Yeah, well, and like you don't want those to be common names that your customers are hearing because that means the thing broke.

AWS is down again, right?

AWS East.

So it's like actually good design can be this way too. It's like you want a Lot of it to be transparent and just to feel invisible to you. I think engineering should be that way too. You shouldn't be thinking that much about how fast a website is because it's working. Like you click and then the thing happens. So you only start thinking about speed and performance a lot of time when. And it's so slow that you're waiting. So I think when I hear these things, I also spend a lot of time with small businesses. So for me it's that end user empathy and it's that excitement about seeing these things happen and seeing someone who's using the software, getting to experience that that gets me excited. So I want the engineering setup to be able to move as fast as those decisions. So there's a lot of nuance in what we're talking about of how many clicks does someone have to do to see the budgeted hours to whatever to keep building their routes. So we're sitting in those calls and we're getting excited about how to solve that. And there's a lot of nuance to those conversations. My goal is as soon as that decision is made to have the right frameworks in place that we can start breaking ground on that tomorrow. And that's going to get done as fast as we can make those decisions. So that's what I'm thinking with all of this is how are we aligning the back end, the database and the frameworks? I think really importantly, and this is the thing that it's like it's hard to speak to without getting really technical. I want those frameworks to be rock solid. I want all the tools and materials that are kind of going into this website to be set up in a way that we can just, we can rearrange the Legos. And now it does what Nathan, what we're all deciding in these conversations, like Nathan's team, is they're imagining a beautiful UX of a user experience with these things. I just want to be able to have that go in place. So I think everything I'm doing is to try to meet that end. And I think that's why it's really important to have owners involved, product involved, designers involved, and have engineering be present for all that. Because we're getting excited about seeing everything flow together into that.

Yeah. And to tap into that. Dan has been such an advocate for pushing to have engineering involved in those conversations early. And it's such a refreshing and challenging at times to bring in the technical concern at that time. But we really benefit from that. I think that's A lot of getting good at that chaos, getting good at working together, because it allows engineering to not be the last one to get the handoff where it's like, all right, product has decided on this design, has this beautiful vision. Go ahead, go let it rip. Good luck. And allowing them to be involved early and often, I think, gives Dan and his team the capacity to get out ahead of that work and also get out ahead of, like, building good foundational patterns, not just supporting the feature that we're talking about, but like, okay, we might be able to support this one, but if they're going to keep asking for stuff like this, it's going to mean an investment in this area or this feature of this service. And most exciting for me is there have been a lot of times where we come and do some initial exploration and for whatever reason, whether it's, you know, something we heard in passing or read on an old Slack message, but we will be operating under a certain set of constraints that we understand as this is a technical constraint. And more than once, more than 10 times, Dan has been like, yeah, that's not a constraint. Like, we can just fix that. And it's like, oh, because it'll usually come out of like, why are we doing.

Doing this? And then this.

And we're like, oh, because. Because you can't do that. Like the engineer. And he's like, no, I'm speaking for engineering. You can do that. Like, you don't need to do it that way.

I'm like, oh, to some extent, that was a wait list. I remember. I mean, early on. I think really early on, we had a wait list conversation. And it. I think you said, like, I think you.

There were some constraints around events and columns and dates.

It was like, we need to build this wait list thing. And it sounded really complicated. And we were looking at all these different screens, and I think it sort of boiled down to some. Someone saying, well, there's estimate line items that fall through the cracks. And I think that was, I think, where some early things came in of like, well, what if we just showed you the estimate line items that aren't on a thing? Like, some things that can sound really big, like you can actually have an engineer show up. I mean, not all engineers can have that conversation, but, like, we're trying to negotiate that scope. Well, what if we just, like, showed you a filter on the estimate line items? You know, And I think, same thing with the idea of the actual wait list. It's really nice to be able to have a conversation of, okay, Is a wait list item a new thing? Is it just a regular event? Is it not? You know, and again, this is a group of people all coming together and kind of deciding what is a wait list thing. And I think it kind of boiled down to, well, it's everything that an event is or a visit.

It doesn't schedule yet.

It just doesn't have a date. And then I think they're like, well, we just thought, you can't do that. You can't have. And so I think there's a really good negotiation of scope there that I think if you're working only design or only engineering or only product. Right. Or only product, or if you're not informed by customers, we can also make a lot of assumptions. So I think that's one of the other things. I really. I've never seen a company do this in the way that Copilot does these, you know, customer meetings where we present and even float ideas that some things we've already built, some things that are halfway built, some things that are up and coming and we see what they say. And I just love seeing, you know, Josh has facilitated so much with that process.

Anyway.

Yeah, I believe in engineering being very engaged with all that so that we can hear where Nathan's, you know, we see where Nathan's throwing the ball and we're trying to run, you know, to be there or vice versa. I don't know how to how that analogy works, but really trying to make it so you can tunnel and kind of have everything meet. And getting early in on those conversations. Sometimes we don't even know the solution yet. But now everyone's wheels are turning and you might be mulling over something for three months before we actually start breaking ground on it.

And even earlier this year, we really focused a lot on the customer portal and how payments were being handled. Obviously a very severe. From a security perspective, from a sensitive position, Payments invoices estimates how the customer is seeing our customers and their business waitlisted and unscheduled work is actually the first foray into the actual CRM where our business owners, their admin staff are actively inside that desktop version every day. We've done the Fieldforce app for the field technicians, but the actual CRM, I was thinking this morning while I was working out, I was thinking about, like over the past couple years and where we're at, and I was like. Because something Dan said early on when he was coming on was like, I want to be able to build these things as fast as you think of them. And so I'm like, well, where are we at in that, in that timeline? And so I thought, well, realistically I've looked over the last couple of years since the copilot bug, hell is, we were clearing the highway, we got to get the houses out of the way, we had to get the mountains out of the way, the rocks. We had to build some tunnels. We like make it so you could get on this thing and reliably get to your destination. I think 2026, after our conversations the other day, and from the engineering perspective and the rebuild that we are really trying to do, switching over to react from PHP and what this is the start of is actually building the concrete in the asphalt for that highway to now go fast. And I think that's what 2026 to me is going to represent is all of the work that we are doing. Not like a new. Not a new highway, but it is making this highway that down the road we can put the things on, we can make this go faster Instead of going 40 miles an hour because it's a little bumpy and it gets straight flat, gets you there. And you're not gonna fall off the cliff anymore. You're not gonna run into a house, but we can make this faster. And that's where I get really excited. And that's kind of what I was thinking about this morning.

Yeah, I mean, I think a lot of this first year, I'll say, I don't know, the first year, I think has been laying all those foundations. I think there's a lot in terms of the design system Nathan's been putting together, which, what does a button look like? What does a table look like? And there's all those things that just. Those are all the Legos that you have to have in order to build the pages. And then there's all this learning about the actual data model, the systems that are in place, the processes. I think same thing on the back end. There's understanding the database, getting these frameworks in place, getting our APIs in place. There's a lot of specific frameworks. And those are the things that I think we bring all this experience of. We know how to do that. And that infrastructure has to exist here. I think the Customer Portal and Fieldforce I think are the first examples of using all of those tools. This is what we're capable of. And we were talking about this yesterday. We were reviewing bug counts and I think with both the customer Portal and with Fieldforce, our average daily bug, our average weekly bug intake is zero for those.

I think that those are the fundamentals of having those things. And then also, you know, the design systems and the front end, that's all going into that. We're, I think, just starting to realize what that's going to look like for the CRM. And that's. That's the part I'm most excited about, is once we start really rolling out all those same patterns. But it was a lot of preparation.

A lot.

Now we're running. You know, I think we're now just starting to get running. I actually think the momentum is still.

Yeah, yeah.

Is still building with all of that. There's still. There's still some foundational, and I think.

It'S evidence of the past few weeks, just like the speed at which now the team is able to produce.

And I know how frustrating and challenging it's been in that year as we're building, because it's like we've got this amazing team. We have, you know, a good handle on what we think are the problems we need to solve. And you've been really gracious and just. And having trust in us that we've got the team. We're building the foundation, and I think you're going to see us delivering a lot of value very quickly moving forward.

Well, I want to wrap it up. I want to, first off say thank you to the three of you.

And to the team. And we're four out of 30 or 40 people on the team, and there's a lot of people behind us that make each of our roles possible.

Yes.

And so I'm sure they'll watch this. I want to say thank you to all of them. They know who they are. I'm not going to start mentioning names, but there's so many key contributors to making this possible. And I want to say thank you to them and to you, because I will be, as the company grows, likely the person that will get the praise. I was definitely the one who got all the rejection and hate online when we were bad, but I will get that. And I wanted to say thank you because without you, the three of you, and the teams that you all lead, none of this is possible. And the members that we are helping and trying to help more, all of that's not possible. And so I want to say thank you for your contributions to the team that supports all of us. I really do appreciate it.

Yeah, thank you, man.

Awesome.

Well, thank you all. Appreciate it. Feel free in the comments. If you have specific questions for either of these four, feel free to comment. We'll get back to you as we can in the comments, but we'll see you on the next pod.