We Live to Build Logo
    34:582025-04-22

    AI Can Write Code, But It Can't Do Architecture

    In this interview, Matt Strippelhoff gives his expert take on the current state of AI coding tools. He argues that while AI can write functional code snippets, it lacks the big-picture thinking needed for software architecture. Matt warns about a hidden legal risk: AI might incorporate open-source code that could force your entire software to be free. He also shares how his company broke through a $2M revenue plateau after 10+ years, and explains the "consultant's dilemma" that keeps many tech businesses small.

    AI DevelopmentSoftware ArchitectureTech Business Growth

    Guest

    Matt Strippelhoff

    Partner and CEO/CRO, Red Hawk Technologies

    Chapters

    00:00-From Graphic Designer to Coder in 1994
    05:01-The Evolution From Dreamweaver to AI Assistants
    08:07-AI Can Write Code, But It Can't Do Architecture
    12:45-The Hidden Legal Risk: Your AI Coder Might Make Your Software Free
    17:10-Why the "Source of Truth" Is a Nightmare for Dev Teams
    21:13-How We Broke Our $2M Revenue Plateau After 10+ Years
    25:30-The "Consultant's Dilemma" That Keeps Your Business Small
    28:15-The Hard Decision: Giving Up Equity to a New Partner

    Full Transcript

    Sean Weisbrot: Matt Strippelhoff is the partner and CEO of Redhawk Technologies, an American software development firm that helps companies develop complex applications. And in this conversation we talk a lot about AI and business processes and growth and lessons learned in the process of growing our businesses and changing ourselves so that we can adapt, so our businesses can grow. If you're looking at software or ai, this is a great conversation for you. Let's get to it.

    Matt Strippelhoff: What made you wanna get into software development? Started out in my career as a graphic designer, and this is just when the internet started taking off. Um, graduated from the Art Academy of Cincinnati with a BFA and communication design. So I had this inclination to create and be a designer and, uh, thought I wanted to be a fine artist, but I didn't wanna be a starving artist. So I focused on communication design, which led me down the path of working for small graphic design studios and agencies in the greater Cincinnati region. Um, but I produced my first website in 1994 using Netscape Navigator. That browser actually had development tools built into it. We didn't have what you see as what you get editors. We didn't have all these powerful tools that developers have today. So I learned how to do coding just to create some interesting visual effects. Produced a website for the agency that I worked for at the time. And I thought, wow, this is really cool. It's kind of taking, um, uh, sort of a, a science, you know, techie kind of a mindset and combining that with the arts to create some experience for the end user. And that led me down that path. And before I knew it, I was designing user interfaces for complex web applications. A few years later, I

    Sean Weisbrot: learned how to code HTML, not like terribly proficiently, but like. You know, breaking lines and changing font colors and sizes and weights and margins and padding and, you know, these kinds of things. I know some of that gets into the CSSI got involved with that, probably high school. It's like two, like late nineties, and I took a CI took, I took a c plus plus class in high school because my brother convinced the, the. Tech teacher for the school that I already knew, visual Basic, that he taught me it, but he hadn't. And I only passed the c plus plus class because I copied off of my friends because I actually was not interested in coding. I, I knew from a very early age, I didn't really care. Uh, my actual goal was to get into the networking class, which was an elite club that the teacher managed. Of students and our goal was to make sure the entire network of 1400 computers in our school were working properly. And that was a lot of fun. I really enjoyed that. It all got really deep into hardware and, and networking standards and land cards because we didn't have, you know, we didn't have, uh, wireless or Bluetooth or anything like that yet. Um, but then instead of going into computers, I went into psychology. I was like, I learned so much about tech that I know I don't want a career in tech. Because in my mind it was all about coding, which was boring and networking, which is a ha, you know, hard to do. Um, because of all the problems. There's constantly problems, right? It's never like everything is working smoothly. There's something is always breaking. Um, so I didn't wanna that, so you get into software development. You've been in software development for 20 ish years, how have you seen it change? And I guess that's more towards now where AI is coming out and being. More relevant

    Matt Strippelhoff: in, in the process. The pace of change right now is insane. I'll just say that it, it took, it was a little bit of a, we saw a lot of progression in those early, you know, nineties to late nineties when tools started coming out into the marketplace to make it easier for designers to code. You know, what you see is what you get editors. The Dreamweaver Tools, Microsoft Front page was an early iteration of a, what you see is what you get editor. And uh, those tools were meant to expedite the development process by removing the need to manually code a lot of stuff. If you think about it, it's. It's a lot of, um, editors that gave you the ability to affect or implement CSS and styles and templates and, and stuff to, to make it faster to produce what you wanted the user experience to be. The same thing was happening on the back end, but that's not the world that I came from. I was more on the front end, um, design and engineering side of things. So today I think what we're seeing is just the, the, the pace of which AI tools are now coming out to basically do the same things to expedite the development process. But now, instead of utilities, you know, in a control panel or dashboard that you, you're using to put things together where it's doing the, the coding behind the scenes based on what you're clicking and what you're selecting. Now you've got natural language prompts that you're using through these AI tools to generate code, which is, which is pretty fascinating. Um, so that's, that's definitely gonna have a big impact on the business as we continue to grow.

    Sean Weisbrot: I used Dreamweaver and Front Page a long time ago, and then it was kind of replaced by Live Journal, which was then replaced by WordPress, and I've used WordPress since its early days. And then I got like divvy theme. Which has been really helpful for moving element blocks around, but you still have to code. You don't have to code 'cause it's visual, but there's still a lot of tweaks you have to do. You still have to pay someone to design your website or something like that. And then when I got into my own tech company, I got into Figma, which was really cool for designing stuff. And they can give you the code and you just copy the assets and give the code to your tech team. And now I'm able to code entire front end and backends with natural language prompts using a tool called Lovable, which I mentioned to you previously. And as a non-technical person who's not a designer, not a coder, but has visions, can I can, I can imagine businesses. But before I'd have to hire people and spend a lot of money. Now I'm capable of doing it all myself and, uh. If I had access to these tools when I had started my tech company five, six years ago, it would've been far faster and far cheaper to get anything done like shockingly. So for me, um, the difference in, in just a few years is huge. How are you using AI in your business? How are you thinking about it?

    Matt Strippelhoff: My role in the company is CEO in driving the growth and, and strategy. We think about AI a lot. I think about it, I'm sure, very differently than, than the boots on the ground, the engineering team, the principal engineers who are driving, what tools that we're using. Uh, so I, I can speak a little bit about what they're doing in the trenches right now. We're using a lot of proven AI solutions like Microsoft copilot. There are a few others that we're using as well that, that ride along as an agent. It helps them expedite the process of writing code. They can review and approve and decide what they're gonna use, what they're not gonna use. And we're doing some really clever, simple things. You know, one of the things that um, um, that's helped us grow quite a bit as a business is that we're we take on support, maintenance, and enhancements of custom business applications that clients have previously invested in either using internal resources or other developers. Documentation has always been a massive problem in the software engineering space. You know, agile comes in. People think that means you don't have to document things. True agile practitioners, scrum, scrum Bond, they know documentation's important. They figure out what the right balance is. But the lack of documentation that we see in the industry is, is pretty. Um, pretty crazy. So we can use AI prompts and, and actually understand the code and have it generate comments for us to help us understand what's happening in somebody else's code. So that's really helpful. On the flip side, sometimes we'll actually write, uh, a prompt, um, as if we're writing a comment. We, we need a function that does X, Y, and Z and that's how we're prompt, um, the AI tool to write the code. And so interesting. Way of thinking about using prompts. Sometimes it's understanding existing code. Sometimes it's to generate new code. Most conversations like this, we're talking about expediting the generation of new code.

    Sean Weisbrot: That's what I found for myself using lovable because I started out prompting it and then I'd realized that something was missing or something was broken and I'd have to go and ask it. Hey, I asked you to do this thing, but part of it isn't working. Can you tell me why it's not working? And it'll go well based on your request. I've checked all of the files and I can see there might be a problem here and here and here. So let me address them and let's see if that fixes the problem. And they'll go, it'll, it'll, do you want me to do that? Or it'll just say, I'm gonna do that. And you go, all right, fine. And it does it. And so as I am creating. I can go back and make changes. I can reverse the changes if they didn't work or if it broke something else, which does happen sometimes. Um, or like, I, I wanted to, I. Change something and then it broke something that was already fine. I was like, why? Sometimes I had to go into the database and clear the database in order to, you know, the, the, to clear the tables in order to make the function work. Again, if I've made, if I've added another column to the database, if it breaks the database, so, or on, on the front end. So I, I have enough technical knowledge that I can do it myself, where someone without my knowledge at all would probably suffer. To do it, but, but I can go. Hey, um, I told you to change from a sec sequential ordering system for the reports to an alpha numeric that has eight characters, but I noticed that it's not working correctly. Um, is it possible that the relationship between the databases got messed up in the, the switchover? And I'll go, lemme check. Like a lot of fa, a lot of non-technical people wouldn't think to ask those questions. So luckily for me, I have that experience dealing with my, my former company. But, um, but nonetheless, I can pull documentation, I can ask it questions, I can suggest changes, I can request reversions, reversions. It's, I don't even a word. Uh, I can request it to reverse the changes. So, uh, I find it to be extremely helpful in, in every way. And I, I think that documentation side is, is the most important as well as the generation of new codes.

    Matt Strippelhoff: You have to know what to ask. And you have to go beyond what the business concept is. I want an application that does X, Y, and z. I'm gonna ask for these features in sequence, it's gonna write the code for me. But when you're thinking about what the larger implications are, what are you actually creating? Is this gonna be a commercial multi-tenant software application that is a SaaS product? Are you gonna have to deal with HIPAA compliance regulations, GDPR regulations? The level of complexity that, um, can be introduced based on what it is that you're producing will to determine how and where AI will be useful in the project. So, when I think about things like this, we, we oftentimes will, will describe to our customers as we're, we're gathering requirements, understanding what their intent is. We first wanna know what the business value is that's gonna be generated and what their larger vision is so that we can help guide them. We need to be a Sherpa. On this journey on behalf of the customer. So even if we're using AI tools, we still need to really be leaning in and thinking about, okay, well based on the level of complexity and what we're doing here, what is maintenance gonna look like in the future? How do we de-risk the investment? Uh, we'll start working out details around the architecture. We probably need a business logic layer that's actually separate from the code. So your business logic is not programmed into the front end user experience. That presentation layer. Because if it's programmed into the presentation layer, then you're gonna have all kinds of challenges changing things based on maybe changing requirements within the business. 'cause you can't just go to the business logic layer and make changes there. You gotta figure out everywhere that that business requirement was programmed into the solution. So we still we're leaning in on ai, but we're also very cautious about the decisions that AI is making because it will take. Your natural language prompts very vary directly. It's not going to ask probing questions back to you. It's not, well, I understand what you're asking, but let's talk about the larger picture here. How frequently do you expect things to change? Are there factors outside of your business that might drive change in the logic that's that's underlying the underlying logic in this overall application? And then come back and say, oh, based on your answers, the AI's not gonna come back and say, well then we need a business logic layer. It's not really doing the architecture, it's generating the code. But these are things that, that we need to talk about. I think in the industry in general, it's like, okay, um, what is it actually producing? Is it architecting it in a way that what it's producing is sustainable and scalable? Where is the business logic being programmed? Is it interface? Is it a separate layer? How are the APIs being handled? When you want it to integrate with third party solutions? How's it handling those types of decisions? Um, I don't know the answers to those questions. I'm sure it's probably different based on each tool, but these are things that I think about a lot. What

    Sean Weisbrot: about the legality of using these tools?

    Matt Strippelhoff: But a lot of these tools are, um. Prompt engines that sit on top of large language models. What is it taking from your, and from what you're giving it and pushing out there to those large language models? Is it doing it in a way that your IP is protected? That would be a concern. I wouldn't want to be pursuing a, a multimillion dollar idea using a low-code ai, um, solution without knowing. That big idea is now part of the ecosystem. I would wanna know things like that. I would also want to know what packages, frameworks, and open source plugins are being used, and what licensing risks are introduced into the platform. Again, when you're working with, um, experienced professionals who build commercial solutions, they're gonna help you. Along that journey because, um, as a client, our clients, they're not in the software engineering space. They don't know what a software bill of materials is. We have to educate them. It's just like a manufacturing bill of materials. It's the makeup of that solution. And open source software licenses can vary dramatically. Some of them have what we refer to as a copy left requirement, meaning that if you use their open source. Your solution, you have to make whatever you develop available to the open source community. That's not a great thing if you're creating a SaaS product that you want people to pay to use, and all of a sudden you can't charge for it because it has to be open source. So a lot of, and that's a problem that we've seen in engineering, um, in the past, even before ai, especially with mid-market clients that will, um, uh, maybe choose offshore teams to do development. And this isn't a knock on offshore. There's a lot of great offshore teams out there. It's just if you don't know what questions to ask or how to protect yourself, you don't always know what's going into the ingredients, the cake that they're baking for you. And if they're not asking you the right questions, they might introduce open source software components, packages, frameworks, et cetera, that have copy left without even realizing it. Um, so we're very aware of lawsuits and challenges that have happened out there in the marketplace because of the ingredients. Engineers chose to use. So from a legality perspective, what are the AI agents choosing to use? Or are they just writing everything from scratch? And I think that's gonna vary from tool to tool. I think that it's really important for, um, people interested in, in using these low-code solutions to take the time to understand if they're able to protect their ip, are they able to protect their code? Is there a risk of open source software licensing risks being introduced into your code base? How are the API integrations handled? Are they in a separate layer? How's the business logic handled? Things like that. But these are hard questions. I feel like you could ask AI this question. You might be able to, it may be able to give you very specific information. Um, but if, if it's generative by nature. You also have to be careful about the accuracy of the response. So it might be better to look at the actual term, the written terms and conditions, and not rely on the AI solution. To give you the answer, it's probably a good place to start.

    Sean Weisbrot: I wonder if I could spit the terms and conditions into an AI and have it as analyze it for me.

    Matt Strippelhoff: Uh, you absolutely can. We've, we've done that. We're a Google Workspace company primarily, so we use Google. Drive and workspace. Gemini's great at that. Well, uh, we can drop stuff in there and I, yeah, I use it. For example, if a client gives me a, a, a, what they would, might consider a fairly detailed spec. I'm thinking about creating X I'll submit that in through, uh, Gemini, through our paid account so that it's all. Compartmentalize. It's not going out there into the ether, but I'll ask it to produce. Just take a first pass at producing features and user stories with descriptions and acceptance criteria as if we're gonna take that documentation and drop it right into a backlog and do a Scrum Agile project, and it'll do a pretty good job, but at least gives me a good idea of the rough order of magnitude of what it is we're being asked to produce. I can refine that, take that back to the client. That's another way that I'm using AI in the business. So you could do that with, with terms and conditions. You can. You could ask it questions about that specific document. I remember

    Sean Weisbrot: handwriting all of that because AI didn't exist six years ago in that capacity, I. It was a huge headache because the feature specifications didn't always match what was in Figma didn't always match what was in the application or in the documentation, and so we would constantly have fights about what is the source of truth. In my mind, I'm the source of truth because it's my vision. All of the ideas and all of the, the features and all of the design are coming from me. You are just implementing it. Of course, I'm explaining why we're doing this and all that, right? So there's emotional buy-in and everything, but, but essentially it's all coming from me, and yet the CTO was like, well, the source of truth should be the documentation. I go, well, I'm, I'm providing the documentation. He's like, yeah, but why is the app not doing what the documentation says or why do your designs not fit the documentation you're submitting? It's like, oh my God. If we had something that could generate the source of truth. Then the QA team and the product team and the tech team would all be aligned, and so everything would appear as it should. And if it doesn't, it has to be fixed. That was like, I have PTSD from this, honestly. So what are some issues you've come across as a business owner in trying to grow this business?

    Matt Strippelhoff: My business partner and I, we started the company in 2008. Um, the high performers in our specific roles in prior organizations, some experience working together for many years. So we decided that we would start our own business, do it better than anybody else, and we rapidly grew, but then we reached a threshold, and I guess it's the threshold is, is the challenge that a lot of entrepreneurs are gonna run into. We were able to grow the business, um, over the first five years, and then we just sort of plateaued and we stayed. Below a $2 million a year top line revenue company for a long time. We've been in business for 17 years, but we've doubled in size each year of the last three years. And colleagues of mine, um, eo peer peer group members, um, though I asked me, well, what, what unlock the growth? And the first thing that had to happen is we, we had to decide as, as business owners that we wanted the company to be more than a lifestyle company. We wanted to grow the business as an asset, and that changes the way that you think about the business. The very next thing that happened is we had to look hard at the business, the market that we served, our customers ourselves specifically, and our skill sets. What were we lacking as leaders in the organization? Maybe what were we doing the wrong things day to day? So, um, that revealed to us, and it wasn't, you know, the other, we had some other folks, I had coaches talk to me about this and others recognized it before I did, and we all have blind spots as business owners and entrepreneurs. My blind spot was that I probably need to be focused on evangelizing the brand, on building relationships and not be in the day-to-day operations of the business. We, we sort of had this consultant's dilemma, which I'm sure you're very aware of where, where you will sell and then you get the work and you do the work, and then you're doing the work so you're not selling. And so you have this little bit of a rollercoaster ride. And that was the way that Redhawk was going because I was the one who was primarily generating. The new opportunities with clients. So my business partner had to step in and just say, okay, I own all operations. You just need to be outward facing. Building relationships, drive the vision of the business. And we did come up with a unique, um, model for the business as well, which helped unlock growth. But we also had another challenge. And that challenge was neither myself nor my business partner had the deep, um, financial experience like a true CFO. We didn't have the experience of successfully building businesses beyond what we had built ourselves, and we needed to bring in additional leadership. We, we needed A, a true C-O-O-C-F-O, and we were fortunate enough to find the right person for that. Now, the challenge that happens af, once you find someone like that, they generally wanna share in the growth and the, and the value of the business. So then as a business owner, you have to be willing. To share that it, it, you gotta give them a path forward to where they're gonna benefit from helping you unlock that growth. So we had to embrace the idea of bringing in another partner, which we did. Um, and so, um, getting, we had to get a lot of things right, but I guess going back to the very beginning of that, uh, answering that question, we had to realize what we were getting wrong and we had to embrace. Where we needed to, uh, uh, uh, bring in some, some additional skills from, from others. And we had to change our, our, the way that we're thinking about finances within the business as well. And sometimes I catch myself still, uh, having this, uh, smaller business mindset instead of a big business mindset in how revenue and cash flow works. Um, and, and, and so it's interesting now to start to say, oh, yeah, okay, I get it. Yep. I need to be comfortable. I need to lean into some of these things. But, uh, you know, as a result, we've, again, we've doubled in size each year, the past three years, and we're on track to double again this year. Knock, I'm knocking on wood. I'm hoping it's gonna go at, according to plan.

    Sean Weisbrot: I specialize in finding problems. Pointing them out to people. I have a friend who's run a business for 13 years and they also hit a plateau and I, I was able to spot from a mile away 'cause he'll tell me all of the issues they're going through and what they're working on and all of that. I've known him for 27 years, 28 years, so I, I've known him since before the business started. And I would tell him for years, like, you, you can't do this, you can't do this, you can't do this. I go, you know, you are the one preventing your business from growing. You know, there's a problem in the marketing. So he kicks out the marketing person and he takes over marketing, go maybe for a few months, crying, clean it up, creates some documentation processes. Then find someone and get out of the way. Then sales has a problem. Then, then design slash product has a problem and he comes in and he takes over those. I go, you are doing the wrong thing. You're not supposed to be taking over these problems. You should like, sure, fine, fix them. But like, you know, I go, if you continue to do that, you'll never hit 10 million in sales in a year. I go, you have to get rid of those, those positions because he's also doing an MBA that's across the country. He lives in Alaska. The BA is at Cornell. Sometimes they have some physical meetings. Um, plus he's traveling to conferences 'cause he is the CEO obviously. He had a conference in Spain. He is got a conference in Atlanta. He is, you know, all over the world traveling to conferences. Plus he's got a wife and a little kid. And like, how are you gonna have time for sales and marketing and product and building the company? And they acquired a company a year ago because it was Synergy. Uh, some of the clients that they had were also clients of this other business. And, you know, so that there's, there's synergy on both ends. Um, so that helps with revenue, but they, they absorb the team. The team's now under the rest of the company, even though they're kind of doing their own thing, they're like a unit. Like, I don't know where you think you have the energy, like the guy's doing it. But I think I'm like, if, if you got rid of those three things, you would probably hit 20 million in a year. You would probably double, double or more in a year or two max. Is he looking into EOS at all? They had someone come in and do training with them and they tried to move some team members around into the different positions, but it didn't work out with those people.

    Matt Strippelhoff: Yeah, I think the operating system works extremely well, but it might also highlight where you don't have the right people in the right seats. So it can be challenging.

    Sean Weisbrot: Well, I, I said to him, I go, you can't be in multiple seats. That's the whole point of the system. You can be in one seat.

    Matt Strippelhoff: You look at the way they handle quarterly rocks, you can't have more, you should never have more than three special projects per quarter. So you can't own all the special projects either.

    Sean Weisbrot: Like if you are going to be in charge of sales, hire a CEO. You're going to hire, if you're gonna be in marketing, hire a CEO, hire a salesperson if you wanna be the CEO, hire for those other three company, those other three parts like, but you can't have two seats. I go. EOS is about having the right person in the right seat, not having the right person in the right seats. So you're only allowed one seat, man. I'm like, I love you very much and I want you to succeed, but you're doing it wrong. I go, I, I've, I've never had a team of this size. I've never seen this kind of success sustainably, so like, fine, and I get it, but I can also see things that you can't see or you're not willing to see. So I totally get it. And I tell him every time I see him, every time I talk to him, I'm like, I, I keep hammering him on, like, these things are great, but you, you're, you're not there yet. And you know why

    Matt Strippelhoff: I kept trying to let go of, of owning too much and then kept getting pulled back in. So we had to bring in the additional leadership. To prevent me getting pulled back in, in certain areas too. So it's hard, it's hard to get right. It's a, it's a concept that we can talk about and people can embrace. It's hard to get right. It's work.

    Sean Weisbrot: I was accused of taking on too much with my own startup and I. Hired a product manager. I hired a marketing director. I hired a COO. So at, in the beginning it was just me and the CTO, and we hired all those people and I felt like I had done such a good job that I felt bored and I felt guilty as if I wasn't doing enough. And that was a big problem for me. And then I tried to do more and they're like, no, stop. They're like, you're doing, you're doing fine. Just stop. Just make sure we have enough money to pay salaries. That's your job.

    Matt Strippelhoff: That's your job. Yeah. Yeah. It is an interesting shift when you go from being a high performer on the execution team and even owning a lot of that during that step, those early stages of the business, you have to wear all the hats until you can backfill your position. Until you have that revenue flowing in that you can, you can backfill and make those good hires, um. It is a tough transition to move out of being on the delivery team. It took me a long time getting comfortable not, um, directing and assisting with, uh, product owners, project managers and clients. My, one of my unique skills, probably similar to, to yours is that, um, one my business partner or CTO, what he would, he would say is, if you've got an idea, take it to Matt. He'll punch more holes in that bucket than anybody. I ask the challenging questions I uncover where the, the problems might happen or where the opportunities might exist, and go beyond just the conversation of what somebody wants. And so you need somebody like that on the team. And I loved doing that because I could help the clients get more value and sometimes figure out where the real value was and focus on, on. Um. On that first, in those areas first, or de-risking the investment by offering feasibility studies. Because I could see patterns, I can see where the challenges might occur, and I loved contributing that way to the team. So starting to let go of that and, and relying on others to do that, it's, it was tough. I'm in a good spot now, but that's

    Sean Weisbrot: hard. That's the thing I love as well. Like I said, I I earlier, when someone tells me they have an idea, I love to tear it apart because they, they're only seeing the idea. They're not seeing how it could fail. And so if you're not willing to see how it could fail, you shouldn't start anything. And a lot of people say, I have an idea. I'm gonna do it. I'm gonna go full force. But they don't think about the the potential ways that it, it could fail.

    Matt Strippelhoff: You gotta think about that in order to de-risk or identify maybe where the, the challenges are. And, and I, I know we don't have a ton of time, but we've got so many great experiences where we helped clients zero in where the risk is do that body of work first. Make sure that that's not gonna be, um, an issue that you can't overcome. Then you make the larger investment. Sometimes it's with tech, you know, IOT projects, things like that. They'll make a lot of assumptions about somebody else's hardware. They'll make a lot of assumptions about other platforms, APIs. They'll make a lot of assumptions about the, what the market's really gonna care about. But that's more a market research challenge. But on the technical side of things, it's amazing. The assumptions that people will make, and we like to zero in on those first to say, well, let's do a feasibility study. Let's make sure that what you're theorizing is true. You know, there's a lot of challenges people run into with, with APIs provided by third party organizations, they assume that that platform is gonna, everything you can do in that platform, you should be able to communicate back and forth for those features through an API. Oftentimes it's not true. The API can be very limited. Or an API might even have throttling. You can only make so many calls in a 24 hour period. You're not gonna get data in real time. Well, if real time data is a requirement for your vision to work and realtime data is not really gonna be available, what's the contingency plan? Do you change the way that you communicate your offer to the market? Do you change the way you handle pricing? Probably both of those things would be true. If it doesn't mean you don't move forward with a vision, but you at least know what the technical limitations are. So anyway, you can see I'm kind of geeking out 'cause that's, it's those little subtleties that I expect my team to be able to uncover as well. Now that I'm not specifically in that role, it's hard to let go.

    Network
    Before
    You Need It

    How I generated $15M for my businesses and $100M+ in value for my network.

    Sean Weisbrot
    Sean Weisbrot
    We Live To Build

    Network Before You Need It

    How I created $100M+ in value for my network
    and earned $15M for my own businesses.

    Delivered as 6 lessons I learned from experience as an entrepreneur.

    Subscriber 1
    Subscriber 2
    Subscriber 3
    Subscriber 4

    Join 235,000+ founders