Forever. CIO's been saying buy, don't build. But that's changing.
SPEAKER_01If I'm not a technical person, like what are some of the foundational things that I should at least be conversationally aware of when I'm approaching developers for some stuff for our company?
SPEAKER_00The conversation when you're evaluating vendors for software engineering projects should really start with what's your experience been like using AI in your software development lifecycle over the last year? Tell me that story. How it's impacting the way that you do things and let them respond. And if they're getting excited and their energy is coming up and they're talking about the wins and efficiency gains, that's probably your guide.
SPEAKER_01What's your thoughts on the CTO leading uh like a generative AI effort within the company?
SPEAKER_00If that effort is specific to affecting or improving the bottom line for that department, then they should be in charge of that.
SPEAKER_01There's a lot of tools out there. What's leading the list for you as far as the tech stack or the tools that are available for somebody like me?
SPEAKER_00Well, uh, one of my favorites is Google Firebase Studio for generating clickable prototypes. We're all still trying to figure out how much of the code we can trust.
SPEAKER_02Matt Strippelhoff is a technology leader at Red Hawk Technologies, where he helps mid-market companies gain predictable, scalable software development and technical support through an award-winning fixed-fee service model. Welcome to Using AI at work. I'm your host, Chris Dave. Each week we'll be learning how today's business owners, entrepreneurs, and ambitious professionals are getting more done with smart use of tomorrow's tech. Let's get started. Right now, every business leader is asking the same question. What are we going to do about AI? If this is you, ChiefAIOfficer.com has the answer. We give you a simple path forward where we provide executive and team training so your people know exactly how to safely use generative AI in their day-to-day. We also manage the deployment and implementation to make sure tools actually get adopted and deliver results. And we'll also guide company-wide transformation so AI becomes part of your operating system, not just another shiny object. The companies that act now will increase productivity, cut costs, and grow faster than their competitors. Those that wait will get left behind. So if you want to make AI work in your business, visit ChiefAIOfficer.com and see how we're helping companies of all sizes finally get results from AI.
SPEAKER_01Hi everybody, welcome to another episode of Using AI at Work. My name is Chris Daigle, and I'm the host. And our guest today is Matt Strippelhoff, the CEO and CRO of Red Hawk Technologies. And today, um, you know, Matt and I had the opportunity to connect uh a few weeks back before the interview, and based on the conversation we had, I'd like the conversation today to be uh for us to be able to access Matt's expertise and find out how do we audit our dev partner in the age of AI? Now, what I mean about that is like just like an attorney, the pricing model is gonna have to change. If if uh we just saw the story that came out with the big law firm that, you know, $3,000 an hour law firm, and they got busted using uh Claude or ChatGPT to write up their brief referencing uh hallucinated case law, right? Now, obviously that's a poor use of the tool, but we know that that generative AI is being introduced into the legal environment. And this whole idea about paying a lawyer by the hour when maybe they're not using the hour, maybe they're using five minutes because they've built something in the models, that's something that's that we're all used to. Now, if you're a business owner and you're uh exploring generative AI, the reality is there's gonna be the the access to be able to get bespoke custom software created for you quickly and easily, maybe not replacing Salesforce, but small applications to start for sure, that's already on the table. So if you don't know how to do this, how do you make sure that when you're talking to potential developers to create these things, that you're not in the attorney situation where they're like, oh yeah, it's gonna be 50 hours development, but they're actually using tools that you and I have access to. So that's kind of the theme I'd like to take it in, Matt. But before we go there, why don't you tell everybody about why you're the guy to talk about this?
SPEAKER_00Well, I've been in this line of work for 25 years and started Red Hawk Technologies 18 years ago, and all we do is custom software engineering. And uh, you know, we developed our first AI model and solution for one of our clients five years ago, but this rapid evolution of cloud code, uh base 44, all these tools lovable, everything everybody's hearing about today, man, we were diving in hard on that all in the past 18 months, uh year or so, and and it's amazing what can be done. And we're using those tools to rapidly develop solutions for our clients today, and it's affecting how we do everything.
SPEAKER_01So was I off when I was doing the comparison between like this legal bottle of Bill by the Hour as compared to dev? Is it is it is that what's happening?
SPEAKER_00Aaron Powell Well, I think there's certainly some risk, but you know, uh it's always gonna come down to trust and transparency from the vendors that you're working with. And I think it's gonna be imperative for people to ask the question of how and what tooling are you gonna use to produce this solution for me and how does that impact the contract? So I think these conversations need to happen very early, very early. You don't want to find out later that um you know they they start adopting tools after they form the contract, and now maybe they're not such a trusted vendor and they're not being transparent, and they're thinking about how much margin they're gonna lose because they've they uh you agreed to a a schedule based on time and materials, and all of a sudden they're delivering at a much rapid, uh much faster pace, and now if they're greedy, they're thinking about, well, can I still get away with billing what we agreed to? Um, but but you know, the description you're providing is like, well, maybe they're maybe they're um uh misrepresenting their time entries, you know. Uh that's where you gotta watch out. I don't think there's gosh, I hope there's not a lot of that going on. I know for sure it's not happening here. Uh you know, our approach is we're letting the customers know what the tooling is that we're gonna use. In fact, we we started um applying a surcharge to our contracts to cover the the cost of using these tools because it's not free. Yeah, yeah. And and it's not even a fixed cost. It's not like it's a license per seat per developer like other software engineering tools have been historically. No, this is a utilization fee. And the more we use it for you, the more it's gonna cost us. So we just pass that cost along as a surcharge, and we still track our time entries in a very transparent manner, provide that detail to our customers with our invoicing. But um yeah, I think there's certainly a lot of talk about moving toward value-based pricing because everybody's trying to figure out how to use this.
SPEAKER_01Yeah, so uh an environment of misaligned incentives, and that seems like a tricky place to be. Um I know that you guys, you as you just admitted, you guys are are kind of changing up the what that billable experience looks like for your clients. But why isn't the industry itself kind of self starting to self-correct on this?
SPEAKER_00Or is it I well two thoughts that I have on that. One is we're all still trying to figure out how much of the code we can trust and value that's being generated, how to make sure there's quality control on that. And then uh we're measuring we're measuring throughput to see how much faster we're actually accomplishing our objectives. But oftentimes we're estimating based on our traditional approach to software engineering because that's the devil we know. And when we're asked to forecast work, the engineers who you know, we've got people on our team with 15, 18 years of experience that have been with us the whole time. With the tooling largely being adopted in the last six to nine months, it's really hard to how hard to use uh hard to estimate differently. We're still learning how to estimate differently. So that's part of the challenge that's happening right now. And so a customer might agree to it to a scope that's estimated a traditional way, and then all of a sudden you you kind of have that challenge where it's like, okay, we agree to a fee schedule, getting there faster. We didn't know how to anticipate that. We also have charges associated with using these tools based on utilization. How does that handle it? And if it's not in your contract language, it's really hard to account for late in the game.
SPEAKER_01So I can tell you that my experience has been when I've uh you know, I'm a light vibe coder, let's say, I've built apps for our organization and uh the mechanisms we use in marketing and things like that. And a lot of times when I'm working with the models, it'll give me an estimate, it'll say, hey, this is a lot of work, this will take two to three hours. And I'm thinking, but then I realized it's basing that on its training data. It's training data is decades of humans saying, oh, that type of development project will take X number of hours. So the models are going and they're like, they're looking for a reference, they're like, oh, he's asked me to do this based on what's in my training data. It looks like that's gonna take two to three hours, but the reality is it's like ding, it's done, like five minutes later or whatever. So one of the things that you've brought up that I think is important for the listener. If I'm going to be investing in a development team, I'm gonna look for AI capabilities for sure, because I'm gonna hope as a business owner that that gives me some pricing leverage a little bit, right? Maybe I'm not paying the full dev price. Um, but if I'm not a technical person, like what are some of the foundational things that that I should at least be conversationally aware of when I'm approaching developers for some stuff for our company.
SPEAKER_00The conversation when you're evaluating vendors for a software engineering project should really start with what's your experience been like using AI in your software development lifecycle over the last year? Tell me that story. Help me understand how it's impacting the way that you do things and let them respond. Ask more and more clarifying questions based on that conversation. And if they're getting excited and their energy's coming up and they're talking about the wins and gains, then you're probably, yeah, that's probably your guy. It's it's like, okay, they're really gonna take advantage of this because they're passionate about it. They're not trying to disguise anything, they're being transparent. Um, and eventually you have to develop some level of trust because it always is gonna ultimately come down to trust. But I think get them to tell you their story about their experience with the tooling and how it's impacting them.
SPEAKER_01Yeah. So we uh we've got I've got a couple of interests. One of those interests is some software, and I've got a very capable um developer who didn't have a strong technical background, but has spent the past two years deep into the in these vibe engineering, vibe coding tools. Smart guy, um, but he's doing amazing things. And and we raise a little money. He said um we need to bring on some more developers so we can move faster. And I let him vet those people because he he's the guy that can you know ask the questions. Everybody said they were AI enabled and AI capable. Once he brought them in, that their self-interpretation of an AI capable, like I'm an AI capable dev, right? Their self-interpretation was no match for what he was expecting. Um so I can say that in our own experience it's been uh hit or miss finding folks who have the traditional experience for sure. They could, you know, if I gave them half a million dollars in six months, they could build a thing. Um but are so I think that's something that that from my own experience, I would also say watch out because they may be using the tools, quote unquote, but are they using the tools the way that Matt's team is using the tools, right? Um as a so how might one how might I I have avoided hiring those people in the first place and then having to fire them a few weeks later?
SPEAKER_00If you have a specific methodology and combination of tooling that you're passionate about using, your lead engineer, for example, then the QA process during the hiring should be more tightly aligned with that desired throughput in the utilization. I think that's that's part of the process. In addition, as we've been expanding our team and growing, in fact, what's happening right now that with that my team is doing is our AI czar the the most passionate developer on our team, has been with us for over 12 years, who's an early adopter on all these platforms. He has multiple agents doing coding at night all the time. Like this is the guy, like he's my version of your guy, right? Yeah, yeah. Uh and he's also passionate about teaching, which is fortunate for us. Awesome. And so we charged him with producing um uh an educational program. It literally is a multi-week boot camp. And we're taking all of our engineers, we have close to 50 people on the team. They're all going through this boot camp now, so we can all start rolling in the same direction. So we have early adopters, power users, and then we have people, you know, some legacy team members have been with us for a long time, OGs who are still kind of falling back into the way of doing things that they trust and know where they can have quality throughput, and they're not adopting quickly enough. So I think there's also uh a need to realize that anybody building a team, you got to have a champion, somebody passionate about educating, that's gonna decide what your standard is, and then you got to be willing to educate.
SPEAKER_01So this is good because the perspective you just shared is there may be listeners that have they've got their own team. They're not necessarily looking at vendors. And if that's the case, what Matt just described, 100%. If you've got that person who's doing this in their free time because they're just so enthusiastic about using it, if they can tell tell others what they're doing, that enthusiasm will catch on and your development team will be um enhanced for sure. Now, in in the pre-interview, there was you you made a comment, there was something along the lines of like if your dev team isn't using cursor or similar tools in 2026, they're either lying to you or they're behind. Right? And I thought that that was um what's the incentive for uh a developer to not like own up to or or embrace, hey, I'm I'm using AI for all my stuff. Is there a stigma? Uh because again, think about who's buying this stuff. Is there a stigma to it? Is it are people concerned about maybe risk of somebody using AI on my code, or what's the what do you think?
SPEAKER_00Well, I'll answer that question from the perspective of of the engineers. And you know, the first part of the question is what's the incentive for them to do so or admit that they are or not doing so one way or the other? Uh it's gonna come down to individuals and style of work. They know they're being uh held accountable for their performance. Performance historically for an engineer is the quality of the code that's generated. If AI is generating the code, then there's some anxiety that comes with this about how am I how's my performance going to be measured when now I'm the orchestrator and I'm not generating the code. So I think that creates some anxiety and some challenges, and maybe that might incent some people to be less willing to dive in headlong. Uh they may be saying that they're using it, but they're not really embracing it like your power users, and you might notice that through a difference in throughput. Or they might be on the other end of the spectrum where they're using the heck out of it, but they're concerned about the quality because they're not taking the time to really evaluate the pull request. So they might be a little less in genuine about some QA around the quality throughput. And they might say, you know, they might change there's also there's so much psychology in this, Chris. There's so much to unpack there. It's really hard to give you a real clean answer. But um, yeah, it's a challenge. You're now trusting AI to do work that you were measured that you are continuing to be measured on.
SPEAKER_01I guess it's like the same thing. If I had somebody producing content about my industry or whatever, you you hope that um AI, you hope it's good enough to pass. So one of the uh other areas that we talked about, and this is something that comes up a lot because we we we go into companies, we don't do the technical side so much, but we do the the training and and use case and uh I mean uh uh uh use policies and pilot project identification and SYZ. And we always look for that internal person who's gonna be the executive sponsor or whatever, right? Like somebody that we know that if their team isn't quite getting traction or they're not showing up to meetings or whatever, then we can go to daddy and he can go and crack the whip on his own team or her own team, right? Um and the first question is who should that be? Now uh a lot of companies they that aren't necessarily like all in on AI yet, they assume, oh, this is a technology, it should be our CTO. What's your thoughts on the CTO leading uh like a generative AI effort within the company?
SPEAKER_00If that effort is specific to affecting or improving the bottom line for that department, then they should be in charge of that. If it is an AI let me let me clarify. Yeah, go for it.
SPEAKER_01When you s when you say they, you mean like if my department is operations, yes. I should be in charge of the orchestration or the oversight of generative AI in my department.
SPEAKER_00Yes.
SPEAKER_01Is that what you're saying?
SPEAKER_00Okay, yes. Now from from a cybersecurity, uh, acceptance use policy, all of that stuff is bigger than one department, obviously. I think that does kind of fall in the room of your CISO or your CTO in terms of policy enforcement, technology adoption, releasing and managing licensing, things like that. But the owner of that pilot program needs to be the one who is also accountable for the performance of that body of work. In other words, if it's if it's operations to your point, and your pilot program is about improving throughput, reducing the time from opportunity to cash, for example. And maybe there's some AI involved that's handling communication between an ERP and the CRM platform to pull that off. If their metric in the business is how well they're performing in that area, they need to be the ones who own that program. Ultimately, it's not about the tooling, right? It's about it's about business impact.
SPEAKER_01So the mistake that a a business uh decision maker could make would be it this is technology, therefore we we've got a tech department. Let's let them handle it. But the tech department isn't going to have the context relative to the process that is getting AIFID or the or the workflow that's being and that's why it makes sense for the the head of that department who does have domain knowledge, subject matter expertise, and outside of the security side of things for sure, totally like the uh you don't want your COO making those calls, right? That's the tech team for sure. Um how should they first off, I guess I don't I don't know if you're you're seeing this in a lot of other companies, but is there friction between the CTO or the tech department thinking that, hey, I should own this because it is a technology? Are you hearing about this?
SPEAKER_00Yes, I am hearing about this. And the friction typically comes into play if the project gets sponsorship before the CTO is involved in the conversation, because now they're in this how do I de-risk where this is going and it's gonna and it's unexpected, and now you've just come in and you've just basically dumped a bunch of work on their desk and they have to figure out how to make sure this gets done in a secure way. That that creates friction, no doubt about it. I think they need to be at the table at the same time when they're evaluating what programs to invest in.
SPEAKER_01Great tip. Because using AI, there's risk. And it's not the tech, sure, but it's the user that is 77% of employees are you know uploading uh company secrets into the models. Not not intentionally, but they just they don't know, right? Yeah, so I think that's a really good point to bring the CTO in as early as you can, not to say, hey buddy, do you have time to do this? But hey, we need your perspective on this. I I love it, I think that's great. Um okay. There was a comment that you made about funding someone's learning curve and calling it a project. And which which we experienced that with that, right? Like, like they said, hey, I'm a developer, I've got and and they had built projects, they built it in the industries that we were targeting and those sorts of things. Great. But when it came to um using AI, there was most definitely some uh I'll learn, you know, I'll figure it out as I go kind of thing. And we were paying for that learning curve. Um outside of maybe some of the suggestions that you made earlier about how to vet and pre-vet some of these candidates, how do I make sure, or is it okay that I'm paying for that? I mean, if the the if the developer is like this is awesome, I've got an opportunity to learn, um, I mean, they're gonna do better at it than I would. Is it a bad thing that they're learning on my dot with AI?
SPEAKER_00From the client's perspective, they're always gonna feel like I should not be paying to educate your team. I'm paying a premium. Developing software is not an expensive, inexpensive endeavor. You're gonna make it an investment and you and you really need it to pay off in the long run. So, what we've done to kind of uh address a lot of that, especially in the past, gosh, the past year, more so than any time prior, is we'll agree to value based pricing on the pilot portion of these programs just to help de-risk that for everybody. Uh you know, and and we're moving more and more. In that direction. And so you what you'll start to see a lot from the industry, and we've been doing this for a while now, is okay, let's talk about your vision. We're going to take our best technical BAs, we're going to do a deep dive, and put together a clear project requirements document. It's starting to kind of go back to like waterfall methodologies in some ways. So we're gathering as much as we can, documenting that, providing that as a markdown file to the AI tooling so that we've got really good context. Now that's all full rate because that's consulting, and that's what we've been doing for a really long time. As soon as we start saying for this clickable prototype phase one, here's the fixed fee, we can all align on that, the value's there, you're comfortable with it, we're comfortable with it. Then we may choose with their with their clarity, they're going to have no knowledge about this. We want to explore Firebase Studio for the clickable prototype on this project for you. When you know, win or lose, that's on us. Your fee doesn't change. We're going to explore base 44. When lose, the onus is on us. Okay? Yes. So then that gives us a way to make sure that we still at least have some cash flow coming in. We can take the risk as a business, knowing that there's going to be some educational costs, but it's not going to be passed to the customer because we're all comfortable with the fee schedule.
SPEAKER_01Yeah.
SPEAKER_00Now, when you look at MCP servers with tools that are uh you combine this with tools like Cloud Code, um cursor, and others, well now all of a sudden you've got all this knowledge and expertise that's provided in an MCP server. So it's not really a learning curve at that point. As long as they've developed their skills in using the products, in fact, the opposite is often true. They don't have to have deep technical knowledge of the API endpoints in dynamic CRM any longer because the MCP server provides all the context. Their expertise really should be residing with or using the appropriate selection and combination of agents and tools and skills, right? You look at Cloud Code, you have all these different skills. That's where their expertise and knowledge really needs to reside now, not so much deep technical knowledge and upskilling on API endpoints and documentation.
SPEAKER_01So that's a completely different. So one of the one of the reference points we share with like executives, at least on the knowledge work side, not the technical stuff, is we say that that the paradigm of learning has changed, right? Like I used to, if I wanted to be the expert in something, I went to school, I went to, you know, I got my my college degree, I got an advanced degree, I went and maybe did some additional like specialized skill training, so that at some point in the future, if somebody said, Hey Chris, you're the expert on this, what do you think? I was expected to be able to like on demand recall this information, right? Today, as a knowledge worker, I don't have to go, oh, we need to schedule the the the expert to come in here. Oh, wait a minute. Hey, ChatGBT, act like the right, like there's that and it sounds like with the MCPs and things like that, it's it's just you want you don't want somebody who's never done who's never worked in a development environment before, of course. But they don't necessarily because with the way you just explained that to me, if I was a buyer, I'd say, oh, yeah, that makes perfect sense. Because I understand what you're saying, right? But with the MCPs, so that's like the that's like the developer's equivalent of what I've been telling executives about using the models. You need to you need to know how to use them. You don't need to have the information, you just need to know how to use the models to get the to apply the information. Okay.
SPEAKER_00Yeah. And you have to you have to have you have to bring the appropriate context into that conversation because it's only going to work with what you provide it. That's where a lot of expertise comes into play. You know, it's it's what are the watch outs? But you know, if you've got 10, 15, 20 years of experience engineering, you're gonna know that there's some challenges and you're gonna cycle through the planning phase with Claude Code saying, dig deeper, think about this. And it's gonna say, oh, it's gonna be very nice. It'll compliment you even. That's a good idea. Let me do this, and I'll come back and say, Oh, I found some gaps in the plan. So you still need really good, experienced engineers to get high value out of these solutions.
SPEAKER_01You used the term earlier, the orchestrator, and I know that it was in reference to the agents, but it's it's more than that. It's it's orchestrating the entire process. But you can't lead the orchestra if you've never played the instrument. I mean, I guess you could, but I'd I'd rather somebody who was familiar with had had done it, had gotten their hands dirty before.
SPEAKER_00You gotta know music theory. You gotta at least think you gotta have rhythm.
SPEAKER_01So there was something else that came up in our conversation. You had mentioned that you had built an AI agent that does the work that a junior developer used to do.
SPEAKER_03Yes.
SPEAKER_01Um so what does that mean? A question that I get from a lot of people is uh what this means for my industry. Let's say it's the attorney. Well, as an attorney, there's a path. You graduate law school, you do, you know, you do the the crap work, and you do the long hours, and then you get you become the person who is the partner, right? But if we remove those people, those junior developers, does that disrupt the I mean it certainly disrupts the existing paradigm, but does it disrupt the end result of me having senior developers if I don't like if there's not if I'm not bringing in these juniors anymore?
SPEAKER_00It's a fantastic question that we have not found an answer to as of yet. It's I think right now we're in that disruptive stage. And you're right, the traditional paradigm of journeyman to craftsman is is no longer the pathway, it's got to change. And I firmly believe that in our education system needs to focus more on logic and and reason, education in those areas, because the teaching the tools, the tools are changing faster than we've ever seen. But if if they've got a really strong foundation in logic and reason, and then then from there it's experience. And so we need our best knowledge workers to be able to assist with training this next generation of developers, but they're not going to be teaching them the tools. They're gonna be teaching them how to think. But it's a tough one. I don't know how to unpack that. I really don't. We're we're we're still in it.
SPEAKER_01Yeah, I think every industry is. You know, with with this, at least it might you might get the result faster, but with some more traditional industries, like it might be uh five to ten years before they realize, hey, wait a minute, we don't have anybody to take over when the boss is retiring or whatever. Yeah. So what we're finding is that a lot of companies that we're talking to, they're somebody's experimenting with something. And it might be Replit, it might be base 44, it might be cursor, it might be, but a lot of it tends to be uh clawed code. Everybody's hearing about clawed code. Um for maybe there's companies that before they they engage with a uh a professional development environment like what you've got, you guys have, they knew that there was some low-hanging fruit, and maybe they had a couple of people that they were like, why don't we experiment our way to this small widget that we know would help in you know customer service or in accounting or whatever? What would you recommend to them, the the DIYers, the homebrewers? Um what a uh there's a lot of tools out there. What's what's leading the the list for you as far as the the tech stack or the tools that are available for somebody like me?
SPEAKER_00Somebody like you. Well, you're fairly technical. Do you want to do are we talking about someone who's fairly technical, homebrewers?
SPEAKER_01No, um I I say homebrew um like literally like a home brewer, but I forget that there is a a homebrew application um that I've encountered. Uh yeah, so that was an accident. More like just uh probably the the average listener to this, which is that they're using it, they're getting wins from it, and they want to be part of the either the champion or part of that championing championing action in their organization for AI. Um and maybe they feel like like I would love to be able to show the rest of the team some demonstrations of what's possible because the the rest of the team doesn't know. So I want to get um maybe marketing had a couple ideas, and I think that we could build something. I saw a TikTok reel or something where somebody had built something. Um, but that individual wants to give get some tools in the hands of their fellow enthusiasts who might be the builder, quote unquote. What are some of the tools out there that you think are the best, and which ones should they probably avoid either because it's too technical or because it's overpromised?
SPEAKER_00Hmm. Well, uh one of my favorites is Google Firebase Studio for generating clickable prototypes. But even before you get to that prototype, uh if if they really want to have a fun, fast experiment, I would advise them. Well, first they have to have an idea, right? Generally, there's going to be some concept that they want to explore. Bring the other subject matter expert, the whoever you think might benefit from it in your department or another department in for an hour-long brainstorm session. Use whatever AI agent you want to capture that transcript and ask a lot of clarifying questions. Then use AI to generate, and it could be ChatGPT. Use that to generate a high-level project requirements document focused on outputting a PRD. But when you do that, drop in the URL address to Firebase Studio's documentation, which is available publicly. So you just got to find that URL. So what you're doing is you're providing you're providing enough context that it understands what you want to have in that PRD. Clickable prototype only, no back end, no database. Here's the documentation about the tool I want to use. Give me a PRD. Then take that PRD, and I I like to use Gemini because it has a lot of deep knowledge around because it's obviously it's a Google, it's a Google family product. I'll have it generate the sequence of prompts for me.
unknownYeah.
SPEAKER_00It'll give me, you know, give me the first prompt to set the projects up so that I can get to the clickable prototype I want. Here's a PRD for context. It'll give you your starting prompt. Then tell it to give me the sequence of prompts so I can generate the clickable prototype. Now, if you want to be a little bit more sophisticated with it, vibe with ChatGPT and provide it your brand guidelines and have it create a design standard markdown file because you provide provide that as context, then it's going to be designed to match your brand on top of it. Now, don't be afraid to fail. That clickable prototype might, it's not going to be 100%, you know, knock it out of the out of the park first pass when you drop those in. If it's a little clunky or a little weird, tell it to export the code it generated, go back into Gemini, pump it in there and say, I had these problems with it. Give me another sequence of prompts and let's try again. Delete that project and do another one. You know, do another clickable prototype with a with a more improved sequence of prompts. It's a lot of fun.
SPEAKER_01Are you so you're kind of having them not necessarily play against each other, but you're you're not just sticking in, oh, I'm in Gemini, I'm gonna build this thing. You're you're bouncing around and getting the best of what the different models are able to do, collaborating, you're orchestrating the different models working together for the solution.
SPEAKER_00Yes.
SPEAKER_01I like it. So I've been doing that with uh, you know, sometimes on strategic stuff or like the marketing messaging or whatever, but I haven't thought to do it with the vibing. And for the listeners, listen, like I am not I I took, I think I even dropped out, I took like a class on coding in in 1990 something, right? So I'm not a tech person by any stretch, but I know I know the outcomes that I want from my business or a client's business, and I know how to explain them well enough and I've created this discipline or this habit of, oh, let me go to the models and not sitting there going, how do I do this? Oh, let me ask the models, how do I do this, right? So I want I want you to think if you're if what you're hearing from Matt right now is you're like, well, that's a little over my head. It's not it might be today, but if you were to sit down and with something like uh an arrangement, what you just what he just talked about, I think you'd surprise yourself with now, is it something you're gonna go and and you know ship tell the people tomorrow? No, but I think you'd be surprised with how quickly you can come up with something that isn't gonna break, probably. Um but you built that with your thought and these models doing the heavy lifting, and this goes back to that that you know new way of learning, right? You don't you don't need to crack open the the the book about coding when you've got the model sitting there. Uh so how are you guys um using this? Um obviously in the development side of things for clients, I get it, but how have you introduced some of this operationally into what you're doing at Redhawk?
SPEAKER_00Well, great question. So we were looking at uh enterprise level ERP solution for professional service organizations, ERPs, everybody knows what those are, or at least I would assume. For us, it's managing our resources are individual developers, their skill sets, and then clients, contracts, all of this information has to be orchestrated. So basically the the short story is we created our own custom ERP using this software development lifecycle that I've been kind of describing. And it's amazing what we've got in there. Um we actually included Gemini out of the box because of the tooling that we chose as an AI agent inside of the ERP. And there's a view for me as CEO. I can navigate to a screen. It's called um Hawkeye, affectionately, because our business is Red Hawk Technologies. But I can put in a couple parameters and it will give me a current state of the business, views in natural language and processing all of my um project managers' agendas and minutes following meetings, sentiment throughout the organization based on meetings. So I get a state of the business and financial data because we have all our clients and contracts data in there. And we're continuing to develop it now. We have a specific product team that's helping us advance it fractionally within our organization because we've getting so much value for it. So for our organization alone, we're moving away from SaaS. We're creating our own SaaS solutions. Yes, okay. And it's awesome. Um I think customers are going to start. Well, we're seeing it with our existing customers, but I think businesses in general will start to evaluate the old concept of buy versus build forever. CIOs have been saying buy, don't build. Yeah, yeah, yeah. But that's that's changing. Well, actually, we helped a customer recently do a gap analysis comparing the plan that um they asked us to put together for them to seven industry leading platforms that they were evaluating. And in and we're looking at I won't uh, you know, we're we're looking at uh 20%, 25% savings total cost of ownership over three years to build something bespoke for them.
SPEAKER_03Yeah. Yeah.
SPEAKER_00They own it forever. They're not paying uh and as they they're looking at it doubling their their fleet. They double their fleet, they double their licensing costs with any one of those seven platforms. Yes.
SPEAKER_01So in your case, with this state-of-the-business tool, you you said that you guys are productizing this and you're gonna offer this as a service to uh your clients.
SPEAKER_00Or the ERP, the ERP we're we're we are considering white labeling, but it's gonna be for our use only. There is, and this kind of goes back to your statement, your question about um uh do it you know, having AI do the work of junior engineers. So I want to unpack that because we do have a product that's already available now that is handling the software bill of materials management, detecting the vulnerabilities, which you know you'll recognize the language, maybe not all the listeners do, but there's common vulnerabilities and exposures. The acronym is CDE. Those are published at National Institute Science and Technology, which is funded by the federal government, other institutions. So what that is is you know, we software today is a series of building blocks like Legos, frameworks, and packages. Nobody's writing your date selection device and you know when you buy airline tickets. That's a that's a plug-in, right? Or it's a package. You know, so those things will ultimately have vulnerabilities that are detected, and you have to patch them. So we have an agentic workflow now that handles the bill of materials, CD detection, updates all those packages all automatically, and then notifies the engineering team that they need to review the quality of that before it's published. Wow. And that's a subscription now that we have several customers paying us for. But we added, we we went one better, Chris, and you'll appreciate this. And this is doing the work of senior engineers. One of the biggest challenges we have in the industry is keeping up with deep systematic technical documentation we're developing, supporting, and maintaining software. People will add comments, they might be good at it, they might not be good at it, but having really detailed documentation has always been a challenge. Out of the same platform, and this is fully agentic, every time that there's a pull request, or we can also set a schedule, all the repos are um evaluated, and that deep systematic technical documentation is generated as a markdown file for context for AI tooling to help us support and maintain these software products. So it's that's how we're using it to change the way that we operate.
SPEAKER_01So I I I want to kind of like move back towards the the pricing conversation because as a listener, if if they're out there and they are wanting to move forward with uh this new paradigm of building, like even engage with Red Hawk, let's say what should they expect the the more traditional developers to say if they say, Oh, well, we got this, we got a 25% savings from uh Redhawk as compared to what you guys would charge us with your you know established. What what do you expect that counterparty to say to the potential buyer like when they hear that we're gonna have it built ourselves and do something like this?
SPEAKER_00I think our competitors who are not adopting rapidly enough, and well, there's two types of competitors. There, there are studios that will do project-based work. They might still charge time and materials to do that project-based work, but then there are larger, much larger software consultancies that have a staff augmentation model, and they're selling you butts and seats. They're the ones I think that have a have a are probably gonna be a little bit more challenged because um they're typically it's up to the client to get value from the team. You'll describe what you want them to develop, and they're gonna say, well, you need a technical business analyst, you need a front-end developer, a back-end developer, a cloud engineer, and they'll tell you everybody that's gonna be on that team. Then they'll show you the talent that they have and they'll give you different rates for every one of those people, and you're gonna look at a minimum X number of months or even a year, year and a half commitment. And you're just paying for that team to be at your beck and call. So that's interesting. That's still time and material. So I think what they would say is well, we they I don't I'm not sure other than this is the way that we sell, and I can offer you this type of contract. I'm not sure how they would counter what we're doing.
SPEAKER_01You're you're so there's no obvious, like, oh, they're gonna say you can't trust AI to do it. They're not gonna there's there's nothing that you're hearing your your clients as they're out there shopping coming back and saying, oh, well, they said this.
SPEAKER_00They they might provide some some examples out there that to to try and frighten them off stories. Scary stories. And there are scary stories, but you know what? There's always been scary stories in tech and even in traditional software engineering. So um, yeah, I think that they would they would likely throw out some examples of things gone wrong. But you know what? That gives the customer an opportunity to ask more clarifying questions about how you prevent those types of issues from occurring. So hopefully you want them to circle back.
SPEAKER_01Silverlining.
SPEAKER_00Silverlining, yeah.
SPEAKER_01Yeah. So if they are approaching and and they're ready to do some development, the the client or the prospect, um what would they expect if they encountered uh organization like Red Hawk when it came to that and how you would how you would position this value-based as compared to, well, you know, we've been working with the same tech vendor forever. They say they can do this this too. What is that com what is that part of the conversation gonna look like with them versus you?
SPEAKER_00We're gonna look at the opportunity that of the solution they want to build and go through an early, you know, it it and this is typical with most organizations, but we're gonna try to evaluate and understand the requirements as as much as we can in the early in the in these conversations so that we can get to a value-based pricing model for that clickable prototype. Because really what we want to do is start with that front-end user experience first that can be vetted with the stakeholders, and then we can refine it before we do the back-end build. Then we re- we re-estimate a rough order of magnitude budget for the actual development work. Because we'll give you the two different fees that we think you're gonna look at, right? You're gonna encounter is clickable prototypes first, that's fixed. What comes next? We're gonna offer, and this is unique to Red Hawk because we offer a software development as a managed service. So we can be your fractional DevOps team long term, and you can amortize that investment out over that long term. So we're operating like an MSP. Yeah, yeah. Not only are we going to build this solution for you the next few months, we're on the hook to support it, maintain it, make sure it's operational, it doesn't have bugs, you don't have cybersecurity issues. That's why we have prod products like the Red Hawk software comp analysis solution I was telling you about. Because it helps all of us. If we're on the hook for how this thing performs after delivery, that's great. The competitors out there are still going to be largely either project-based or time and materials, either way, but they're thinking about new build deployment, maybe there'll be a hosting fee. They'll most likely offer you a support maintenance agreement, which will look like time and materials. Call us if you need us. And those are just basic service level agreements, which I call break fix agreements. Because you won't call them because you don't want to pay them until something happens, so you're just waiting for something to go wrong, and now everybody's in this really difficult situation. Right? So that's a break fix contract. Breaks the route, you got to break and fix the relationship, and it's not good. So our our software development as a managed service model accounts for all of those things, and our customers can see total cost of ownership over multiple years. And from a business owner's perspective, if you're thinking about building something meaningful, you're gonna think first capital expense. At some point that expense goes away, it's an ad back. And then, but you still want to know what your operating costs are gonna look like for having that software in your IT portfolio. The way we work, we can answer all of those questions.
SPEAKER_01Interesting. Well, I'll tell you this is a perfect time because as I mentioned, there's one of those software projects I I've got on the side that's actually getting some traction. It's gonna be time to bring on some more people. Um so the timing's been perfect for me, very helpful to understand the dynamic. And I achieved the goal. I wanted the listener who is gonna be encountering AI enabled or at least claiming AI enablement in these development environments to so I I there's a saying I I heard in finance, you're either at the table or you're on the table, right? And I I want my clients to be the ones that are at the table and not have a very expensive learning curve because they go there and they end up overpaying for something or they end up getting um less than they were expecting. So Matt, thank you for for kind of being that um the helping us find out how to audit our dev partners in the age of AI. Um but if people want to find out more about this this model that you guys are doing and this and the the way that you guys work, what's the next steps?
SPEAKER_00They can certainly visit the Red Hawk Technologies website, redhawk-tech.com, and uh feel free to look me up by name on LinkedIn. I'm always happy to take a conversation and just share a little bit more insight. Uh educating and and sharing knowledge is a passion of mine, so I'm always happy to have a conversation.
SPEAKER_01Thank you for that. Yeah. Um, and we're gonna have that in the show notes for everybody as well. Um so this has been great. And and thank you, Matt. I know that you guys are obviously busy with 50 devs and AI, you know, speeding up the velocity of everything for everybody, but I appreciate you taking the time and sharing this with our audience.
SPEAKER_00It's my pleasure, Chris. Really enjoyed it.
SPEAKER_01Thanks, man. So uh if you got something out of this episode or any episode, the best way that you could say thank you would be to pass this episode or any of our episodes along to somebody you know who's on the AI journey so that they can uh plug into the conversations that we're having here. And I just want to say thank you for listening to this episode and being a supporter. As of this recording, we've broken 250,000 downloads of the podcast, which is a lot. Uh we've uh exceeded 100 episodes of the podcast, which is a lot. Um, and I just want to thank everybody who uh has been there uh for the journey, both the the guests and the listeners. So thanks everybody. We'll see you next week with uh another exciting episode of Using AI at Work.
SPEAKER_02Thanks for tuning in to Using AI at Work. Don't forget to subscribe for more conversations about how to use AI at work. And a special thank you to our sponsor, Chief AI Officer, for empowering businesses with AI education and training. Visit their website for a free AI readiness assessment and AI strategy guide to help you get started using AI at work. That's www.chiefaiofficer.com. Follow us on Twitter at the handle using AI at work, and visit www.usingai at work.com for free resources to help you harness AI in your role.