The Software Dilemma: Build It or Buy It TRANSCRIPTION

The Software Dilemma: Build It or Buy It? 

June 28, 2024 

Join us for an insightful webinar featuring Brett Wooden in conversation with Max de Lavenne, CEO of Buildable Works, as we delve into the age-old question: Should financial institutions build their own software solutions or buy off-the-shelf products? 

Brett: Welcome everybody. My name is Brett Wooden. I'm the FI [Financial Institutions] software strategist at Buildable, and I'm really excited today to be joined by Max, and Max is going to talk today about the software dilemma. Should you buy or should you build? And so thank you very much for joining us today, Max.  

Max: Thank you, Brett. Yeah, absolutely. 

Brett: Well, why don't you give our listeners a quick intro on yourself, a little bit about Buildable, before we jump into that Q&A.  

Max: Yeah, sure. So I'm Max De Lavenne. I'm the CEO of Buildable. I've been a software engineer my whole life. I’ve been building applications for a long time, interfacing with applications that we've bought, that were bought, or building applications from scratch for the past essentially 30 years. 

And Buildable is a company that I created about 15 years ago – a little bit more than that. We went through a few names, and today there are about 40 of us at Buildable, and we do a lot of innovations. We build applications, we configure applications, we build AI stuff, we do designs, we do UX. A lot of it is around doing some pretty clever software engineering.  

Brett: Nice. That's great. Thank you. And well, you know, jumping into this buy versus build, my first question would be: What are some of the factors that, when you look at financial institutions like credit unions, community banks, even some of the fintechs, what are some of the factors they should consider when looking to build or buy?  

Max: Oh, sure. Yeah, it's a great question. There's so many parallels between all these industries and the construction industry and sometimes, you know, you go to Lowe's, and you need a cabinet, you need a lamp, you're not going to build that, you're going to buy that. But then there's times you're going to go to the sections at Lowe's, you're going to get the wood, because you need to make a fence, and the fence is not something you can buy, it's something you have to build.  

And a lot of it is similar to the software industry, and especially in the financial space, there are some products that need to get purchased, that should be purchased, things that are commodities. So some of the factors are identifying if the product that you need is a commodity, which is something that's widely known or accepted or a standard in the industry. Or if it's something that needs to get molded into an existing process inside the company. 

And whenever you start having to mold a software into a process that you have, that's usually when you need to start considering building it. Because while you can buy something, you have to buy something that is highly configurable. And in one moment, you're going to find yourself struggling with maybe some configuration settings of things and finding out that there's this thing it really needs to do that it just can't do. So then that's really where I would say the decision factors are. You have to tell the difference between whether you should buy a product, whether you should build it.  

Another factor would be also the appetite for going down the build route. One of the factors you have to know is that when you build something, you have to be flexible and you have to be understanding that you're embarking on a journey. And it means the software vendor you're going to work with and your team will collaborate. And this collaboration needs to lead somewhere. 

And we have some wonderful, success stories to share about that, but we can talk about that later. And so that I think is a factor, the willingness of the team to essentially embrace change. Because whenever you start building, it gets very exciting very quickly because you start to see things that you exactly want and you get the things that you want. And you do not get the things that are present in other applications that you would purchase and you're like, ‘I don't need that’. So you cut down on distractions.  

“[Building] gets very exciting very quickly, because you start to see things that you exactly want and you get the things that you want.” 

Brett: Yeah. And one other thing to just chat about with this too is that a lot of times the institutions are, I would say, victims of their vendor or victims of their core. So you've got this core server that holds all the members’ data and you're trying to plug other things in. And sometimes they don't work. Sometimes there's charges for that extra development that needs to take place. And so what's your advice with that when you've got to have the core, right? And typically that's something like you said, it's like the lamp or the maybe framework. 

Max: Yeah, absolutely. So I think things like the core is something you have to purchase. I think that there's no way around that. I mean, building a core is a big undertaking. And so, unless you're a very large bank with big resources – in that case, you should consider it. But you have to weigh the pros and cons about that. Are you going to spend a lot of money getting something that you could get already and you're going to get just marginal? Are you going to extract just marginal benefit? And I always talk about that marginal benefit. A marginal benefit is a benefit that isn't really a benefit. You just get a little bit of an advantage. The savings you get from that advantage does not justify the outlay of expenses.  

So I think the core is definitely that thing that you need to get. But when you talk about the data, there's one thing you talked about right there that I like a lot, which is the vendor lock-in. The vendor lock-in is a problem in the industry. Sometimes you get some vendors that sometimes, it just happens that you get the software from this company and they make a bunch of promises. 

And you sign on the dotted line and you get the software and you realize that the person that sold the software may have told you…but actually it doesn't do that. ‘Well, yeah, of course it does all this.’ And then you look under the hood and you realize, ‘Okay, it doesn't do it actually really well, as well as you told me’. And then you say, ‘Can you make those changes to adapt to my situation?’ ‘Yeah, sure, we can do that. It's going to be available 18 months from today.’ And then you go, ‘Oh, but I need it today.’ 

And say, well, it's on the product map. You end up essentially in the vast majority of the accounts that the vendors will try to accommodate. But you know, a vendor is trying to make a product that's stable for the vast majority of their clients, which is what they should be doing. 

And sometimes they have little incentive to want to make a customization for just one or two clients they have. And then you start to fall into the vendor lock-in issues, which is, well, you really want these features, they are important for you. They're just not important to the vendor. And they're not going to change that product just to satisfy you. Then you have to start to wonder, okay, maybe I should have built it. 

And at times in those situations, by the way, you can build customizations around that. And oftentimes, these are the factors there. So essentially, I think that, yeah, there's definitely some of these. 

Data security also is a big one. When you start to embark on another vendor system, you are tributary to their security practices. And sometimes that's good. For example, if you're a small credit union, you may want to ride the compliancy of a vendor that has a big reputation – and you know that. If you're a small organization, you might live with the limitations of that vendor because you're riding their security compliance. If you're a larger organization, or if you have different goals for growth, then maybe you can actually think about that. And you can build some pretty secure applications. I know it's all the news. It isn't as hard to build a secure application as people think. It's usually about organizing processes and working around the details. 

“It isn’t as hard to build a secure application as people think. It’s usually about organizing processes and working around the details.” 

Brett: Yeah, that's good. And kind of going back to the, you know, the common pitfalls and challenges that organizations face when building software. So if, you know, let's say you've got a financial institution on the line listening to this conversation right now, and they're thinking of building their own software. Let's say maybe they're CDFI certified. They're looking at building an application for a specific community that they serve. What are some of the common pitfalls and things you see that people get into when they start, you know, building their own software?  

Max: Oh, sure. Building a software, well, we can talk about pitfalls and we can talk about doing it right. So we're going to start with the pitfalls. First of all, not putting the right team together, not having enough time dedicated, not planning for enough time, or having unrealistic expectations that the software manager will just, be a mind reader and will just create magic for you. Or not having the right budget developed. And not realizing that building the software is half the journey, we're going to uncover processes that people haven't talked about. Or people will do things that never get documented or anything, and we're going to find ourselves with undocumented procedures, and organizations are going to realize that. 

Those are some of the pitfalls. Or trying to go so fast that you're not necessarily vetting the right technology sets, or not necessarily vetting the right vendors, or using relationships that you have in your network, thinking they can actually build software, but they can't. And so these are some of the pitfalls out there. 

Now, I can talk about doing it right. Doing it right is always embarking on a discovery period. You have to do a little bit of discovery, and discovery isn't this, like, weird, nebulous way of figuring out what to do. 

Discovery is all about a discovery period that is essential to create the blueprint, the same way as if you were to embark on a building. You're going to hire an architect, you're going to do some feasibility studies, you're going to figure out what to do, you know, you're going to do some land surveying, you're going to figure out what to do, the same thing in software, and that is a sunk cost. You may end up not building the software, you may end up not building a building, but it's easier for you to spend a little bit of money figuring out how to do it. 

So doing it right starts with the discovery period, where you're going to build the blueprint of the software you're going to build, you're going to design the lay of the land, you're going to start designing what we call the MVP, the Minimum Viable Product, you're going to start prioritizing all the lists of things you would like to do. Figuring out the key players, getting in touch with the different vendors that you have to interface, talking to every single person in the organization that could potentially be working on the software, because everybody's voice matters.  

And what we found out over time is that it's not the person that talks the most that necessarily has the most valuable insights. There's always one person that talks the most, that wants to get exactly their things, that are kind of pulling the cover their way. And the people that we really pay attention to are the quiet people in the room. These are the people that actually have vast amount of things to say, or do things differently. And so, those discovery peers really are here, and we talk with every single stakeholder, and we get the story, we condense it, we then produce a blueprint, and we review it with the stakeholders. And we are able to essentially create budget guidelines, and those are flexible. 

So that's one way to start, to do it right. And then it's putting the right team together. And the right team is always a funny thing. You could say, oh, everything is right. Well, the skill set to build the software is a mindset. First of all, we're very good in general. The vendor you work with needs to be very good at working with different personalities.  

And the second thing is to know that there is a plan, and we're all going to get on the bus, and the direction is somewhat to go to the north, but we're both going to be on the bus. And actually, the right direction, as we start to build the software, it might actually be slightly northwest, slightly northeast, or some is just east, or some is just west. And it happens sometimes, we just actually go the other direction, south. But not south in a bad way, it's just a different direction. And that's a flexibility of building. 

You essentially get to mold the direction you want to go based on the needs, and things are going to appear. So those are the right things. And embracing change, embracing the fact that building software means that you're going to get things, and you're going to discover things, and it's going to be good for the organization, and you're going to end up in a better spot than you thought. And it's not as complex as you think.  

“Doing it right is always embarking on a discovery period.” 

Brett: Yeah, and you actually bring up a good point when you're talking about building the team. One of the questions I always get asked by credit unions is, ‘Hey, we're going to build our own software platform, or should we hire developers in house? Should we hire the staff in house? Or should we outsource to a company like Buildable?’ And what's your thoughts on that?  

Max; So, I mean, it's all about cost. There's validity in this comment. And the thing that people need to understand is, if you're in the business of being a software company, then you should hire software developers. If your primary business is banking, maybe you will not be able to know how to manage software developers. Software developers need to be managed by companies that understand software, and that's in the process.  

And software development is usually part of R&D. So there's research and development. And the research part is important, because we constantly have to learn new things. So, typically, when people tell me, ‘I'd rather hire a developer because you guys are too expensive’, I usually respond to that, ‘Well, no, that's not true.’ If you hire a developer to build your software, you're now adding a recurring expense that's going to be year over year over year over year. You will always have a software developer in your company.  

So if you hire a software developer, the multiples of that over ten years is going to be above one million per developer. So each software developer you're going to hire is going to be one million for ten years, essentially, to the business. And you cannot just hire one developer, because you need to have redundancy. And that's where it comes in. Someone's going to have a baby, someone's going to be on leave, someone could be sick, someone may change jobs. 

And all of a sudden, you find yourself with having to retain what we call domain knowledge. And so if you're a software company, where building software is part of your business, then you usually have a team of five to ten developers. That's kind of what you need. That's the right team of developers. Hiring one, two, or three developers is not really a solution. That's actually dangerous, because you need a UX person, you need a back-end person, you need a person that can manage products. 

And I don't want to build a house, I'm just saying, you need those skill sets. So one developer alone will never have all these skill sets. It's like hiring somebody that's a tiler, that can do roofing and electrical and all this. And then you're looking for a jack of all trades, and we all know that doesn't exist. And so at the end of the day, if you're hiring developers, you have to hire a minimum of three or five.  

So that's an expense. At the end of the year, it's going to be half a million, if not more of an expense. And that's just for one year. And then you have to keep that for 10 years or more, because the software is going to outlive everything. And so that's a big expense. Now you find yourself facing a five million dollar expense.  

Hiring a company like ours, well, that's when we come into play for companies that do not or should not have software developers on staff. And usually the cost is actually a lot smaller. Let's talk about a cross-domain company, you pay a little bit more on an hourly basis, but you pay for the rotation. And you pay for the cross-domain knowledge. Meaning we always have engineers that rotate on projects. The knowledge is essentially transferred. So there's always somebody that's ready to work on the project, and that's always there. 

You've got support, you've got maintenance, you've got changes. Also, we constantly learn new technologies. The right software firm should always learn new technologies and learn new things and new methods, stay on top of the regulations, stay on top of the security issues that are published, stay on top of all that stuff. And that's what you get with a software firm. 

And it's funny, we should talk about that. We are always hiring people, because we're constantly growing. And so it's always interesting because we find people on the market sometimes, and developers. And the thing that's funny about people, people sometimes don't like change. So sometimes you find developers that don't like change. And we find people that have been working at companies for decades, and they find themselves in the job market, and they've never learned anything new. And they never needed to.  

And that's a danger when you're a credit union in a financial industry. And if you're a small one, you think about hiring a couple of developers, you need to know that they're not going to have the support from the organization to instantly want to innovate or learn new things. They're going to be busy, and they're going to run short on time to want to learn new things. And that eventually is something that has a time expiration on it. And then you find yourself in a different spot. 

So for the software firm, the benefit of it is really getting that team rotation, the time, and also the expertise you can get. Also, we can hit deadlines by swirling a team of two people to like ten people, or by bringing four designers to work on something, work with you on something, or something else. And also, you have these flexible avenues to where you can accomplish a lot more. 

And by the time we're done building, then you find yourself in a maintenance zone with a fraction of the cost of any engineers and staff. And you find yourself with the total cost of the software to be a lot cheaper by several orders of magnitude than if you were to hire an entire team. Hopefully, that helps you. 

“By the time we are done building you find yourself in a maintenance zone with a fraction of the cost of having engineers on staff.” 

Brett: Yeah, it does. It's funny because one of your comments made me think of when I was a CIO at a credit union, we had a developer on staff. She was phenomenal, right? But she was so good that we would throw all these projects at her. Like, you know, we did a debit and credit card conversion, online mobile. And so, she was helping. And one of the times I sat with her during a one-on-one, and I go, ‘Hey, I need you to go out and spend some time observing your work with the staff use’. So, she had programmed in, I think it was like getting email addresses or something from members. And I remember her going, ‘I don't have time to do this’. You know, ‘I'm too busy’. 

You know, and like you said, you get kind of sucked into the day, and especially now with things moving as fast as they are, they've got more and more projects they're doing every day. So, kind of going to your other question of like the software lives on forever. I'll ask this in two questions for you. The first one is, if you've got a vendor that you're using, so you're buying the software, how do you ensure that that software is going to stand the test of time? And then the second part of that question is on the build side. So, if they're building software, how do they ensure it will stand the longevity and the change that technology poses?  

Max: Well, that's a really good point. Well, the first one, if you're getting software from a vendor, you're just taking the chance. Today, they may be good. Today, they may be on top of it, but they may become outdated because maybe there's gonna be some management changes later at the company, with the vendor, and you don't know. And maybe the choices they are making today are logical, but you just don't know because you just don't, because the software you use, you just will not know what language it's written in. You shouldn't know, it's just not part of what you know.  

So, when you buy software from a vendor, you have no clue. It could be building COBOL for that, you know. And we know what that did to the industry. There is still some COBOL out there that exists. And so, you just don't know. Is it going to last forever? It depends on the company, the culture of the company, the vendor. But we all know, culture changes over time. I mean, if you look at the major companies that are around right now, what they were 30 years ago, some companies went through a complete turnaround of culture. And you can look at Apple and Microsoft to see the change of culture. And that has an impact. 

Or are they going to abandon the product? So, you don't know. But some companies are going to be here, are going to be doing a good job. But yeah, eventually, the technology they have, they will need to evolve it. And now, you're going to trust what they're doing. And you got to trust blindly. But we see it. We do see it. I do see when we use, for example, some major national banks, when we use their systems, we see the JSPs extension. It means they're using Java, which means they're using Tomcat behind it. And I'm going, oh my god, that train, it is time to retire that train. That explains why. Some of the things were just difficult to do. I can see the complexity of them now managing this. And I'm going, oh god, some software engineer out there is going to have a tough time changing the infrastructure.  

So, when you build it, how can you make sure the software lives on forever? So, first of all, you have to know that the database will live on for far longer than the software will. That's just true. We see databases. And the data will eventually get warehoused, maybe in some different databases. But the data you got is going to outlive the software. That's one.  

And then the second one is, well, the software will have to get designed on a platform, I always say this, that's supported by the major, you know, major companies, largest communities of developers, and always with an eye out for change, making sure that you're not overly committed to the platforms that you use, so that if you do need to make a change, you don't find yourself completely locked into the platform. That's really important.  

And that's more of a software engineering decision, architecture choice. And we make those. And we make those carefully, by the way. There's always, you know, the software engineering industry is kind of funny. When you build software, you have to know developers, they always follow shiny objects. They will always want to follow that. And it is filled with shiny objects all around. And we just want to use that, but there's a lot of them we need to stay away from. We don't know. That's not a shiny object. That's a fire. Don't touch that. And, you know, that's kind of funny. But it's actually true.  

So, how do you ensure that? Well, first of all, if you start to build the software, and you've never heard of the language, you've never heard of the company, these are signs that maybe these aren't good things to use. And there are products. And also, you know, usually say, well, you know, we don't use alpha products. We don't use beta products. We use, I would say, really professional grade tools. 

And that's really important. Mechanisms to avoid doing certain things that are good. And then sometimes you have to embrace the fact that you have to rewrite portions of the software. A software application is always like a rising tide. It's a tide that never stops rising. And when you use it, you're an island in that ocean. And the water level is constantly rising. And at one point, you'll be underwater. So you essentially have to keep rebuilding portions of the software here.  

And that essentially means that you have to embrace that and accept it. You can choose not to accept it. That will lead to certain consequences that you have to live with later. But you have to accept it, it will change. I don't have a crystal ball and I'm not a mind reader, but I do know that some languages will stay around for longer than others. And you will have to modify and you'll have to test things and always have an eye out for what's out there. 

For example, AI right now is very big. What's out there? How does that impact things? How does that change things? And then you have to assess that, do some test projects, proof of concept, and start to modify pieces and treat this not as it is, as a status quo, treat this as a living organism that's going to have to evolve over time.  

“I don’t have a crystal ball and I’m not a mind reader, but I do know that some software languages will stay around longer than others.” 

Brett: Yeah, so let's talk a little bit about that too. Our listeners are typically credit unions, community banks and fintechs. What are the trends that you're seeing? You mentioned AI. So tell me a little bit about that. Like when we talk about AI, what in that are you seeing?  

Max: Oh, the trends of AI are fascinating. So first we have to debunk a couple of things. AI is not going to replace software engineers. Let's just put it out there. That's not helping. 

The generative functions of AI are also something that we're seeing a little bit less use of in the companies. But the thing that we see AI really taking on is the ability to digest large bodies of information and query things, query search data, search files, search documents with using what we call natural language. Something you would just write as if you're talking to a friend or another person, and then being able to translate that, create the queries, query the data, come back with the results, concise, and being able to draw and infer. And that is really where we see it work really well.  

And by the way, none of that is new. None of it is new. We just have a new kid around the block. And it's pretty cool because actually machine learning, which is what we're talking about here, was very difficult back in the day. It wasn't difficult, it required a lot of infrastructure and setup. The AI movement that is going on right now essentially has lowered the technical barrier to be able to conduct the things we do in machine learning without having to have a machine learning degree or anything like that.  

You can actually do things fairly simply now. And the barrier of entry has really been lowered, which is fantastic. Whenever you do that, it creates more innovations. People that weren't able to enter the space now can. And it creates huge innovation down there. So we see that change. It's changing all of the things. It's changing our behaviors is what it's doing.  

And in the industry, where we see that happening now is, for example, being able to do some deep searches on content or being able to extrapolate on things, being able to do quick computations on the fly and answer some quick questions. It does really well. And so I do see that coming quite a bit. 

It does help. As software engineers, we do use it. It helps us sometimes explain a couple things. It's an incredible assistant. It's the best assistant that's ever been created right now. So we use it that way. And for creating unions and fintechs, there's definitely a lot of opportunities for using it. But we have to do it.  

But it's kind of funny. There's a saying around the racetrack that we always say that going fast is going slow. And you have to move slowly to go very fast. And it's the same thing here with AI. You have to move slowly by experimenting in order to move fast. And same thing here.  

“AI is the best assistant that has ever been created.” 

Brett: Yeah. One of the other things that I've heard is this is kind of like the new gold rush, a little bit of everybody's trying to create their AI products and things. Do you feel like there's going to be like the dot-com bubble or even, I've heard, like AI Winter where all of a sudden it's just going to stop for a while?  

Max: I definitely think that we have an AI bubble going on right now. 100%. Because I think that the public doesn't understand what the AI tool does. There's a lot of misinformation. I see some very sharp people, very smart people talk about how AI can help them do things, without actually knowing it's not possible. The strong things they're talking about. They think it's magic.  

I's kind of like in business school. You know, we'll have a business plan. Okay. Here's a business plan. And then, you know, you have the hockey stick because we're going to China. It's like, wait a second, I have this idea and then I'm going to use AI and it's magic and I'm going to have all this. There's a little bit of that going on where people treat AI as if it's a magic tool. It's going to solve everything. And actually we as users of it in the industry, it requires a lot of fine tuning. There is a lot of misses, meaning we have a target and you're trying to hit it and you hit it a lot, but there's a lot of missing around it. And so right now we're experimenting. 

There's a bit of exhaustion going on. For example, a lot of coders were using a little bit of AI, but right now, honestly, if you're using AI to code, you find yourself better off learning actually how to code because you will get results far faster than if you have AI code it for you, because it makes mistakes or it does things differently, or maybe people don't understand what it does. And so, so there's a little bit of that bubble there, maybe. 

But I do think that there's some exhaustion right now going on, people are exhausted using the tool, because they're realizing the results they're getting, they're getting marginal benefits because they don't use it properly. So I think it's going to slow down.  

There's also a lot of product that's being created. And quite frankly, we can’t catch up. I mean, as software engineers, and even as users of AI, it's very difficult to catch up to all the new things that are created. And also, because it's hard to catch up, it's hard to digest. And it's very hard to see what is the impact of the things we're implementing. 

And some of us that create unions and fintechs, and other clients that we have, start to get a little bit of stage fright, which is, ‘Wait, why am I going to invest into this product if two months later, there's a new one coming in, and it's going to undo all the stuff we just did? So I'd rather just sit and wait a little bit, and wait until things settle, and the players settle, and get down to where there's essentially three or four major players in the industry.’ And there's a little bit of that out there right now. And I'm not going to say that there's a bubble. I'm just saying, I'm seeing signs of it. 

Something I would say in software, the more things change, the more they don't. And that is, oh my God, that just runs the world right there. And things don't change here. 

People embrace the new technology. We'll take too much at one point. At some point, too much of a good thing is a bad thing. Then we'll reel it back a little bit. And then we're going to start to tweak it and use it the right way. The thing that I think doesn't exist, where I think there's not a bubble, is that training a model, training a large language model, is extremely costly in terms of resources, and physical resources, and money. 

You do not have that many people using it. It's not like a dot-com bubble, where all you need is a computer and an internet connection. You can make a website, and off you go. This is different. Learning, building a language model, training one, is actually very costly, very complicated. And it's also a very highly technical field, and very complicated. 

But I do think everybody is watching it, to see what we can do. It's kind of like throw and see what's next, you know? There's a little bit of that going on right now.  

“The more things change, the more they don’t.” 

Brett: What I think too, is the access to data, I know within the financial space there's more data than they even know what to do with. And I just remember working in that area, you're like, ‘oh my gosh’, like I could tell where our members were spending their money at, exact locations, if there are habits, those types of things. But it's like you said, if you don't have the resources to utilize all that data, it's tough, you know?  

So last question is a kind of similar to the buy versus build. I've been hearing, you've got like Gemini out there, which is for the Google suite. You've got Copilot, which is for Microsoft 365, where they're kind of like these tools that have been created, that can integrate within the suites. Do you, for an individual, if they came and said, ‘Hey, should we use those in our environment, or should we build our own?’ What would you recommend, or what would you say to that?  

Max: Well, if there's a tool, I mean, if there's a tool that exists, like I said before, that solves your problem, and it's been fine-tuned, and actually is pretty much a 99% hit on your target, then you should be using that. 

Now, all these tools are made different, and some have specific purposes. So Copilot is an example of a tool, okay? And sometimes they're hard. By the way, AI makes sense when it's customized to your situation. And that requires getting pretty involved and building your own AI integration, your own AI tools, because only you can access your tools, and only you can know how to fine-tune the model so that it extracts the right information. Only you know that. 

So when you buy a tool from someone else, you're guessing, you're hoping, you're hoping that the tool will be able to magically get all the answers of your data. And that's when, you know, usually, that's really when the veil opens up and you realize, ‘Ah, geez, I should have known better. I need to build it.’ 

Yesterday we were looking at some tools with our VP of engineering to do some things, better. And we did a deep dive into some of the technologies that are there. And, you know, there are really three major, I would say, AI assistants that are coming up. And if you look at, for example, what OpenAI is doing (and others are following suit) there's some things that are cool out there. 

A, a lot of the AI companies right now are following the same API standard, which is really important, which means for you to switch language models later will be actually fairly easy. They are all following. It's kind of like the industry is following OpenAI's lead on that. And the APIs are compatible. So that means that if you need to tweak things, you can. But the other thing is you have these assistants, and right now they're experimenting with it. 

But there's a couple of things you get to do. And, you know, the biggest benefit of AI is not to throw some data that's limited, and for it to try to get some answers for you. The real benefit of the AI tools and machine learning tools is essentially to unleash – is to harness, not unleash – harness the power of AI on your data stores. That is where you will have to implement that. There is no tool you can purchase that can do that magically. You will have to do that. 

And that's when usually you get the best benefits of it. And for that, there's a couple of things you can do. There are three things you can do. A, you can use definitely what we call a file, you know, something that allows you to index files, and you build file databases. And you can search through that, build through it, and essentially extract information.  

The other one is you can do what's called embeddings. And essentially it means you submit your dataset to an AI tool that gives you a very large vector with all of the points of the datasets there. And then when you search it, the search that you do creates an embedding of your search, like another vector of your search text.  And then you can hit the database with all these vectors. Then you can actually start to get some really good correlations. So that's something you get to do. And that is definitely something you have to do. There's no magic. It's something you've got to do. And then you have to tune that to figure it out, to make sure it works right. 

And then the last one usually is the copilot’s approach and unleashing these tools. And then, obviously, these are just for today. Who knows what tomorrow is going to be made of. 

“If there is a tool that exists that solves your problem and it’s been fine-tuned and does a 99% hit on your target, then you should be using it.” 

Brett: This has been great. We've kind of hit the time block. But well, I always like to, I'm an 80s kid, so I grew up watching Mr. Rogers. So any final thoughts? I always like to end with that. And do you have any final thoughts for the group?  

Max: I think the final thoughts on build versus buy – I always like to say talking with a network, it's important to talk with an outside vendor to help you make that decision. And companies like ours are pretty neutral when it comes to this kind of decision. And we'd love to, you know, help people out and be able to have that conversation that says, ‘Okay, now actually you should buy this; this is something you should buy’. 

Because we have no incentive in building something to get people to have a product and they're going to say, ‘Well, I wish I'd known, you made me build this, and then I could have bought it.’ You know, we don't have that kind of angle. We're pretty neutral there. So I would say, get some advice from people. Talk with more than one software vendor on whether you should build or buy a particular thing.  

And do some regular assessments. Do at least a yearly assessment of your software landscape to realize where you have gaps and where you have redundancies and where you have opportunities to streamline and limit double entry. 

That really is it. That is where you start to get into the zone of building something. And it's exciting. 

“Do at least a yearly assessment of your software landscape.” 

Brett: That's awesome. I love it. Thank you. Well, thank you again for joining us today. Another thing too is that Max was interviewed by our content creator. So his blog post of Q&A about what makes a good software development team is live on LinkedIn and our website. But thank you again, Max, for joining.  

Max: Thanks Brett.  

Brett: And stay tuned. We've got a couple more of these coming out in the next couple of weeks. 

Max: Super cool. Thank you. It was a pleasure talking with you today. 

Brett: Yeah, thank you. 

 

End Interview 

Thank you for joining us!