Into the Gnar, Episode 1: A Software Podcast for Operators, Not Developers

Most software podcasts are built for developers. Ours isn't.

Into the Gnar is for the CEO, COO, or operator who knows software matters and keeps getting burned, confused, or left behind when it's time to build it. Nick and I have spent ten-plus years building software for everyone from scrappy startups to hundred-million-dollar operators, and we keep watching smart people make the same expensive mistakes. Not because they're bad at their jobs. Because nobody told them what they needed to know before they started.

In episode one, we get into why we started the Gnar, what a product consultancy actually does now that agents produce most of the code, and the biggest lie non-technical leaders get told about software: that it's a one-time capital expense instead of a living thing you operate. We also react to two stories from the news: Claude Code overtaking GitHub Copilot as the most used AI coding tool, and MCP crossing 97 million installs. And we settle nothing in the great Starburst debate.

Watch the full episode above, or read the complete transcript below.

Key moments

• 0:00 Who this show is for
• 1:20 An employee told Mike to back off, and why that made his week
• 3:30 Immerse: the AI fluency curriculum that came out of our AI working group
• 5:20 News: Claude Code passes GitHub Copilot as the #1 AI coding tool
• 9:45 News: MCP hits 97 million installs. Are the protocol wars actually over?
• 15:00 Why we started the Gnar
• 19:55 What the Gnar does today, now that agents write the code
• 22:10 The real problem with offshore teams (it's not the one you think)
• 26:40 The biggest lie in software: treating an OpEx like a CapEx
• 31:30 Slow is smooth, smooth is fast: what moving fast actually requires
• 36:05 Who this podcast is for, and who it's not for
• 38:38 Rapid fire: dream builds, Claude, and the Starburst argument

Full transcript

This transcript has been lightly edited for readability.

‍

Mike: Most software podcasts are built for developers. This one isn't. Into the Gnar is for the CEO, COO, or operator running a real business. Someone who knows that software matters and keeps getting burned, or confused, or left behind when it comes time to build it. I'm Mike Stone, one of the co-founders of the Gnar Company, a custom software development agency based in Boston. With me is my co-founder and co-host, Nick Maloney. We've spent the last 10-plus years building software for companies of all sizes, from scrappy startups to hundred-million-dollar operators and beyond. And we've seen the same mistakes made over and over. Not because the people making them are bad at their jobs, but because nobody ever told them what they needed to know before they started.

‍

And that's what this show is. Into the Gnar, where the cutting edge of software gets built. We're gonna talk about real builds, real decisions, real consequences. The moments where things went sideways and how they got back on track. We're gonna bring in the operators who lived through it, not the consultants who wrote about it afterwards. And we're gonna do it in plain language, because the gap between how software gets talked about and how it actually gets built is where most of the damage happens.

‍

This is Into the Gnar, and this is episode one. So Nick, coming into today, launching a podcast, we took it upon ourselves to think of something in the last week that reminded us of why we started the Gnar. And I actually had a funny one that's related to the Gnar and how much I love this company. I got totally put in my place by an employee in the last week, and it was awesome. It got me so excited. So we have this AI working group. Obviously Nick, you know about that. And we use that working group to keep pushing the boundaries of our agentic development practice.

‍

But I'm tangentially involved. Nick runs this group, and I tend to jump in with a lot of opinions. There's somebody on our team who's leading this initiative, who has a quarterly goal around this, and I was coming in, firing off with all my ideas, and he just kind of looked at me and told me to back off. I've got this. It immediately hit me like, yeah, you do. You're good. You don't need me for this at all. But it got me so pumped, because it just shows how great our team is. Confident, capable. That's our core differentiator. The code production and all that is table stakes.

‍

Anyway, that was a full circle moment for me, 'cause I've always loved being on teams, and to have somebody just be like, dude, back off, we're good to go here, just really made my day in a weird way.

‍

Nick: Nice. Yeah, I'm enjoying those sessions that we have. We've got a good team on board there, and just learning from everything they're experiencing working on client projects is really cool. Like we're not just sitting around and ivory-towering it. It's based on things that worked and haven't worked, and building a plan around it. That's probably a good segue into what I'm thinking about on this topic, which is really the autonomy we have to pursue things, whether it's offerings or product ideas, based on intuition, data, our own experiences. I just got out of a meeting five minutes ago on our AI fluency program that we've been launching. There's a clear need in the industry as a whole, because it's the Wild West.

‍

That's all everyone hears about. But there still needs to be some structure and definition in the learnings, and we have a spectrum of usage across our team. I think we're very adept at it, but not necessarily in a uniform way. So being able to take a step back and say, let's build a curriculum around it. And it came out of that working group that you just mentioned, that we're able to use the team's experience, build a curriculum that we believe in, and then enroll our own folks in it. That is really exciting. And just being involved in it, but at the same time taking a step back.

‍

I'm not an instructor, and we have folks on the team that literally have a background in that. It has been really cool. And just talking to people about it. Like I said, I just got out of a call. They're really excited about it, and there's a lot to come from that.

‍

Mike: Yeah, that's awesome. Definitely keep me far away from that group before I come in and ruin it with all my ideas. But one thing I know I can't help out on is the naming side. That's always been my weakness. I don't know, did you guys land on a name for it?

‍

Nick: Like a 200-message Slack thread that went full circle to, I think, the original name that we came up with: Immerse.

‍

Mike: Nice. Yeah, it's the hardest part of all this, the naming. But I like Immerse. That's a good one. Awesome. All right, so we're gonna move into our first segment and talk about news of the week. We've got two stories loaded up. First is: Claude Code just became the number one AI coding tool, overtaking GitHub Copilot. A major developer survey from The Pragmatic Engineer confirmed what a lot of teams have been feeling. Claude Code, which launched less than a year ago, is now the most used AI coding tool among professional engineers. Among engineers at smaller companies, 75% say it's their primary tool. GitHub Copilot, which had years of a head start, has been overtaken. The same survey found that 55% of engineers are now regularly using AI agents, not just autocomplete.

‍

This is a fundamental shift in how software actually gets built day by day. That's our first story. I have an immediate reaction to this, but Nick, I'll hear from you first, 'cause you're more in the weeds on this stuff than I am. What's your reaction to this story, and what does this mean for a CEO who's hiring a development partner right now?

‍

Nick: My initial reaction is, I am glad to hear this, because I just put I think $15,000 worth of Claude Code licenses on our Amex. So we are firmly aligned with Claude Code being the best tool available right now for developers. To be tempered, I'm surprised it's overtaking GitHub Copilot. I would've thought Cursor or another more sophisticated agentic tool than Copilot.

‍

I'll leave it at that. Needless to say, we're all in on Claude. No shade on Cursor. It just speaks to a broader swath of our team, because it's not just Claude Code, which I really like in the direction they're headed, but Claude Desktop and the capabilities that it provides with integrations and ease of use for other folks on the team. Whether it's sales, HR, full-on integration. I just think of it as an ecosystem play, and then we get the added bonus of having the best agentic coding tool available right now.

‍

Mike: Yeah, you touched on it. My WTF moment with this headline is not the Claude Code part, but the GitHub Copilot part. Like, I am amazed that GitHub Copilot was the most used agentic development tool. I haven't thought about Copilot in over a year outside of PR reviews. And to me, if your development team is still talking about Copilot, they're multiple generations behind.

‍

Yes, you can check the box that you use AI, but you are not far along. And that was super surprising to me. A few steps in the past in my mind. So that was surprising. Almost as surprising as our Claude Code bill.

‍

Nick: Yeah, we were just talking about that on Slack earlier this week, about how we have historically used Copilot to do PR reviews. And then we set up Claude Code and it was just ripping on Copilot's PR reviews, and they were duking it out. And needless to say, Claude's were better. But for me, this is the nail in the coffin, 'cause I think they wanted another 30, 50 bucks to use Copilot, and there's no need anymore, 'cause we can just have Claude agents do our PR reviews.

‍

Mike: Nice. That reminds me of that fun exercise where we put the agents against each other on how they would characterize the other LLMs as characters in The Office. Who was it? It was like Grok, GPT, Claude, maybe Copilot was in there, I forget. But everybody was throwing everyone else under the bus, and everyone wanted to be Jim Halpert. And I think Claude was actually the only one that didn't put themselves as Jim Halpert. And that's when I was like, you're my guy, Claude.

‍

Nick: Yep. So it's good news.

‍

Mike: All right, moving right along. We've got our second story of the day. MCP hit 97 million installs. The agent protocol wars are over. The Model Context Protocol, the standard that lets AI agents connect to external tools and data sources, crossed 97 million installs in March. Every major AI provider now ships MCP-compatible tooling. Adobe, Salesforce, SAP, and Atlassian all announced MCP integrations at NVIDIA's GTC conference this month. The standard has won. Again, Nick, I'll go to you. From a practical standpoint, for a B2B company, what does this actually mean? Being able to connect to all these external systems, what gets better and what gets dangerous here?

‍

Nick: I think it's good that there's a standard defined for all of this. I wouldn't say my take's contrarian, but I don't think that MCP is this magic wand that just solves all of the things. In many cases, an API negates the need for an MCP and is a cleaner interface. If you have a very direct need to interface with a product, just use a very well-defined RESTful API. However, for some of these larger products, particularly enterprise SaaS, where some element of discovery is needed, I think it makes a lot of sense, and I'm glad that the larger application suites have that. But at the same time, I don't think this is a green light for everyone to just default to MCP.

‍

I was literally working on a feature recently, and even conversing with the agent, the agent advised me, said, no, that's overkill. It's actually a layer of indirection. So not trying to go off on a tangent here, because I think it's a good thing, but when we were reviewing this, it did make me think it's not the magic bullet for everything that we need. I think that's part of the discussion. Do you actually need one? And having an understanding of when they fit in. I almost view it as when GraphQL first came out. Everyone was just throwing GraphQL on all of the things, and it really complicated a lot of simple apps.

‍

It's, you ain't gonna need it, just use an API. And I think this is different, but it's a similar flavor of that. It's a tool, and when used in the right scenario, it absolutely makes sense, but it doesn't necessarily need to be the default for everything.

‍

Mike: Yeah, I like that analogy. I think that's spot on. And I think that's gonna be the challenge in this podcast, because we think very similarly about this stuff. It's a little different than your take, but my take here is I would not call the protocol wars over. We're still in this period where every week there's the new hotness, and I don't think that's gonna stop for a long time.

‍

MCP is the best tool right now for some of these connections. Like you mentioned, it's not the only one. CLI tools are gaining a lot of momentum. Simple APIs are still great to use within agents. But there's inefficiencies with MCP around token costs and token volume.

‍

It wouldn't surprise me if it's a thing of the past a year from now. It also wouldn't surprise me at all if they solve these problems and it becomes even more of a standard. So I'm waffling right in the middle and not picking a side. But if I were to pick a side... shoot, do I want to pick a side? Listen, I'm gonna take the jump. I'm gonna pick a side. I think a year from now, MCP is not as big as it is now. I think there's gonna be a lot of evolution in external connectors.

‍

Nick: Or it's a layer removed, where skills, Claude skills, or agent skills as the generic version, abstract this so you don't know, and they just default to using APIs. Another tangent, which is probably another topic for another day, is the interchange format too, right? Where a lot of these are JSON, and now there's things like TOON, which are optimized for token spend. So I think we're gonna see more of that. And that's probably a good topic to address separately, token optimization, because it's becoming such a real problem for businesses, your burn on token spend. And that's gonna continue to go up. I think I read today where people are predicting that token spend is gonna outpace engineering spend within the next few years as it becomes more ubiquitous.

‍

Mike: Yeah, we were talking about that earlier this week. It's only a matter of time before we're spending a full-time salary on tokens. But yeah, enough with the news already. Let's talk about ourselves some more. This is our first podcast and we get to talk about our company.

‍

Let's get back to the beginning, so that the dozens of listeners, our parents, who are listening can hear from us exactly why we started the Gnar in the first place. Nick, what are your thoughts here? We've obviously talked about this in the past. We've gone through this since the beginning. But there are maybe some questions we can prod into that we haven't ever really addressed directly between us. Was there a specific moment that made you think, I have to do this differently? Or were there things that you were seeing in the industry at the time that you knew were wrong, that you wanted to solve for?

‍

Nick: I don't think I'd phrase it as I saw things that were necessarily wrong, but at the same time, I definitely saw there being a demand for companies to establish engineering best practices. And our origins are from when there were a lot more startups and a lot more VC money at the early stage, and it's a fire drill. And this still holds true now: you can still ship software fast and follow best practice. And we knew that. We came out of companies that had that in their engineering culture. That was a big reason I wanted to start the Gnar, that we could work with companies to still establish best practices, do things right, but at the same time still ship their product, go to market, generate revenue, and not sacrifice quality and have systems that break and keep them up at night. That's it in a nutshell, anyways.

‍

Mike: Yeah, for sure. And I guess again, for the listeners, Nick and I worked together at a Boston startup before starting the Gnar. But I agree with you. We worked at a place that had an amazing culture, talented people, everything was done right. That job for me was kind of my intro to startups and tech. Nick's more experienced than I am and more technical than I am, and I lean on him a lot. But I came in pretty green and just assumed that was the way that it was. Then I found out through experience that it was not as normal as I had assumed.

‍

I think most teams cut corners thinking that it makes them faster. But we really saw the opposite from our experience. It's the great people and the great process. You don't have to cut corners to move fast. You need great people, you need great process. And that's what creates speed in the end.

‍

To me it was like, how do we package up this way of working, where we can deliver such high quality at high speed, and offer that as a service. Do you think any of that has changed over the years? Like today, do you think that all still holds?

‍

Nick: I think that is a great question. And I think yes, it absolutely still holds true today, but things are shifting rapidly, and there's less of a clear definition around best practice. It's narrowing quickly. But I feel like when we started, there was a corpus of knowledge. Agile was well defined, the tools we were using were well defined. Now it's a little bit of the Wild West, and people are trying to figure out what the best practice is. I think we're taking what we know and applying it, but it's definitely not as defined as it was when we started.

‍

Mike: Yeah, I think the core still holds. And you see this all the time with AI slop these days. Bad inputs equal bad outputs. And that was core in the olden days when we'd write code by hand, and you were thinking about some of the best practices that you're talking about, good clean code, well-tested code.

‍

And I think that still exists today with agentic development. It's just a very different approach. Like you said, we're still writing the book as we go.

‍

Nick: Yeah, you're training the agents to follow the best practices that you used to practice. And yeah, I think it absolutely holds true. It's just your role as an engineer is shifting, where you're more of an instructor and enforcer of the best practice than an implementer, in regards to code quality and things of that nature. Mike, on that theme of how best practices have evolved in 10 years of business, how would you describe what we do today? You don't necessarily have to compare it to what we did 10 years ago, but what do we do today, in this new world that we live in? If folks were to quickly ask, hey, what does the Gnar do?

‍

Mike: I think we are a product consultancy. I would say that's been the case throughout. We've always been a product consultancy. We take an idea from concept through development and maintenance. But now, what I think is a really exciting change in the industry is that the thing that actually matters isn't the code. Anyone can produce code now. The agents do that. The humans don't even do the code production. What we do is shape the product. And I think that's always been the case. It's just that there's been more value on code production in the past. Now we can be really squarely in this position. And it helps that we are a hundred percent US-based.

‍

It helps that we have only senior talent on our team, because we are in a perfect position to help shape these products, working with founders and executives to take their idea, size it to a budget, turn it into an MVP that's actually viable. We've always said this: the client brings the domain expertise, we bring the product expertise, and we marry those two things together.

‍

So I think the changing industry is benefiting us in a lot of ways, because we've never been the company that says yes to everything. That's how most software projects fail. We say no a lot. We help clients see around corners. That's always been a part of our positioning, and now it's much more so.

‍

Nick: And moving at a faster clip.

‍

Mike: Yes, that's been an insane part of it as well.

‍

Nick: Mike, you had just mentioned that we are a hundred percent US-based. In the olden times, we had an office in downtown Boston and we had that very tight collaboration. Now we're a distributed team, but we're still US-based. You touched upon that. What would you say the advantages are for us having retained that philosophy?

‍

Mike: Yeah, we have to compete against offshore teams and non-US-based teams all the time. And a lot of our work comes from clients getting burned by an offshore team. But I would always say it's not actually an offshore problem, it's a product problem. The technical competency itself has really never been the differentiator.

‍

There's great developers all over the world. I think the differentiator is shaping the product and being able to have direct conversations with the people building. Having the courage to say no to an executive and a stakeholder. Taking a vision and crafting it into something viable.

‍

And I think that just naturally breaks down with distance and team structure. You need to be talking to the people that are building in order to communicate the vision appropriately. You need to have a lot of overlap in your days to be able to check things in real time and keep things moving forward.

‍

I think that's been a huge key to our success. At first being mostly based in the Boston area, and now being remote, but having that overlap in the working day, having everyone on our team in direct communication with clients. I think that helps us craft the product in ways that you can't from certain structures and distances.

‍

Nick: Yeah, that tracks with my philosophy. And I think it really boils down to communication. Even when you say no, and I've been on many a project where you essentially have to say no, there's a level of tact to it, right? Our team is giving them information and guiding them toward informed decisions, and saying, here's the options you proposed, but here's the data, and my recommendation is doing it this way, and here's why. It's not a "no, we're not gonna do this." It's, here's my recommendation based on what I'm hearing and what the vision is for the product. And I think that communication really helps versus just going async. 'Cause I've definitely worked on collaborations with other teams where you wake up in the morning and you have a bunch of PRs and a bunch of work, and there's just a lot of churn, because everything happens asynchronously. Where if you could all get in a room together, especially if you're in person or in the same time zones, things happen a lot more smoothly and a lot more quickly.

‍

Mike: Yeah, like you're scrambling to get to your desk in the morning because you have one hour of overlap with the other team, right? And you need to ask some questions, and then of course some part of that conversation misses the time window, and now you gotta wait till tomorrow for your hour of overlap. It's like a mad scramble, and every one of those conversations is a day delay on getting the product shipped. So that is a problem with offshore. But I've seen so many rescue projects from onshore companies too, where I can look at their app and immediately just be like, you said yes too much. You just waved in all of the features, and now this product has way too much going on. The UX is bad, nothing quite works as you expect, because they needed to work within a budget to get all your crap in there. So it's definitely not exclusive to offshore. Part of it is the communication, and part of it is the experience.

‍

Nick: Yeah, the level of discipline required for good product management and stewardship.

‍

Mike: Yeah. All right, we're gonna move into another section, talking about what we believe in. Let's get some hot takes here. What's the single biggest lie in the software industry for non-technical leaders?

‍

Nick: I wouldn't say there's a single conspiracy or lie here. I'd phrase it differently, but...

‍

Mike: You are so conflict-averse. Let's have it, Nick.

‍

Nick: I'll put the gloves on when it's warranted, but in this case, no. I think one thing that I have seen, and I've even seen it this week, is thinking of software as a CapEx over an OpEx. A capital expense, versus a continually operating, living, breathing thing. Software evolves. It needs to shift with the market or it will die. And the definition of done is not, I spent $50,000, this thing's done, I'm never gonna touch it. There's a window in which products are viable and done, but they need to shift with the marketplace. I think it can be boiled down to exactly what I said: software is an OpEx and not a CapEx. It's something that your organization operates. I have never seen a product that doesn't evolve over time. Name one. The time horizon might shift. Windows is a good example, but it's always innovating. And I've seen frustration, because we've had stakeholders say, I've spent this much money, I'm done. And then three, six months down the road, something in the industry changes and it needs to evolve, and there's been a lot of tension there.

‍

Mike: What does your crystal ball tell you in terms of what we're gonna see in the months and years to come, with all the vibe coding and non-technical folks building software product?

‍

Nick: I think it speaks to it even more, because there's gonna be discipline needed to not just say yes to everything, because code is so cheap to produce. The ability to ship features faster is at a level never seen before. And you think about a lot of the larger incumbents that might be more hesitant to innovate. This is gonna lower the barrier to entry, so they're gonna need to operate more quickly and have more features delivered faster. And they can't just have a fixed capital expense on a piece of software, or they'll be dead in the water.

‍

Mike: Yeah, totally. The ease of producing apps now means that you have people that don't know how to shape product trying to shape product, and just adding tons of complexity. That was actually my answer to this. Not that the ease is bad, it's fantastic. But simple is not easy. It's the hardest part, because mostly the non-technical folks that we work with as stakeholders, they want all the bells and whistles. They want so much complication when they're just starting out. And we really focus on simplicity. Sometimes in those conversations you get a little pushback.

‍

It's almost like they feel like simplicity means that you can't handle the complexity. In reality, every project is complex. That's just what's going to happen. But having the discipline to make each piece of the complex system as simple as possible provides the flexibility for the code base to be extended and more easily maintained.

‍

But that's the key point I think you touched on too. The maintenance piece is just not considered. People don't think about the ongoing cost, or just the ongoing needs, of a software product. It's not like a house where you just build it and then it exists. Even though, bad analogy, houses need a lot of maintenance too. But building is like chapter one. If you need your software to survive for years, you need to maintain it. And simplicity enables the code base to survive. So there's definitely overlap in how we're thinking about that.

‍

I'm curious if there's anything in your mind around what moving fast in software requires. Is there anything that we do on day one that other agencies skip? Anything in our secret sauce, or not-so-secret sauce, that enables it?

‍

Nick: I think our commitment to following best practices. And that's not us being pedantic or not adaptable. But by setting things up properly, it allows us to move fast and not break shit. If we're setting up a greenfield project for agentic development, ensuring that we have CI/CD set up, and test suites, that will put on guardrails to make sure that as we're shipping software so much faster, it's doing everything from linting to make sure that code's not breaking, to regression tests. Taking all of our knowledge from mistakes made on things that we've broken, and codifying that into a process on day one. And that's not to say other folks don't do that, but I think that's an area we pay close attention to, so that we start a project correctly. And along the way, we have that confidence that we're able to move fast. And then at the end, we're not scrambling to QA and find all the bugs and regressions that will happen if you don't follow these best practices.

‍

Mike: Right. And we borrowed the phrase from the Navy SEALs for this: slow is smooth and smooth is fast. If it worked for the SEALs, it should work for us. But I think a lot of those best practices that you mentioned, that's where the corner cutting comes in at other organizations that think they're moving fast. They'll skip tests or skip PR reviews just to ship the feature, thinking that this is how startups work, this is how you move fast. And then six months later, they're spending 80% of their time on bugs and rework. There was no time saved in the long run.

‍

It's almost like you're just borrowing at a terrible interest rate. The other thing that came to mind when I was thinking about this question was recency bias. I've seen this a ton, and it absolutely kills speed. Every feature in the backlog becomes urgent, or you get pinged on Slack: hey, we need this feature ASAP. Not really considering that at one point, every feature in the backlog was the most urgent thing. It just causes thrashing in the process. Speed is actually having a process, and maintaining that process and its priorities, and then you can just crank through the work. That's another one that comes up in projects over the years.

‍

Nick: Yeah. And I gave a very engineering-centric response here, but one area that we've found is super important, especially in agentic development, is requirements clarity and context. Because one bad line of context is probably a hundred lines of bad code. Performing all of that due diligence upfront, and making sure there's clarity around what the product is, what it needs to do, how it needs to operate, is so important. So then the robots can go off and build it. And I think that speaks to what you brought up around the backlog. 'Cause if things are just being thrown in ad hoc, it means there wasn't enough time spent upfront to define what the product should do and what should be prioritized in that backlog. And we've spent a lot of time honing our process and building out really robust PRDs and the corresponding context documents that go with them, that can then be fed into the agentic workflow. And it saves so much time. It seems like it's slowing us down initially, but the speed boost on the dev side is orders of magnitude faster as a result.

‍

Mike: Yeah, I totally agree. And it's been interesting as we think about this podcast and what we want to do here, because these are topics that we could talk about for hours, right? We could have a podcast talking about the technical details of all of this, and being software developers, get into the nitty gritty. But it feels like there's a bunch of that already existing. I'm thinking about, as we're planning this show, who's it for and who's it not for? To me, it's not really for developers. It'd be wonderful if developers tune in and like it, but there's so many podcasts for developers out there, YouTube channels, everything in between.

‍

I've just been having so many conversations with friends who are in private equity, or are operators at large businesses, and they're all in scramble mode, trying to figure out where the industry's moving and not sure how to get there. Or they've been burned before. So many of our clients have been burned before and are trying to trust a new partner.

‍

And it just feels like that's a gap. There's not many shows out there that will talk about: here are the real challenges, here's probably what's happened to you in the past, and real ways to get out of it. And so that makes me excited. I got into software a little later in my career than you did, and before that, while I was learning, it was super intimidating and I was confused all the time.

‍

These are the types of conversations that I'm now coaching my friends through. And if someone would just explain this in plain language, they'd be able to make decisions. So to me, this is just an effort to bring that forward and talk in plain terms about complex topics that are top of mind.

‍

Nick: Yeah, I completely agree. As much as I love nerding it up and taking a technical deep dive, I think there's so much value in talking about our experience in the trenches, and surfacing what all of this means and what the impact is from the business side of things with these tools, and what we're doing in the agency space, and how it can be applied for folks more on the business side of things.

‍

Mike: All right, so we're coming up on time, and we're just gonna rip through some rapid fire questions. These are things that we're gonna be asking some of our guests, and we're gonna dogfood this by answering them ourselves. Our first one: if you could build any piece of software in the world, no constraints, unlimited budget, what would you build and why? I'll kick us off. At first I got on my soapbox and I was like, end world hunger, world peace, something about that. And I was like, that's too big for software and way above my pay grade. So I dumbed it down all the way to: I just sold my house and bought a new one. So I want an app where I can take a video of both houses, and it'll design the new home with all of my stuff in it.

‍

Anything that doesn't work can go straight on Facebook Marketplace, and anything I need, it'll just give me the options for everything, and done. What do you got?

‍

Nick: That's actually a really strong idea. I know my wife would appreciate that, and there would be a whole lot of items on Facebook Marketplace. So good idea. I'm just hesitant because I know the impact of it. There's a lot for me on this one. One big one for me is just a better communication platform. Right now we're using Google and Slack and occasionally Teams. And I'd rather fax people than use Teams. It seems like such a solvable problem, but there's nothing out there that is really good. We use Slack and Gmail, but there's so many gaps there, and I feel like there's a lot of opportunity to innovate in this space. If I had unlimited resources, I'd put my hat in the ring and give it a go.

‍

Mike: Nice. All right. ChatGPT, Gemini, or Claude?

‍

Nick: Claude, by a mile.

‍

Mike: That's an easy one. What's one piece of software that you genuinely cannot run your life or business without?

‍

Nick: Probably Slack.

‍

Mike: See above.

‍

Nick: Yeah, exactly. For better or worse, it keeps the entire team connected in real time. It can be a distraction, but I don't know where we'd be without it, being a remote team.

‍

Mike: For me it's Claude. I use it every day. I can't operate without it.

‍

Nick: That was my other one that I had on there too.

‍

Mike: And the easiest rapid fire question of the day: what's your favorite Starburst flavor? I think we can both agree, it's obviously pink.

‍

Nick: We know I'm Team Orange. I'm a weirdo. Orange, red, pink, yellow.

‍

Mike: That's just wrong. And this was actually Nick and I's first argument. That's when we started the company. We were buddies, colleagues from the past company, and we just aligned on kind of everything. And then one day somebody had Starburst, and we got into this conversation. I guess it's a good problem to have. We gotta disagree on something, and let it be Starburst flavors. But you're still wrong.

‍

Nick: I love it, because my family is Team Pink, so I get all of the orange Starbursts just given to me. So it works out quite well.

‍

Mike: Yeah, because your family, they get it. All right. Before we close out, Nick, what's one thing you've seen in your career that made you want to make this show?

‍

Nick: So this is very recent, and I will preface it by saying we are guilty of this. But right now, generating content is essentially free. If I go on my LinkedIn feed, or blog posts, a lot of it is good content, but there is just so much of it, and it's hard to discern real conversations and human voices. Admittedly, I won't say I had cold feet, but I've always been a little hesitant on pursuing a podcast. But I think it's gonna become more important to have real humans talking, and not just AI-generated marketing material out there. It's an opportunity for unfiltered human voices that aren't gonna be watered down or vanilla because you asked AI for the smoothest or least offensive way to say something. Not trying to be offensive there... friction-free. But I think having these unscripted conversations is just gonna be more and more important, to differentiate yourselves and just have good conversation.

‍

Mike: Nice. All right, that's episode one. If you found value in it, come back next episode. And as a small favor to us, please consider telling a friend or sharing it on your socials. We'll be here every other Monday. Leave us a comment and tell us what you wanna hear next. What decision is keeping you up at night? What question do you wish someone would just answer plainly? That's why we're here. And if you've been wondering whether your team's actually set up to use AI, we built a free two-minute AI assessment at ai-assessment.thegnar.com. It gives you a straight answer and tells you exactly where to start. Link is in the show notes. See you in the Gnar.

‍