Why builders make bad entrepreneurs 🧱 Matt Watson

I wish I would've never sold it. That company today would probably be a unicorn. It would probably be worth $1 billion. If you are the founder of a company, you own the product vision, whether you like it or not. You own it. Own it.

Today's guest is Matt Watson, founder and CEO of Fullscale and author of Product Driven. Matt bootstrapped his first SaaS company to $35 million yearly revenue and sold it for $150 million and has been building and scaling companies Ever since.

The biggest trap for most software engineers is they can— We need software developers, not software engineers. Claude Code is the engineer, right? AI is the engineer, right?

What did you misunderstand about exit before the first one?

It's hard to understand is how it changes people's perception about you and relationships. It's a lonely place to be an entrepreneur.

Absolutely. Oh, everybody says that.

There's a reason that most good CEOs are salespeople. Because business is about sales. It's not about building.

Matt, welcome to Millennial Masters. Where are you joining us from today?

Kansas.

Well, hopefully you still have your slippers on.

Home of Superman and the Wizard of Oz.

I mean, two great characters and great inspirations. Not sure about business though, but that's maybe where you come in. Because Matt, you've built, sold, then built again across SaaS, services, media, and now this product-driven angle. Did you always think you'd stay this close to software building for this long throughout your career or working life?

I mean, honestly, I've just been a guy looking for something to do. You know, the first company that I started, somebody reached out to me and said, hey, I have this problem, can you help me? And I just said yes. That was it. I mean, I think that's the first thing in life is like opportunities come along and you just have to take them. And I've just always been the guy that said Yes, maybe I can help you do this. I started 4 different companies and I was the co-founder of 3 of them. They were, they were not my idea. I was just the guy who said yes.

But that was because of your technical skills and your coding. If you would go back, how did you get into that?

Well, so that story starts all the way back when I was about 13 years old. I started playing games online and this was back when we had a modems, right? Like, you know, I don't know, like—

Yeah, the ones that screeched and yeah, when you connected.

Yeah. I mean, since this podcast is about millennials, like I guess we're showing my age here.

We'll remember it. Everybody will remember that.

And I don't know if I'm technically a millennial since I was born in '81, but yeah, I started in games back then and basically I wrote scripts to automate playing the games. So while I was at school and while I was sleeping, I would run these scripts to play the games and that was a lot of fun. I went to college for what was called Computer Information Systems. Not computer science. And like a lot of people, dropped out halfway through and got my first job doing computer programming.

And your first business was VIN Solutions.

That's correct.

What was the first ugly version of that? And what was it actually doing? That, you know, the first, let's call it a prototype if nothing else.

Yeah, so the original idea, there was another gentleman that was going around and taking pictures of cars and was trying to figure out, okay, how do I organize all this and upload the pictures to the internet and stuff? And so that was the original idea. And you gotta remember, this was 2003, so the iPhone didn't exist. Like digital cameras were very expensive. Very few people had a digital camera at that time.

And the quality was, uh, um, yeah, not great.

Nope. And so we were on the early cusp of, of this kind of revolution that, that has unfolded. Um, but yeah, it was just a simple idea of how do I, how do I take this data and upload it to a site like autotrader.com, cars.com, things like that. And, um, it, yeah, it was just a really simple product. It was definitely ugly, but it, it was very utilitarian in what it needed to do.

And how did you grow that from like a narrow pain, which was uploading stuff onto these major trade websites into something much bigger? Because you've added features that nobody wanted.

Why was that? Well, so it, when it started out, we were taking photos of cars and their data and uploading them. But then we, we added more features to print the stickers like that you would see like on the side of a buying a car at a car lot, you know, just describing the car and stuff like that. So we, we built stuff like that. Eventually we built websites for the car dealers. And so we were building like a whole sort of like marketing suite for them. Right. Um, the big thing that changed is when we moved into building what we called Internet Lead Management, which was a type of CRM type product that was designed around handling internet leads. And in this day and age for the car dealers, The idea of getting internet leads was like a new thing, you know, because they would get emails and they would get a request from a site like autotrader.com would come in, stuff like that. So we built software specifically designed around handling those, not, not too different than products today like HubSpot and other, all these other CRM products, but it was very cutting edge at the time because you could inquire about a car and the software could automatically email you back and say, here's the brochure, here's the link to our website, here's 5 more cars just like that one that we have available. Like it did all this kind of automated functionality that we all take for granted today, but back then was like super cutting edge.

It was the beginning of this era before people started using this type of systems day to day. But that also meant that you had to bootstrap Vyn Solutions. And as your first business, what did it force you to learn that, you know, most people who don't have to go through that process, say they're raising capital, don't? From my experience, it's a much slower organic growth. And you have to place stronger bets behind the things that you invest in next.

So I didn't at that time have any idea what a startup was or venture capital or even entrepreneurship. I was just a guy trying to build some software and we had customers that wanted to pay for it. That was it. It was just a business. We started a business. We had customers from the very beginning and it just slowly grew. We never raised any outside capital at all. We did get to a phase where we were very rapidly growing. Into like 2007, 2008, and we wanted to raise capital then for growth. But if you remember what happened in the United States in that time, that's when—

And then a crisis.

Yeah. General Motors went bankrupt. Chrysler went bankrupt. Ford closed a lot of stores. Was not a good time to be raising capital, especially when you're in the automotive sector and it's like kind of doom and gloom with all the automotive, uh, you know, big manufacturers. But it was actually all a huge positive for us. You know, when car dealers are making a lot of money, they spend a lot of money, right? They're like TV ads, radio ads, newspaper. They're just throwing money everywhere. They're making lots of money. When they're not making a lot of money, they're trying to figure out how to save money. And we were the perfect solution to help them save money and move to digital. Like, we're not gonna pay for radio and TV anymore. We're gonna spend more money on autotrader.com and cars.com and eBay, but we need a tool to help manage these internet leads and, and how we do this digital thing. That was new and we had the right product at the right time. And so that recession actually was a huge boom for us. We were growing way faster than we could even keep up with.

And how did the, um, how did you move on next? Sometimes people design a business from the beginning. I was speaking to a founder this week, actually. They design a business to be sold and or acquired by a much larger company versus somebody thinking, okay, these guys have the right idea and we're just going to take it all wholesale and build it into what we do.

Well, what was interesting is we had that business for about 8 years. Okay. So we get to 2010, 2011. We start down this idea of, well, maybe we'll raise some capital. Let's sell 30% of the company or whatever. Maybe we could go raise $20 million. We could take a, put a few million dollars in our, in our own bank accounts and then swing the company.

So it was all for expansion and—

Yeah. Because we were still growing at an insane rate. We, at that time. We bootstrapped this all the way over $30 million a year in revenue, bootstrapped to $30 million a year. And we didn't, we didn't have enough servers. We didn't have enough support people. Like we, we were just struggling to keep up with all of it. And we, we really could have used like a big influx of cash to like really overhire and, and do some things the right way. Although it's interesting, when we got to the end of it, we became so profitable. We really didn't even need to raise capital. Like we were actually, wildly profitable in the end of it. Um, which is funny. They always say that, right? The banks, the banks only want to give you money when you don't need it. And that's exactly the experience that we had. But we, we went through that process and originally we thought the company would be worth $60 million, $80 million. Like we did, we didn't know, but eventually it, you know, we got offers that were up to $150 million. And remember it was me and two other people that basically owned 80, 90% of the company as the key shareholders. And so it's a lot of money. At some point in time, you're like, you just take the money and run. And when you talk about like why to sell a business, there's a lot of good reasons and we can talk more about that.

Well, let's talk about that because I know there comes a point where not necessarily you get jaded, but you, the job changes, especially when you scaled from basically zero to a $30 million a year company. The processes, the staff, the day-to-day job changed. Yes, you were the founder. Part CTO, and you wrote about that trap, and we're going to talk about that separately. But I want to know how you felt when the job started changing and when these opportunities arrived to take the money, and maybe you had something else in mind. You wanted to do something else and move on next. You weren't in your early 20s anymore either.

I was 29 at the time when we sold it, and I definitely could have retired, although looking back, like, I still need something to do. I still need something to do today, but I think there's a lot of good reasons to sell a company, right? I think some of it is timing. You're looking at market timing and you're like, I don't know what's going to happen with this thing or that thing. And there might be a time of window where, you know, we're way ahead of the competition. Let's sell. Let's get out of this while we can. I think the main thing, well, there's one other thing I want to talk about first. The trap, a big part of the trap when you're in the heat of this, we are growing so fast, we almost feel invincible. And We're doing $30 million a year in revenue and we're sitting here, man, this thing's worth, let's just say it's $100 million. We're like, at this rate, it's going to be worth twice that in 12 months or 18 months. Why would we sell now? Why wouldn't we just wait 12 more months or 18 more months? But you can just keep doing that. You could, I mean, if that, if you're still growing, like you could, okay, when, when is enough is enough, right? I think is the thing. And I think that the big thing is diversification. You know, when you have all of your assets and all of your wealth in this one thing, That is the thing I think that eventually kind of eats away at you a little bit. You're like, man, I would be better off if I could sell at least part of this thing or all of this thing, set myself up where I've got a security, I could retire, whatever, for the rest of my life instead of just continuing to roll the dice with this thing.

But it was hard to think of that at the end of, you know, in your late 20s, it is, it's hardly, hardly at the top of your mind, retirement. You don't even contemplate it in that aspect. So what did you do about it then?

Did you— We took the money and ran. I mean, when, when, you know, we had, we had over 3 offers, I think, that were over $100 million. And at some point in time, you're like, just doing the math, you're like, this is an insane amount of money. You know, at some point in time you take the money and run, but there's a big part of me looking back today, I wish I would have never sold it. I wish I would have never sold it. Like that company today would probably be a unicorn. It would probably be worth $1 billion.

So would you say that you fell in the trap of selling early rather than waiting for longer.

You know, I don't, I don't have any remorse for it, but it's just, you know, it's just one of those things in life. You roll that, you roll the dice and figure out, you know, what to do at the time. And it wasn't just my decision. I had other business partners too. They were a little older than me, but they had other priorities.

And I mentioned, because you, you wrote about the founder and CTO trap and coding being one of your main specialties. What breaks first when the founder CTO is still acting like the hero coder? Because you possibly had to like go in and fix a lot of the stuff, firefighting constantly when the stuff broke rather than having the overview. And this was my experience as well. When you try to zoom out to have an overview of the business and work on strategy, whether it's developing the code, the product, the new direction, the next update versus fixing things manually yourself.

Well, I think there's two things here. And actually I would say where it starts first. Is the biggest trap is a lot of startup founders are builders. They like to build things. They don't like to sell things. They don't like to talk to people. And that makes them really bad entrepreneurs. And I know a lot of people that are this way. They're really brilliant builders. They're really good at building things, but they don't know how to sell anything. Like they, they don't know how to operate a business or sell something. They're like in their basement playing with Legos. It's more like a hobby to them. And that is the biggest trap actually for most people that are software engineers is they can build anything. They don't know what to build and a lot of them feel like they act like they're allergic to sales. And this is why I tell people all the time, it's like, you can build anything, but you got to know how to sell it. And there's a reason that most good CEOs are salespeople because business is about sales. It's not about building. Like I could sell somebody else's product. I didn't have to build the product.

And how did you develop your skills in this area?

Well, I think I've always been more of a product person. I've I've always been the person that's not scared to talk to customers, understand what they need. I also had a business partner. My business partner was a salesperson. I, you know, I mentioned earlier, I've been a co-founder 3 times and in at least 2 of those, my, my co-founder was the salesperson. And so I was the person that had to, had to build the product. I think I've also just been blessed to have that skillset of I'm not afraid to talk to people. Um, I can speak both languages. I can understand the tech side, but I, I can also do the customer part of it. And maybe that's because when I was younger, I, I worked at, in retail and then sales and had to deal with people and maybe that made me more comfortable with all of it. But so that's the first trap.

And the other one?

So the second trap is just learning when to scale, you know, so is making this problem even worse. We, we could talk more about that, but when you're—

might as well touch it now while we're at it.

When, when you're in a really small company, it's easy to be the one who has the product vision. Like, I know it needs to be built. I can build it myself. I can do it myself. And then you start hiring a couple people to help you. Inevitably, you sort of end up kind of micromanaging them to get them to do what you want to be done in your way. And eventually that just does not scale. It doesn't scale. You, you've got a couple people that are working for you, but they're basically just doing what you tell them to do. And the only way it really scales is to give them real ownership of their, of their job. You, you have to stop giving them—

delegate.

You have to stop giving— the thing is you have to stop giving them tasks. And start giving them goals. You're like, here's what we need to accomplish. You go figure out how to do it. And, and that's the only way it works. So the problem is, is that also takes dramatically longer because now I have to spend forever with this person trying to educate them about what we're doing, why we're doing it, how we're doing it, why that's a good decision, why it's not a good decision versus me just telling them what to do. I could just tell them what to do, but then we never scale because they never build up the knowledge about why we do things the way that we do. And so that's why this is such a difficult proposition and sort of a trap. It's like the easy button is for me to just tell them, do exactly this, go do it. But then they never learn why they never have like the sense of purpose and meaning and ownership behind it. They just, they don't care. They're just like, tell me what to do.

I'll go do it.

So you really want to scale, you got to build up this, this ownership in the team, but it's a lot harder to do.

It takes much longer as well in order to bring it all up to speed. Do you think it could have been looking back? Do you think it could have been done differently? Say if you documented more of your thinking thinking and your processes, which is what AI can do now. And that's why I'm bringing it into the discussion alongside with the coding element.

I think we talk about this a lot in regards to how we do software development today is we can capture a lot more documentation and context is really valuable. And in the past, I've never been a big fan of documentation because it's like nobody ever reads it and it's always out of date, you know, the week after you write it. And nobody really ever, ever reads any of this stuff. Well, now all of a sudden that documentation might be the most important thing you have because AI can use it and actually use it to understand how to build software. Where one of the problems with software development is, you know, like, hey, we have this big bug in this thing. We need to figure out how to fix this thing. And you'll be like, I don't know. The person who wrote that left 5 years ago. Nobody here knows anything about that. There's a knowledge gap. Right? Like we don't have the tribal knowledge or documentation to know how this thing works. Where if you would have captured that along the way, now it's like you have that kind of forever lingering around capturing that knowledge about how does this thing work and why does it work this way? Why was it designed this way? And now a lot of companies may have that hidden in their project management software, right? In Jira or ClickUp or whatever it is they use. But historically that has just been so lost and divorced in like a black hole where now I think it's, it's shining the light of how much more critical that is and getting that so the agents can use that to know what to build and how to build it. Like all that context all of a sudden is really, really valuable and it's changing our jobs to spend more time doing these kinds of requirements and figuring out how to make the tools do all this. Like it, it's never been more fun to be a builder and build software. But that's created a new trap. You ready for the new trap?

Take me through that one as well, Matt. Yes.

So if you love to build, as I mentioned earlier, like there's this persona that loves to build. They have—

Every entrepreneur does that. Yes.

They have spent the last 6 months only staring at Claude code and building, building, building, building, building, building, building. And one of my friends is this way. He would tell you, he's like, I've written millions of lines of code. But I ask him like, okay, how much, what revenue do you have from that? None. It's like Claude Code was the needle and every prompt is the drug, right? Like they get a little dopamine hit every time they, you know, do another prompt and write a little code and build a little thing. It's like they're hooked, man. It's like a drug. But it's a good drug.

So you think they're wasting time?

In some ways they are if they don't go sell the product. They've gotta sell the product and that's the problem. And AI has created a little more of this problem because it's so easy to build stuff. You can like hide, you can hide forever and just keep building, building, building, building, building, building. It's like even worse than before.

Yes. And we, we, we know, and at least 4 different founders have told me that directly, that build and they will come is the biggest lie.

It doesn't work. And that the thing I always ask them is, how many customers have you talked to about this? None. Well, then you don't even know what to build because, because if you're targeting this type of customer base versus this type of customer base or small companies or big companies. Even in one industry, you can pick one industry in one vertical, depending on if it's small companies or big companies or whoever you're dealing with, you need different features and different things. And the only way to know that is go talk to customers. And you know what their response is too, is like, well, I'm building AI to do that.

With Claude as well?

Yeah, I'm sure. No. Yeah. They don't wanna talk to customers or do marketing or sales. They're gonna build more AI to do all that too.

So you said, Matt, that you'd want your developers to take ownership of certain parts of the project. But a lot of the founders, as you know yourself, keep a lot of this knowledge in their head.

Yeah.

And that's the hardest part to take out. You can speak to AI as much as you want. It's not gonna make it onto further down the, the— where, where do you think there's a, the clean break of how much and how often do you need to offload from your mind to your people?

I'm so glad you brought this up. I wrote a book about it.

Maybe it was the lead-in into that.

So, so I ended up writing this book called Product Driven and, and we can talk more about why I wrote it and whatever if you want, but—

Yes, let's do that.

What, to answer your question directly, I ended up creating what I called the Product Driven Model and there was 5 components to it. And the 2 that matter the most answer your question and they refer, they're what I refer to as vision and clarity. And when I say vision, it's not like some HR slogan about, you know, why we're some great company.

It's not that.

Why are we doing this thing today? Why is this important? Why are we doing this? Because whoever you are as a leader, if you don't tell your employees, like, why are we doing this? They're just never going to understand. And they're not, they're not going to have that sense of purpose and they're not gonna be able to make the same decisions, right? If you told them like why we're doing this, they can make different decisions. And it's no different than with being a parent, right? You tell your kid like, stop doing this. And they get mad because they don't understand why you told them to stop. But if you tell 'em why, they'd be like, okay, yeah, dad, dad's right. Dad's right. I understand why I should stop now. Right? Like, so everything starts with a vision. Why are we doing this? Why are we not doing this? Why are we doing it this way? And honestly, that's something you have to do almost every day. Definitely every week. Every week it, it keeps changing, right? Like, cuz what you do every week changes. And if AI makes you do things twice as fast, you gotta meet twice as often.

In order to move it forward.

Yeah. Right. That's the problem with AI is now, now we got to like go even crazier trying to keep up.

But also it allows you to get a lot of the features out faster. I'm going to go into two tracks here with the questions. One is how do you direct AI to fill and make things faster in principle? Because I'm assuming you're still having them reviewed by a human. And the second part is Does the AI-assisted coding change the type of person you hire for the job?

Yeah. So I'm sitting here writing my newsletter today, which is the Product Driven Newsletter, and the title of it is How Software Developers Are Replacing Software Engineers. And when I started my career 25 years ago, I would talk to customers. I would put my product hat and think on what are we building? What problem are we trying to solve? How do I, how do I help the customer do whatever they want? And then I would go build it, right? Where over time, that job turned into only engineering. It's like the product manager and product owner, project manager, business analyst, all these people, it was their job to figure out what to build. And they would write all the requirements and then they would give it to a software engineer who would build it, right? And part of the reason why is software development was slow and expensive and it was hard to find people to do it. So it's like we stripped away work from them. So that all they had to do was just literally write the code primarily, right? But AI has changed all that. AI writes all the code. So now we need to go back to that era. We have to go back to where we were 20 years ago. We need software developers, not software engineers. Claude Code is the engineer, right? AI is the engineer, right? So that's why I'm writing about in my newsletter today. And we have to go back to that time where you mentioned it's like rapid development. When I started my career, that's what we called it. RAD, rapid application development. And we moved very quickly. We did not over-engineer things like people do today, but that is the world we have to move back to. And it is absolutely changing the careers of people. And I read about on Reddit and stuff every day, people are like, I don't know what to do about AI. I don't, I don't like where, you know, what my job has turned into. I'm thinking about switching careers. There are some people that were just so hardcore of engineers and that was a craft to them. You know, it's like they were a craftsman. They took a lot of pride in the work that they did and the code, and it was beautiful and all this kind of stuff. You know, think about like a master carpenter or something, right? And then we was like, no, we have a machine that can 3D print anything now. We don't need you as a carpenter anymore. Now your job is to manage the machine that does the 3D printing. You're like, I don't want to do that.

And that has been the role throughout all the other parts of a business, whether it's marketing, whether it's copywriting, accounting, wherever you deployed AI in the business, that the same role remains. You manage the AI. So similarly in development.

Yeah.

But I wanted to kind of like focus on the different qualities of people you are hiring between the developers and the engineers.

Yeah. So here's the challenge. In software engineering, traditionally, we would have one product manager and one product manager could manage 4 or 5 or something software engineers. That doesn't work anymore, right? We need a lot more product managers. Okay. Now we might need for every product manager, we need one software engineer or two software engineers, right? Because how fast we can make decisions and do product design and all that kind of stuff is changing it. And my theory is software engineers have to really turn into being product owners. And I have a great analogy for this. We have what we call no-code development. You heard of that before? Yep.

Yes. 3 tools. Lovable.

Yep. Well, and if you go back a little further, you have Salesforce. Salesforce.com is like a no-code product, right? You can add form fields to it and do weird workflows and stuff like that. And you don't really have to be a software engineer. We had Microsoft Access like 30 years ago that could do this, right?

Yes.

Yes. This is not new.

Build databases, drag and drop.

Yeah. This is not new, right? We've had no-code stuff forever. And you have tool— tools like Bubble and all these different things. Well, and then we got to an era where we had low-code tools. So there are some tools like Bubble and others. That let you drag and drop and do stuff. And if you need to write a little bit of code, you can write a little bit of code like Microsoft Access. You could write code in Microsoft Access too. In Excel, you could even do VBA scripting in Excel and do crazy stuff. So you had low-code and then you have a third category, which was like full-stack software engineering. So we had no-code, low-code, and full engineering. Well, if you're on the no-code side, your skillset has to all be about product, right? You're like, what is the business problem we're trying to solve and how do we solve it? Like that is the only world there is to live in. Right? But if you're on the like full engineer mode, you don't do as much of that. You're in like engineering mindset, highly logical problem solver kind of person, right? If you're low-code, you have to do both. You sit in the, in the middle of this. You've got to have enough of a technical and engineering mindset to know like how to do some of this stuff while also being able to understand the business problems, right? That is where all of software engineering is going. In the middle. In the middle. It's low-code mode. It's low-code.

But, but they're two very different type of roles between the project management and the code. Is there a, there's no particular degree that gets you both?

How? No, these problems, these people don't exist. That's the problem. They don't exist. There isn't even a way to create product people. Nobody goes to college to be a product manager or a product owner.

Yes, have Lenny's newsletter for that.

Yeah, that's it. Yeah. So if, if we, if we talk about product for a minute, there's really like about 3 ways that people become product people. The first one is they maybe work at a company and over a long period of time, uh, they, they gain some domain experience, right? Like I worked in a medical laboratory and there was a lady there that ran the medical lab. She was the expert at the lab. So she was like the product expert, right? She was the expert at how all things work. She wasn't technical, but she was the expert at the industry and the problem.

Okay.

Second way would be somebody who worked in a product team and over a long period of time worked through the ranks and did this kind of work, right? But I think the third is actually where a lot of them actually come from, which are people are trying to solve their own problem. I have this specific problem and I'm trying to solve it. And that's not just a technology, like a friend of mine was trying to create custom cabinets for his outdoor kitchen and there was nobody that sold custom outdoor kitchen cabinets. So he decided to start a business that did that because nobody else did. And like, that's what most entrepreneurs do, right? We find a problem and we get frustrated because nobody solves the problem the way that we want to solve it. And then we go solve it and we have this crazy product vision for how it's supposed to work. And that's why a lot of startups are successful, right? There's this like really strong, like crazy product vision behind it, crazy idea behind it. But how we create these product people, like They just, they don't really get created. Like, this is a very rare skill, is my point. Nobody goes to college for this. Nobody learns it. And it requires having, like, a strong opinion and taking risk of, like, I talked to all these people. This is what we need to do. Let's go do it. Which means nobody in corporate America—

Yeah.

And nobody in corporate America wants to do that because they don't want to get fired for making the right— the wrong decision. And a lot of that's just human nature. Humans, humans want to, you know, have harmony and get along and not make mistakes. But when you're a product person, you have to make bold decisions. It's a difficult job.

Who takes the responsibility at the end from that? Is it the, um, after the product manager, above?

Above? Yeah. I mean, ultimately it's leadership. I mean, it's ultimately it's leadership, right? So at Fullscale, we have some internal products that we build, and I keep telling the, most of the people we hired have more of an engineering background, not really a product background. But I keep telling them, I'm like, you guys gotta think like product people, right? Like, you've gotta go talk to a bunch of people about what do we need to build? And talk— you have to actually go talk to people. Like, that's the job. Your job isn't to write code. AI writes the code. Your job is to go interview the other stakeholders in the company and ask them, what does the product need to do? What are the problems? What are the opportunities? How do we solve them? But it's such a different mindset that most of them have never been exposed to.

Before we move on to Fullscale, I want to stay on AI and technical debt because because I know it's also one of your favorite topics to touch on from my research. And how much would you say of the technical debt is actually code? And how much is the old decisions or the old way of thinking before you figure out a newer and better way to do it?

Well, technical debt is one of those topics that I always kind of laugh at because all the software, the code—

Make it funny, Matt. Make it funny. That'd be great.

All the technology we've ever built. Is either a debt, it's a liability, or it's an asset. Which is it? Is it an asset to the company or is it a massive liability? And the problem with this is all the technology you build, it doesn't matter what it is, it doesn't matter how perfect you wrote it, it only has a lifespan. It's only gonna last 3 years, 5 years, whatever, and eventually it will be thrown away. What's funny about this with software engineers is they hate other people's code. It doesn't matter how you write stuff. You hire the next person and he come, they come in and they will say everything that was done before was not great. It all sucks. We've got to rebuild this thing.

Yeah. All of it.

They all do that. Every single one of them. I don't care who they are. I don't care what they all do it. They all do it. They hate other people's code. And part of it is they don't understand it. Right. Or they think there's a better way.

Comes back to the documentation point earlier.

It's back to the craftsmanship thing, right? Like, they take— there's a craft to it and they're proud about how they build stuff and whatever. Or there's a new way. I mean, that's the other problem is software engineering has changed dramatically over 25 years. I, um, the most popular newsletter article I ever wrote went viral on Hacker News and went viral on Reddit big time. It got massive views. And the whole article was about how my entire career was technical debt or basically deprecated. Like everything I had ever done in my entire career was gone. The code is gone. The code is deleted. Like you guys spend so much time worried about this technical debt thing. Everything I've done in 25 years is gone. Like, it's just the nature of it. Like you guys worry about such a thing because think about like, I built stuff that was Visual Basic 6, 25 years ago. Nobody uses that anymore. Or they use like Flash or Microsoft Silverlight.

Or is it archived anywhere on the internet? Not even that. It's just a static screenshot at most.

Yeah. I mean, I was building mobile apps before the iPhone existed. That stuff is long gone, right?

For the Nokia phones, for the BlackBerrys?

It was for the PalmPilot, like the Palm, uh, Windows—

Palm OS.

It's like Palm devices and stuff. But Windows CE, was it? Windows CE. Yeah. Windows CE.

Yeah.

My point is like code has like a lot— code has a job to do first and foremost. It has a job to do, and if it can do the job, it's good code. If it can't do the job, it's bad code. But, but point is like, it only has a certain lifespan anyways. Like most things only last 3 years, 5 years, 10 years, whatever it is. There's very few things that make it older than that because things just change. Technology changes. Somebody buys your company, they kill the product and use this one instead. Whatever it is, there's a million different reasons. Back, back to your original question about technical debt. AI is also changing all that. So if people talk about AI slop.

And, uh, I, I joke with you more about content than, but you'll tell me that it's, uh, there's a version of it in the code.

Yeah. AI slop in the code. It's like it created this nasty code base and all this mess and whatever. There is some truth to that. Like a non-software engineer, if they go use nothing but AI, it's gonna generate a whole lot of us, lot about a lot of stuff. Yeah. It may not organize things well in the database or didn't create like clean code or reusable code or didn't organize it very well or a lot of all these things. That's all totally, totally possible. Sometimes it also doesn't matter 'cause like my kid built this thing and it does what my kid needs to do. He's never even looked at the code and he doesn't care. It's good enough, right? But from an engineering perspective, right? In a big company, if you're using this stuff, you can build all the guardrails. You, you know, you create all the documentation that tells it how you wanna write code, how you wanna organize it, how you wanna do that stuff. You have a human in the loop that, that reviews all that.

You give it that craft element.

Yeah, but here's the thing. If it doesn't do it the right way, you can just tell it to fix it.

It might take a few passes from my experience with writing, and I'm assuming if you have the code slop, it will be the same process.

But it's even easier with software engineering, I would say. When you're writing a newsletter, a book, or anything like this, the grammar, the story, the narrative, like there's like an art to that.

There's an element of taste. Yes.

Yeah. There, there, you know, there is a creative art to that. And so software engineers that hear me say this are gonna be mad when I say this. There is not that to software engineering. There are inputs and outputs. What the code looks like between those inputs and outputs doesn't matter as much. There, there's like 50 different ways you could do it and they are all correct. And, and you're not reading the code like it's art, like you would a newsletter, right? Where there's a style to it. The code either does the job or doesn't do the job. That's the difference. And that, and that's what is some software engineers are struggling with. They're like, to them, it was an art, but now it's like, no, there's inputs and outputs. And if it gives the right output, it doesn't really matter what the code looks like.

And did AI make documenting new features and these developments easier? Because I know, for example, in a series of products, you would automatically create, say, release notes or document certain functions or features. Is that slop as well, or a lot of it's slop as well?

I mean, it's able to create that kind of stuff that software engineers frankly never did. I mean, asking software engineers to write release notes, they don't do it. They're, they're notoriously bad at it, right? Because usually they're, they're not very good at explaining things to other people. Like that sort of communication is usually harder for engineers. Because again, they just, they want to write the code and they want to do the thing, but they're usually divorced around like, why did we do it? How do I explain the value out of it? Like, how do I do the marketing part of the work that I did? To tell them how to—

Yeah, they have to put the mark. It's a totally different skill set. And it's not about having it in a lyrical or stylistic way. It's about how it's pitched.

Yeah. And so AI can do that really well, right? AI, that's one of the cool things is like even the notes in the code, like the comments and stuff in the code will be very good of like, here's what's in the pull request and all this stuff. It does a really good job at all of that, that most software engineers would never do. They'd be like, I fixed the thing, and that's all they would type.

But they, they, they might spend a lot of time trying to figure out where that one, the cause was, or because the code wasn't properly explained initially.

And then they'll just say, I fixed the thing. Where AI now will actually give like a great explanation about this was the bug and this is how it was fixed and blah, blah, blah, all this stuff, which is really helpful.

For both the humans and future AI, which will look through that code and bring it back and redo it. Now, I think we've established that, that these skills or this mix of skills is very rare now for what the modern companies and coding need, which is where your next venture comes in, Fullscale, because it came from your own hiring pain.

Yeah.

And what was the actual problem you were trying to solve when you started it?

Yeah, so we started Full Scale, I think it was 2018. I needed to hire software engineers for a different company of mine. Mm-hmm. 3 of my top developers got recruited away. One of them went to work at Microsoft, one went to Amazon. Like, so I lost 3 of my key people. And what I realized is like, the cost of those 3 people, I could hire like 10 people overseas. And I'd had a little bit of experience hiring people in Russia and Latin America and different places as software engineers and had good experience. And just decided to give it, I was going to give it a try. I'm like, I got to go all in. I really need these 10 developers to go help build all this stuff. And my friend already had a handful of employees in the Philippines and we decided to create a little partnership. It's like, you know, we'll get a little coworking space. Maybe we'll have 20 people there and we'll create a little business out of it. And if we find somebody else that needs this, maybe we can help them. And at that time, he did have one customer. He had one customer that he was doing this work for. And next thing you knew, man, we hired 100 people in the first 12 months. It just exploded.

And across the world as well?

Just in the Philippines.

Just in the Philippines.

Okay. We grew from zero to like $5 million a year in revenue in one year, which was incredible.

And how did you divide the work between the team? Were they first looking after your product and that was their priority? And then any spare time and capacity they had was pushed onto other projects, or you had a certain number of people per project and that's how you also sold it as?

So we did this slightly differently. We didn't, we don't do project work. We just do staff augmentation. So, you know, it's like if I get 10 people, these exact 10 people only work for this client. They don't, they don't do anything else. So, you know, at Fullscale, for example, we have AMC Theaters as one of our clients. We did like a whole case study with them and everything was very cool. Yeah, we have a whole big team for them and those people only work for AMC Theaters. We have over 80 clients that we do work for. So they're dedicated teams that—

So when you have an offshore team or an outsourced team, whichever way you want to look at it, it sounds great until you realize that you still need somebody in the business to own that knowledge and to, to direct it because you can't take, so to speak, outsource the CTO as well.

No, I would say you can't outsource the product vision. You can't outsource innovation, right? A lot of times they're all problems you have to own internally and you have to figure out. I always tell this with people that have like start, like it will be like a founder. I'm sure you've had these people on your podcast. They have big problems with sales or marketing. Like, I don't know how to sell our product. I don't know how to market our product. Hiring somebody else to figure it out usually doesn't work either because they don't know anything about your industry, your business. They don't know anything about it.

That's how we ended up doing this episode through one of these founders, Melissa, who worked out through all these problems and then how we, how we ended up on having this discussion on web development and outsourcing here.

Yeah. So it is much better if they own all of it internally, right? So our best clients all have in-house engineering leadership. And then we provide the extra talent to help them scale. But the big thing is it's all about a team. The reason that our model works and any kind of hiring global talent works or any talent works, it doesn't even matter where they sit, is you got to treat them all like one team. It doesn't matter where they live, where they sit, if they're a contractor through whoever, you need them to be part of your company.

Or they, you know, and that's going to be, that was actually my next question. How do you do that? How do you get the dev team to understand the product, not just the task that they have to do because it's on a, on a list.

So that ultimately that's a leadership issue, right? Leadership has to do that, make time for it, put, put the effort into it, right? And again, it doesn't matter if that's an outside contractor or an in-house employee, somebody in an office or somebody remote, it's all the same challenge, right? But it really comes down to a leadership issue of how leadership handles all of that. But the key is that whoever those team members are, again, wherever they sit, need to be as close to the problem as possible. And you don't want layers, you know, I, I, I think in that same chat, somebody was talking about they have a team in Vietnam, but they only ever talk to the project manager or the lead developer in Vietnam. They don't talk to the developers at all. And to me, that's the problem. The developers need to be part of the conversation. There can't be this, that layer in between is part of what usually causes the problem. We got to remove those layers. We need everybody working closer and closer together.

Because oftentimes the, so to speak, manager on the remote team side doesn't necessarily have the technical knowledge. They're more like a key account manager than a technical person, right?

Well, or it's just a telephone game. You know, I tell you something and then you go tell Melissa something. Melissa has 4 questions, but she didn't ask them to you. And you didn't relay them to me. And even if I did answer the question, you didn't give her the same answer, right? Like we need Melissa needs to be able to ask the question directly to me and get you out of the way. Or we just work in Slack or Microsoft Teams. We all work together. We all ask the questions together. Like we got to remove the middleman. That's the problem.

And what would you say, say for, for a founder and they have a technical lead and maybe an outsourced team on the technical side? Are there any warning signs that the leadership system is weak and not the developers?

I think there's a lot of things there, but I think if you're a, a leader or founder in any way, shape, or form, I would highly urge you to invest more time in being involved in the development process from a product perspective. If you are the founder of a company, you own the product vision, whether you like it or not, you own the product vision. You cannot outsource your vision, your crazy idea to somebody else. You own it. Own it. But what you have to do is invest the time in getting it out of your head to everybody else so they understand. That means you've got to spend time every week with the team, giving them, like, as I said earlier, at least the vision. What are we doing? Why are we doing it? Why this is important? How did what we did last week impact our customers? What we're going to do this week? How is it going to impact our customers? Right? Like, spending that time. And sometimes it's, it only takes 5 minutes. Sometimes it's recording a Loom video. Like, hey guys, the last release looked great. Here's what I really like. Here's what I really don't like. Here's why I need you to improve. Take that video, send it to the team. Sometimes that's all it takes. So the team understands what they're building and what, and what you need. Like constantly getting that feedback out of your head and giving it to the team is your job. You cannot outsource that to somebody else if you're the visionary founder.

Even if you don't have the technical skills, you have to have the—

it's the problem domain and it's your vision. It's your vision for what you want built. You've got to take time to share that vision. That doesn't mean you have to get into the weeds all day long. It doesn't necessarily mean that you've got to be using AI and building software yourself. Eventually, you know, in the early days you should, in the early days you should probably prototype the whole thing yourself, but eventually you've got to go run a business. You've got to focus on sales. You got to focus on marketing. You got, you got all these other things to do. You gotta hire a team, right? You gotta learn to delegate that to somebody else, but you still gotta stay part of the process. That's my key point. You can't totally divorce your— you can't hire a CTO and be like, you figure it all out. That doesn't work.

Or they might be able to figure something out to do with a particular challenge, but not for the entire vision of the product.

Yeah, they don't— whoever owns the product vision has still gotta be involved. And eventually over time, that can change, right? Eventually over time, but yeah, that's my key advice. Stay, stay involved.

You mentioned the AI prototypes and it's so easy to create a demo-like one.

Yeah.

But I'm assuming through Fullscale, you possibly also had to take something from a demo to an MVP to something that would scale in real life and deal with actual customers and money. And from your experience, what do people need to be wary of when they build these AI prototypes versus when they move them into production?

A lot of times it's the difference of like, how do things actually work and perform and scale? And it's easy to build a prototype and be like, okay, when I click this button, this thing happens. But when the thing that happens is actually like a whole series of things, it imports data, it does this, it sends an email, like, you know, there could be like a whole series of different things that happen. You know, that's a lot harder to do with AI, right? Usually you need a software engineer that's in the loop that's trying to figure out, okay, How do I map out the workflow and the processes? And how do I make this thing like work every day? Right? It's not just a pretty screen with a button on it. Sometimes AI can do that stuff, but there are times like that where you're going to get into the weeds of a lot of complexity. Like you mentioned Full Scale Ventures, we're building a couple, a couple products and we are using AI to rapidly prototype all the UI stuff. AI is so amazing at building UI related stuff, but we, our engineers spend a lot more of their time on how do we import the data? How do we import the data and do the data hygiene and all the processing and run these AI prompts and get the results of the AI prompts to put in the UI? Like our engineers spend more and more time like on all this kind of backend stuff behind the scenes. And we're able to use AI to do the, a lot more of the UI kind of stuff, especially.

And from a couple of the examples I've seen with the AI UI, and please correct me if I'm wrong, you tend to get like a static version of which then you still have to put into a particular folder. It doesn't give you like, say, the final icons or they're not like all exactly the same. You still have to refine them.

There's, that's the trick, right? So AI is so amazing at being able to build a prototype, but potentially that prototype still lives in a separate world, right? And I told our internal team one day, I'm like, hey, you have a problem with this internal project, take a screenshot of it, paste it into Lovable or Claude Code or whatever. Write some prompts and modify whatever you want it to do, and it'll build a beautiful prototype showing off whatever it is you want to do. And then, yeah, you could hand that over to the engineering team and be like, okay, make this work. I really want to move this button over here. I want it to be this color. And we're all like, thank God you finally made those decisions. And now we can just go implement it, right? But where the real magic comes in, and this is the struggle that we're all dealing with right now, is how do you take these product people, maybe not everybody, but some of them, and let them actually commit code right to production, where you have a product manager who is like, I'm not working in Lovable. I'm working in the actual code, the actual production.

Because that's where a lot of things can go wrong and a single update can take the whole system down.

And so then this is, this is a challenge and an opportunity, not only for product people that can very quickly iterate on things, but it's also junior developers. Now you've got junior developers that are doing this. They're rapidly making changes. But somebody needs to review their code too, right? And so the—

And is it gonna be AI?

Well, the, the challenge we have at a lot of companies, and you read about this a lot, is the senior developers now spend all of their day having to review everybody else's code all, all day long. They're like, I got 3 junior developers, I got this product manager, they're all writing prompts all day long, churning out thousands, tens of thousands of lines of code, and now I gotta babysit this crap all day long and figure out if it's any good. And so now it's like the pull review, code review process is the bottleneck. And at Full Scale Ventures, what we did, we were running into the same problem. You know what we did? We just said no more pull, no more code review. We're not gonna review any of it. Just let it all go. Ship it all. And part of the reason we said that is we're an early stage startup. We don't have any revenue. Why the hell are we trying to slow ourselves down? There's nothing to break. Just go, right? But that's different than in a big company. In a big company, You've got to have those layers of defense to prevent problems getting through. And Amazon famously, like 2 or 3 weeks ago, came out with some big thing about how this had caused big problems for them. They had some junior developers that were shipping stuff with AI and it was crashing and, and, and causing problems in production. And they had to implement more mandates around the review process and how junior developers are doing things. That's the problem is like we still need security and performance review and all these different things., but yeah, we've got to have AI do those too. You, I think you mentioned earlier in your writing process how you write something and then an editor reviews it and maybe another editor reviews it, right?

It's the same thing for 5 to 6 different stages before.

And so software development has to be the same way. It's like, we got to have it reviewed for performance and security and all these different things. Like we've got to have these.

So could you have then some final layer that goes through the human, but before that there's some AI layer that will validate it.

And, and no matter what, a human needs to be in the loop, right? Because if I'm at the start of this, think about it like an assembly line. It says, I want to add this feature. I want to add this button. I want to add this thing. I give it to AI and it does all this and maybe it goes through 4 or 5 steps. I still got to check it at the end and I can figure out, did it really do what I want? Do I like that? Do I want to move the button? Do I want to change the label? I mean, a human still has got to review it.

And I think it's— I'm interested to find out whether it's similar to the writing process. Sometimes, for example, you would point out to it that you've used this word 3 times, one after the other, and then you give it a task of localize what we would call surgical edits and fix it, but then it introduces something else that breaks something else further down the line, and then you still have to have the human overview because the machine itself has not picked up on that. Even a separate step afterwards to try and pick it up.

And I would say the best analogy is even though you use AI to help do writing, I use AI to do writing, you're still going to proofread it, right? Yes. So it's the same in software development. Like there still has to be somebody that proofreads the output, although it's a little bit less about proofreading the code. That's important too, but not as much as it is proofreading what it changed in the product. You know, did it actually change the product the way that we wanted and does it work? There's like a whole QA step that still has to happen. And the code is a little less important. And I know some software engineers don't like it when I say that, but if AI can write decent code, it can run all this code scanning stuff and make sure it didn't introduce bugs and introduce security issues. The job ends up being more proofreading how it modified the product. It's QA work.

Which is also very important and a new set of skills, but also what this creates and is going to take me to the next and possibly kind of like final topic of our discussion is You can create much faster with AI and everybody can do it to a certain extent.

Yeah.

So everybody can copy a feature or anything that's innovative just for a week before they can do that. So then there's the, what we would call the modes of distribution, taste, and trust.

Yeah.

And it's building those at the same time as your business and as your product. And you've been very prolific with that because you've had your podcast, The Startup Hustle, and I'm wondering now if you look back at it, because a lot of founders treat this content as extra, they see it as a chore, that PR, sometimes they outsource it as we know.

Yeah.

As we were speaking, what role do you think it played in your business?

Well, the marketing that we do has been usually beneficial for Fullscale all along. That's the reason we started a podcast 8 years ago. We used to invite local startup founders in Kansas City to come to our office and record a podcast and go to lunch with them. And like, that was a great way to build a relationship with them and get referrals, or they would be a customer later, right? Like we were doing those marketing activities for that reason. And then same thing with LinkedIn. Like I now have, I'm getting closer to 80,000 followers on LinkedIn. And like 3 years ago or 4 years ago, it was like 15,000, right? It was still, it was still quite a lot. But it's grown tremendously. Even back then when it was 15,000, you know, I could post on LinkedIn and I'd get a lot of responses and it would drive a lot of leads. And yeah, that, that sort of marketing is really important. And actually it's what has made Full Scale really successful is we've been able to build an inbound, like, marketing engine based on doing podcasts, newsletter, posting on LinkedIn. We've, we've been able to build that inbound engine where most of our competitors, people that work in IT, outsourcing and recruiting and all that kind of stuff, they almost all do outbound, like cold calling and stuff, which is brutally hard. And so that's what makes us unique is we have built this sort of inbound engine.

But isn't there a danger twofold there? One, that it's in a way reliable or too reliable on the founder's personal brand in terms of you hosting the podcast, but also the, um, Building on rented land, which is from your experience when you had 15,000 followers on LinkedIn versus 80+ thousand, do you actually reach more people now than you did when you had 15,000?

I think we definitely reach way more people. I mean, you're right. There's always the risk of, well, what happens if LinkedIn like goes away or kills my account or whatever, right? Like, I think there's always that risk.

Facebook did that. YouTube can do that very easily.

And so to that point, I've tried posting on Twitter, now X, and never had any success with that.

That changed. Yeah, that changed. No success. Absolutely.

I've never managed to have any success with that. I guess I haven't dedicated enough time to it or whatever.

I think that's it. That's the simplistic solution that is being sold because possibly there's a particular network that works better for a type of business.

And I think with all of these ecosystems, you've got to invest time in it is, I think. Part of the key feedback, like you were talking about how you use this, you use Substack and you use Substack Notes and I bet you get in there and you comment on people's stuff and you reply to their comments and you do all this kind of stuff. And I think that's the key, like, but you can't do that on every channel. I can't do that on Substack Notes and LinkedIn and X and Threads and YouTube and like all these different things and TikTok and whatever. There's too many channels. So it's like you have to figure out what channel works well for you. And I think all of them can work well for you. You just have to dedicate enough time to it, figure out which one makes makes the most sense. And for me, LinkedIn has always been, made the most sense.

But that's also where you've been the most engaged. Yeah. And, and spent most of your time and created real relationships in a community around.

And I would point out that's really the key. It's about building real relationships and it depends on the kind of product that you're selling, your service. But for Fullscale, what we do is all based on trust and relationships. And to do that, we really gotta meet people in the real world. That's the number one thing. It's like, we really only want to meet people in the virtual world so we can go meet them in the real world because that's where business is really done still.

Now, getting a bit reflective, Matt, you've sold twice. What did you misunderstand about exit before the first one?

What did I misunderstand?

Yes. About exits before the, before the first exit.

I mean, I think what is hard to understand is how it changes people's perception about you and relationships. Family relationships, family.

Is that because of the money?

Yeah. I mean, all of that is the part that's hard to understand.

Okay.

It has a dramatic effect on family and friends in an all negative way. No positive.

Is it because expectations change or?

Well, I mean, I'll give you an example. Like nobody invites me to their house. They know where I live. They know I live in a, in a super nice house. They're not going to invite me to their house. It changes weird dynamics with relationships with people., and it's like, if you want to go out to dinner with family, you're buying or you're going to Taco Bell, right?

Like, because it was public, the sale, the acquisition, the overall value.

I mean, it's family. They know. So it's like, you know, it just, it just creates all sorts of weird dynamics, right? You want to go out to dinner with your cousin or your sister or whoever it is. Like, you basically know you're paying or you're going to Taco Bell because that's all they can afford. Like, it just, it just creates all sorts of weird dynamics. It's hard to explain until you kind of live through them.

And I'm guessing they didn't get any easier with time either.

I'm not saying—

like for the second exit.

I don't— nothing's really changed for many of it over the time. I think in some way you, you figure out who your friends are and who your family really is. And like a lot of people, I have family members I don't even talk to. And your friends change over time. I think that's the big thing is you find, you find some new friends that you have. Different, you know, shared experiences with. It's a lonely place to be an entrepreneur is what I will say. It's a very lonely place. Very few—

Absolutely. Oh, everybody said that.

Very few people understand the problems that you're trying to deal with or the solutions to them. And you're just thinking at a different level usually, you know, you go hang out with some random guys and they just want to drink beer and talk about sports or something. And I'm thinking about like some crazy business problems and they just don't understand. Like they just don't relate at all. Right.

So how do you find your tribe? I know there's a Founders Group, which you're part of. And in a way, that's how we, we've been introduced.

So you have to find new friends. You gotta find new people you can relate to.

So it totally changed.

That's what I mean. It totally upends like some of the dynamics, like people that you were friends with your whole life, they're going to look at you differently all of a sudden.

And the second exit didn't change anything from a business perspective. Did it adjust maybe how you fine-tune a business, what you build next in order to say, make a sale or an exit easier?

Well, so the first time around I was the co-founder and then the second time around I decided I was going to go start my own company and I didn't want any business partners. And so that was a massive life lesson about going to be the CEO and really running a business and all that kind of stuff. A lot of really hard lessons learned from doing all of that. That was my 30s. I spent my whole 30s doing that.

Was that because obviously you were both on the technical side and on the sales side, the two roles that were separated in the first time round?

Yeah. Yeah. Learning, learning to run a business was because the first time I didn't really have to do that. I was really the product guy. I built the product, but I had other people that really were the, the CEO role.

And a lot of founders have had exited founders have had earnouts or they had to stay and implement the product. Integrated into another one. Does it feel like you're in a way sacrificing your baby, or is that— there must be parts that are unglamorous about that whole process behind the scenes where people don't see beyond the money, financial transaction.

I think there's a couple things there. Like people always ask, like, you know, it was your baby and you sold it and how does that make you feel? And what I usually tell people is like, she's not a baby anymore. It's like she's 21 and like, run out into the world and like has a boyfriend and like they're doing all sorts of things I probably don't approve of anymore. But at some point in time, you're like, I've done this for so long, it's not my baby anymore. After many, many years, it's like, I'm fine.

You learn to detach. Yeah.

You, you, you, you detach from it. You know, when you're first trying to get a startup going, yeah, you're very more emotionally attached to this thing. You're trying to will it into existence, right? Like you're the only one that has the vision to make this thing work and you're trying to just make it happen. And then eventually it takes a life of its own, eventually.

So finally, Matt, we've talked AI, we've talked product, and we talked what changes when you exit and when you rebuild. But when you look back, what would you say were the biggest sacrifices you had to make to be where you are today?

Wow. I think it's, it's ultimately it's time, right? It's time and it's relationships and I would, I would tell you to some degree, being a builder ended up being a coping mechanism, I think, for my previous marriages where I wasn't very happy in the marriage. And so I would avoid her and spend more time working on my business. And I don't know if you call that a blessing or curse or sacrifice, but it was just the reality. And no matter what, in the early days of being a founder, you've gotta put in the time. You're not gonna work 40 hours a week. You gotta do whatever it takes. You know, I always joked like I'm chief cook and bottle washer. It's like whatever we gotta do, we gotta do. And you just get used to that, right? But yeah, you, you sacrifice a lot of time and, and everything along the way, and that includes relationships. And, and I, I look back where it delayed how young I had kids. Like I waited to have kids a little longer cuz we were worried about the uncertainty of things. And probably the thing I sacrificed the most is just not spending enough time with my kids or as much time with my kids as, as I would've. Would've liked to, but I would, I would also say that's not entirely the fault of the business. It's because I also have ADHD and it's super diff— like most founders do. We do. Let's not lie about it. My brain is always thinking about something else. And so when I sit down with my kid, my ADHD doesn't want to sit down and play with Legos with them. My, my mind is thinking about some business problem or some idea or whatever, and that's difficult. And that's not necessarily because of the business. It's because of I have ADHD, but it's the combination of the two. My mind never stops. And so it makes it difficult at times for me to do things.

And for anybody who has been dealing with this, whether through diagnosed, undiagnosed ADHD, we know that detaching or kind of like temporarily putting the business aside just for a few hours when you're at home, were there any ways that you have found that have being efficient to do that?

The struggle is to be present, right? It's like, how do I be present? And at some point in time, it's really difficult for me to do that. But I think it's just trying to create a schedule for you that works. You know what I, what I have long did, it's like, okay, I work till 5 o'clock, whatever. I have dinner, I spend time with my family until bedtime. And a lot of times after bedtime, I would work, I would work more for years. I'd put the kids to bed and then go back to work for years.

You're not the first one to say that. Yes.

Yeah. So I think some of it is just trying to get that schedule of like, okay, I've got to focus. Like there will always be more work. And this is why I tell, I tell my kids this a lot because they're worried about how many episodes they watch of some TV show. I'm like, there will always be more TV shows to watch, man. Don't feel guilty because you haven't watched enough TV shows. It's the same thing with work. There will always be more work to do. There will always be more work. So it's like, at some point in time, you got to stop and you got to focus on other things. There will be more work and it will still be there.

But you put more focus on it at the beginning and then you learn to temper this and your brain as you move throughout the business and it starts stabilizing and growing. I think that's a really good idea to wrap up this episode on, Matt. The time sacrifices which have been universal throughout anybody who has built something from scratch and even so further down, but also to be able to detach from the business even for a few hours a day or a weekend in order to live the life outside. Thank you so much for sharing a lot of the wisdom and learnings that you've had along the way in your journey. And I think we're gonna have to revisit things a little bit later down the line and figure out whether AI is taking even more of these roles in the development process.

That's the struggle. We're all trying to figure it out, man. We don't know, like, how to build software anymore. We're all trying to figure it out.

Thank you, Matt.

All right. Thank you for having me.

Thanks for tuning in all the way to the end of this episode. If you enjoyed it, please share it with someone you think would get value from it. And don't forget to subscribe on YouTube, Spotify, or Apple Podcasts so you never miss an episode. For the best way to stay in the loop, head to millennialmasters.com. That's where you'll get all the latest features and new episodes straight to your inbox every week. Catch you next week.