Ep 64: Never Let Your Software Vendor Run Your Construction Tech Stack Assessment

Subscribe on:

Never let your software vendor audit your construction tech stack. Here’s why.

One contractor told Ascent they had to get off Excel. The real problem? Thirty versions of the same spreadsheet, one for every guy in the field, all tracking hours and job costing their own way.

In this episode of Construction Hot Takes, Adam Cooper and Greg Gorman walk through what a construction tech stack assessment actually looks like, and the mistakes that cost contractors the most. They also share a client story where the “obvious” fix would have cost $100–200K and a year of work, and what they did instead. Plus: does AI belong in your tech stack, and where does it actually help?

What’s in this episode

  • Buying “best-in-class” tools that never talk to each other
  • Switching ERPs when the real problem is somewhere else
  • Trusting a free audit from the company selling you the software
  • Making changes without looking at your company’s tech history

Timestamps

  • 00:00 Cold Open: “Change Is Disruptive”
  • 00:32 The Hot Take: Your Tech Stack Needs an Architect
  • 01:20 What Is a Tech Stack, Anyway?
  • 02:18 Best-in-Class Software That Doesn’t Talk
  • 03:23 The New ERP That’s Costing More Time
  • 04:18 Does Company Size Matter?
  • 05:15 “Are You Just Going to Tell Me to Buy More Stuff?”
  • 05:34 The QuickBooks Client Who Didn’t Need to Switch
  • 06:18 What’s an Integration (and Middleware)?
  • 07:38 How an Assessment Starts: Discovery & Current State
  • 08:46 Why Your Tech History Matters
  • 10:22 Why Not Let Your Software Vendor Do the Audit?
  • 12:49 Inside a Live Assessment: A Multi-Office GC
  • 14:16 The Technology Roadmap
  • 16:25 Biggest Impact, Least Amount of Change
  • 17:35 $200K and a Year vs. a Quarter of the Price
  • 21:16 30 Field Guys, 30 Excel Files
  • 22:20 Who Owns the Roadmap?
  • 23:26 Do You Need Procore?
  • 23:52 Is AI Part of Your Tech Stack?
  • 26:02 AI as the Glue (and DIY Middleware)
  • 28:33 Wrap-Up

Is Your Tech Stack Working Against You?

If your team is buried in workarounds, siloed data, and software that doesn’t talk to each other, Ascent Consulting gives construction owners and leaders an independent look at what they have, what’s working, and where to start.

Book a Free Consultation

Transcript

[00:05] Adam Cooper: Tech stack analysis is really like, how can I get the biggest impact with the least amount of change, right? I don’t want to change softwares. I want to change functionality, or I want to provide more training potentially, or create some type of a, I don’t want to call it a workaround. My overarching goal is typically don’t change their software. That’s like the last resort.

[00:26] Greg Gorman: Change is disruptive in business. It just is. It always is and it always will be.

[00:32] Adam Cooper: All right. So, I’ve got a topic for today.

[00:35] Greg Gorman: Lay it on me.

[00:36] Adam Cooper: All right. So, your construction software tech stack doesn’t need more or better software. It needs an architect. We get called in to do these tech stack assessments, analyses, recommendations pretty frequently now. And so, I thought we’d talk about what is a tech stack analysis that we would, what does that look like for what we perform for a construction company? Why do they call us? What are they hoping to get out of it? And what does the process kind of look like? And what do they get out of having us come in, or anybody come in, and do a proper tech stack analysis?

[01:11] Greg Gorman: This is very timely because I just had a call yesterday, on the day we’re filming this, about this exact thing. So, I’ll have some feedback. So, why don’t we start with, why don’t we define what a tech stack is for people that don’t know, because it’s a buzzword. We say it, right? Sure. A tech stack is really just all the technology used inside of your organization.

[01:30] Adam Cooper: Yeah. A collection of all the softwares you have. So you have your accounting system, your project management system, maybe a service system, inventory. You might have estimating systems. This tech stack could be softwares

[01:43] Greg Gorman: Like QuickBooks or Sage or Procore, or it could be

[01:49] Adam Cooper: Some spreadsheets in there. We could even think about your Microsoft Word, Excel, and PowerPoint files as part of your tech stack. Your email as part of your tech stack. All of it. It’s all the technology that you use.

[02:00] Greg Gorman: So we have clients who’ve just gone on to DroneDeploy. That’s in their tech stack. They fly drones every single day, which got bought by Procore. So yeah, everything you use to run your business. It’s not just accounting or just operations, sort of everything broadly based across your whole company.

[02:18] Adam Cooper: Right. And the companies that call us most frequently typically say something, what I usually hear is, we’ve got this great collection of software. We’ve got the best in class of everything, but it doesn’t really all talk to each other. And it’s kind of what they call siloed data, right? It lives in that system. It doesn’t automatically move into another system.

[02:40] Greg Gorman: And I’ll just say to follow up on that, what I hear a lot is we have all this best-in-class software, and then they add “we think,” because I think part of the problem is, I think a lot of our clients, and probably everybody, not just our clients, everybody thinks they have what they need. They think they have the best thing, or maybe they know they have something, one piece is older, one piece is new, but they don’t really know what is the best thing for them, is what I would say, right? And then should it all talk? Should it be integrated? Is it okay to have something siloed off to the side? That is really kind of where we’re going with what you asked. What’s an assessment? That’s what it is.

[03:23] Adam Cooper: The other thing I do hear is, “We got this new accounting system, this new ERP, a couple of years ago, and it was supposed to make our lives easier, but we’ve had to do so many workarounds now to make it talk to our other systems. It’s not saving us any time. In fact, we think it’s costing us more time.”

[03:41] Greg Gorman: Yeah. Yeah.

[03:42] Adam Cooper: That’s what I hear.

[03:43] Greg Gorman: I think, and then on top of that, we have the system, it’s costing us a lot of time, there’s a lot of workarounds, and by the way, it’s really expensive.

[03:54] Adam Cooper: Yes.

[03:54] Greg Gorman: Should it be this expensive? Is this how much it costs? Do we need all of this software? So we’ve probably all heard the same questions, but that’s really what we’re talking about, right? How do you assess what someone has, what they’re paying for, what they don’t need to be paying for, what they don’t yet have, and then is it all working for them?

[04:15] Adam Cooper: Right?

[04:16] Greg Gorman: Does it all work for what they need it to do?

[04:18] Adam Cooper: Right. And then the other thing I would ask, with your experience is there a threshold at the company size where this starts to become more and more important? Typically I’m working with companies that are doing hundreds of millions or more on their tech stack, but there’s small companies that call us too.

[04:38] Greg Gorman: I started my career in the day-to-day of construction at a very small firm, a very small company. We were on our way to growing, but we were pretty small when we started. We had a tech stack. Now, that was probably email and Excel, and then we had a pretty powerful ERP accounting platform. But yeah, I don’t think size matters here. I think everybody’s tech stack is what it is. I think the question for a smaller-size business is, do we need more, and then do we want to spend that money for more? Because that’s the question that I get a lot: “Are you just going to tell me, if you come do an assessment, are you just going to tell me that I have to buy more stuff?” Right? In fact, that’s what the people yesterday asked me. “Is this nothing more than you just telling me that I need to buy more stuff?” Because that’s not really going to help me if the answer is yeah, just buy more stuff, right?

[05:32] Adam Cooper: So we have a client that, when we got started with them, they asked me, “Hey, we’re on QuickBooks. We’ve been on QuickBooks for a long time. I’m thinking about changing to a bigger, more powerful construction accounting platform. Do you think it’s worth it?” And I said, “Well, let me ask you a few questions,” right? Kind of a quick analysis with them, not a full assessment, but in my quick analysis, the answer was no. For what you’re doing, you don’t need to change systems. What we could do is add a few more tools, a few different pieces of software externally that can talk to the accounting, can talk to QuickBooks, that would solve the problems you’re describing, but we don’t need to necessarily change your accounting system. And there’s no need to go through that much expense and time investment.

[06:19] Greg Gorman: And that’s another good definition, right? What’s an integration? That’s what you’re describing. An integration is either a piece of software that sits in between two pieces of software

[06:29] Adam Cooper: Like a middleware.

[06:30] Greg Gorman: Right. Right. Also known as middleware. Or something that maybe one of your software has, like a direct connection to it, already exists, and you connect two things together so they do talk together. That is all part of what we assess at Ascent for our clients: What do they have? What do they not have? What works? What doesn’t work? What should work but doesn’t? What are you paying for that doesn’t work? What should you be paying for so it will work? Right? Those are all the things, because it can get very complicated. I think people are running their businesses every day, and their technology is a tool that they need to work. So, they need it to work, and they need to know why it’s not working.

[07:10] Adam Cooper: Yeah.

[07:10] Greg Gorman: Or they need to know how to make it work better, I think.

[07:13] Adam Cooper: Yeah. I want to clarify. I think we always start with, what’s the outcome you’re trying to get to? And the outcomes should always be supporting the field activities. That’s where the construction company is actually making and losing money, is in running construction projects and managing their labor force, their materials, their subcontractor base.

[07:32] Greg Gorman: Yeah.

[07:33] Adam Cooper: So the technology should be supporting that. So, when we come in and do an assessment, I’d be curious, how do you start them off? Because I think we start them off a little bit differently.

[07:45] Greg Gorman: Okay, good. So, when we do an assessment, when I do an assessment, well, we always start every project with a discovery. We talked about that on other episodes. A discovery is, what are you doing now? How are you doing it? What do you have? So, in a tech stack assessment, what do you have? What do you currently own? How does it work? We do a discovery. We meet the people. We understand kind of how they work, how they’re working in the field, how they work in the office, what their accounting is doing. And then I go into, just like you said, what problem are we trying to solve? Now, I’ve identified that in the sales process almost always, like, this is what we’re trying to get to. But we start the discovery phase. We understand what they’re doing, in the current state. That’s what we call it, right? The current state of what they’re using their technology for. And then we start looking ahead into what do they want to do? What do they want to happen? How do they want it to work? So those are the first two steps that I do in my projects.

[08:46] Adam Cooper: Got it. I will add to that. I do the same thing there. I also try and go historical on them. What did you have before this, and why did you change this, and when did you make that change? If they’ve gotten off of QuickBooks and into an ERP, well, why did you do that? When did you do that? What was the impetus for making those changes? So, I can understand kind of the history, how they got to where they are now, current state. I find there’s a lot of value in that. I uncover, like, “Oh yeah, well, we went through that change two years ago and we upgraded our cost code systems. We had all these old codes in the system and the new codes that we wanted.” And, oh, that’s why I still see projects with old codes. Yeah, there have been multi-year projects that are spanning. So, I’m starting to get the backstory, and I find that’s very valuable for me.

[09:31] Greg Gorman: Yeah, I think the context matters. For example, if I’m looking at someone’s tech stack and they tell me they’ve been on the same accounting system for 35 years, I know probably what that means. It’s been around a long time. It’s probably pretty old looking. It doesn’t have a lot of technology in it. It’s not cloud-based, for example. But if they say

[09:52] Adam Cooper: They’re on Sage 300 or something, which is still a fantastic program, but it’s 30 years old.

[09:58] Greg Gorman: I was thinking something more like a computer, right? Or Sage 300, that kind of thing. Or if they say, “We just got this new ERP and it’s not working right.” So, I think you’re right. We have to get the context of what they have, what they used to have, and what they’re trying to do. Yeah.

[10:14] Adam Cooper: Yeah. I think that evolution is so important for me to understand the business, their business. All right. Let’s talk a little bit about, because I know people have sometimes asked me, “Well, my ERP provider said they would do an assessment like that,” or, “We’re looking at these other softwares and they offer to do some type of a free audit for us.” How is that different from what we do?

[10:39] Greg Gorman: Yeah, that’s a good question, because we are third-party experts in all things construction, and that includes construction technology. I would say we get to spend all day every day talking about this and doing this. And so, if someone says, “Well, my software company can do an assessment,” I think there’s an inherent bias there. That’s my sort of off-the-cuff hot take on that. We don’t have that bias, because what we want is what’s best for our clients. We want them to tell us, “Here’s what we’re trying to get to. We would love our four main things in our tech stack to all talk to each other. We would like our field guys to have better data that comes from the field into the office, but we don’t want them to have to touch four different systems.”

[11:28] Adam Cooper: Right.

[11:29] Greg Gorman: Right. So, we want them to be able to go and be as efficient as possible. And that’s the focus of what we want our tech to do. Well, that’s where we’re starting from. And we’re trying to find a solution for that problem, I think, and then how it ties in with all the other technology in the stack.

[11:48] Adam Cooper: Yeah. I mean, if your accounting system provider is offering to do a tech stack analysis for you, they’re going to come in with that bias of, “Well, this is what you have that doesn’t work with our software.”

[11:59] Greg Gorman: Right.

[12:00] Adam Cooper: Right. Whereas we can come in and say, “You have some great technology, but it’s your accounting system that’s actually the hindrance. Like, it doesn’t have good APIs,” or something like that, potentially.

[12:09] Greg Gorman: I tell you what else they’re probably going to say. We’ve heard this. They’ll say, “Oh, well, tell me what your problem is.” And then you tell them, and then they say, “Oh, well, yeah, our system already does that.” What the software company thinks that their software does and what you need it to do are not the same thing. So, they will sell you something and say, “Oh, of course it does that. It does it perfectly. It’s going to work for you all the time.” And the minute you get into it, you’re like, “That’s not what I need it to do. That’s not the right thing. That doesn’t look the same way that I need it to look.” Right? So, I think that bias is sort of like, don’t rely on the software companies to tell you what you need. It’s sort of the other way around.

[12:49] Adam Cooper: Right. So, what were some of the, I would say, real life, you’ve done a few of these recently. What were some of the outcomes that you got to? What did you deliver to the client?

[13:01] Greg Gorman: Yeah. Well, I’m doing one right now, which is great. And we’re in the middle of it. And we’re doing this exact project for a client in South Carolina, right? A multi-office general contractor, and their technology stack is very sophisticated. It’s very well thought out. They’ve been on most of their systems for a long time, so they know what they’re doing. And they are running up into, I don’t know what to call it, but just a lot of system chaos is what I would call it. I guess everything works a little bit, and everything works how it’s supposed to, but they would like a broader, more integrated technology stack. That’s what they want. So, what we’re looking at is, how do we take the things they already have? How do we try to understand what they’re using it for? How do we look at what they’re using it for? And how do we think ahead to what they want to use it for? So, that’s what we’re doing. We just finished our discovery phase on that project. We’re now going into kind of the assessment part, right? We’re writing our findings report so we understand what they have. We will run that by them to make sure that they agree with what we heard and what we saw. And now we’re going to start doing the assessment. We’re going to start looking at everything, and we’re going to start solving the problems that they want solved. And I expect, in the end, we expect for them to have a very good technology, it’s called a roadmap, is what I call it. I don’t know what you call it, right? Yeah. We’re going to give them a technology roadmap that’s going to be, “This is what you have right now. This is what you want to get to, and this is a map to follow.” We’re going to write it out for them like you’re following a map, like you’re driving your car. What do we get to next? And then what? And then what? And at the end of that map, there’s going to be solutions to, not all, to most of the problems they want to solve.

[14:46] Adam Cooper: Got it. I assume that, just as I do, when you’re going through the middle phase, where you’ve done the findings and now you’re trying to make the recommendations, I wind up meeting with, like, their VAR. I might work with their Procore rep. Yeah. I might work with their other softwares directly and kind of bring to their attention, “This is the problem your client is having,” our shared client now, because I’m doing this tech stack assessment. Do they not understand something, right? Or, “Can you help me solve this? How would you solve this for them, or for anybody else? Like, have they expressed this concern to you before?” So I’m often playing middleman between the client and the software provider, trying to figure out how to make it all work.

[15:36] Greg Gorman: That’s a great thought. As a matter of fact, at the time of recording this podcast, we’re going to Groundbreak, which is Procore’s annual conference in a few weeks. So, they’ve been on Procore for a long time, in this example, and they have a Procore team they’ve known for a long time. They’ve asked us to meet their Procore team at Groundbreak. So me and my colleague, who’s working on this together here at Ascent, we’re going to go meet them at Groundbreak, and we’re going to take them for a cup of coffee, and we’re going to talk to them on their behalf from our point of view at the Procore conference. I’m actually really excited about it, because it gives us a chance to meet them in person, to talk to them, and kind of get some feedback from Procore about some of these issues that we’ve surfaced in our discovery. So I’m looking forward to it.

[16:24] Adam Cooper: There you go.

[16:25] Greg Gorman: Yeah. I think the other thing that’s important about tech stack, I wanted to bring this up because I think this is a really, I don’t know if you hear this, but I hear this a lot: Is a tech stack assessment, or is a tech stack, nothing more than just telling me to buy more software?

[16:39] Adam Cooper: Okay.

[16:40] Greg Gorman: I sort of brought it up earlier, right? Do you think that a tech stack, this is a little bit of a leading question, do you think that a tech stack is nothing more than just always buying new technology? You kind of referenced it earlier, but I wanted to dive into that, just a little.

[16:55] Adam Cooper: For me, a tech stack analysis is really like, how can I get the biggest impact with the least amount of change, right? I don’t want to change softwares. I want to change functionality, or I want to provide more training potentially, or create some type of a, I don’t want to call it a workaround, it’s more like a work-through. Like, we have to redesign the workflow a little bit, but without changing the softwares. My overarching goal is typically don’t change their software. That’s like the last resort.

[17:26] Greg Gorman: Yeah. Change is disruptive in business. It just is. It always is and it always will be. Sometimes it’s necessary, but like you’re saying, sometimes it’s not.

[17:35] Adam Cooper: It’s kind of a sliding scale. Like, we’ve had clients say, “Well, I wish you would do,” I’m thinking of that one we did in Los Angeles a few years ago. They had the older accounting system and they had Procore, and they were trying to get things to work a certain way that they had seen in other companies. Some people came from other companies that had different systems, and they were trying to get their system to work like that, and there’s just inherent limitations with the accounting system that they had, because it’s an older accounting system. So we said, “This is how much change we could accomplish without changing softwares. But if you want to change software, that’s a much bigger investment,” right? I think we were talking about 100 to 200,000 for them to change accounting systems

[18:20] Greg Gorman: Expensive.

[18:20] Adam Cooper: And a year of time for all of that work. But for a quarter of that price, they could change some of the technology and some of the integrations.

[18:33] Greg Gorman: Yeah.

[18:33] Adam Cooper: And they could put a few more things in place that would get them a lot closer to that end goal. It wasn’t going to get them all the way to the goal they were looking for. So they chose, we gave them the options, we kind of laid it out for them like you said, and then let them make educated choices.

[18:48] Greg Gorman: I think one thing that I always think about a lot in technology is the old saying, less is more. Sometimes in technology, more is not more; less is more. You already own what you own. You have what you have now. If someone comes to you and says, “Look, I want to solve one specific problem,” you could probably recommend a solution for one specific problem. But if you look at something overall, kind of what you’re saying is, sometimes what you have is already there. It’s just not. Your process might not be right, or your integrations might not be right, or the training might be wrong. We don’t necessarily train on other people’s software.

[19:24] Adam Cooper: We just necessarily don’t understand how things are supposed to work, and if we just provided some training, they could get it working.

[19:29] Greg Gorman: Yeah. Yeah. Because I think cost is a really important piece here. And anyone watching this episode is probably thinking, “Look, if they just tell me to buy more software, that sounds easy, but is that going to solve the problem?” I don’t necessarily think that’s always the answer, because, like you said, it can get really expensive to buy new things, and always

[19:50] Adam Cooper: And time-consuming too.

[19:51] Greg Gorman: Very time-consuming, and disruptive and stressful, right? Because anyone that knows technology, there’s no easy button with technology, usually. There’s no “turn it on, it works perfectly, and good luck.” It’s very much, it’s got to be configured, you have to have training, you have to have testing, you have to make sure it works, you have to check the integration, and then at the end of the day, you hope that it gets you what you need.

[20:15] Adam Cooper: And you’ve got to train everybody on how this new piece of software works.

[20:19] Greg Gorman: Yeah, I think training is a big piece of this. And like I said, we don’t necessarily train on other people’s software for them, but we lay out, we give them the assessment that maybe what’s missing is training, or what’s missing is some testing, or what’s missing is that one integration that already exists that’s supposed to put two things together for them.

[20:37] Adam Cooper: Well, I love the roadmap analogy that you used. The goal of the assessment is to have an unbiased third party give you a true diagnostic view of your ecosystem, all your softwares and your technology, and then say, validate “this is best-in-class,” or validate “this is the right tool for you.” Then provide recommendations for better integrations or custom middleware. Or if they are missing some best-in-class tools and they’re still working off of spreadsheets or something like that, is there a tool that we could recommend that would be a good addition to their ecosystem, and outline how well it will integrate, and where it will and where it won’t?

[21:16] Greg Gorman: I just want to point something out, because you just said it. One of the comments that we got about this topic, I’m just going to read it: “We have to get off Excel because we have 30 versions of Excel.” And I said, “Well, what are you using those 30 versions for?” And they said, “Because all of our guys in the field,” so we’re trying to get better field data related to hours and job costing. And I said, “Why do you have 30 workbooks?” “Well, because we have 30 field guys. Every guy in the field has their own Excel document.” During the call, yeah, during the call, I sourced that there is a solution for them. Now, if we move forward, that’ll be part of our recommendation. But there are solutions that solve one or two things, and we can talk that through, help them understand it, and then help them understand what it’s going to do for their business, and then kind of be with them as they implement it.

[22:11] Adam Cooper: Yep.

[22:11] Greg Gorman: So, I’m looking forward to this project. I hope we get it, because it’s going to be exciting to see them have a solution to something that is causing them a lot of stress.

[22:19] Adam Cooper: I love it.

[22:20] Greg Gorman: Yeah. Excel.

[22:20] Adam Cooper: Once we’re done, we provide this roadmap. Who owns the roadmap?

[22:24] Greg Gorman: On my projects, the client owns the roadmap. The reason that we build it in a roadmap is so they can follow it themselves. I would never leave a client with a roadmap that they can’t read, because that seems unfair, right? So we build it, they walk it with us, we kind of think ahead, we show them the route, if you will, and then we leave it with them to determine if they want to continue down that path. And it can be with us. Sometimes it is. Sometimes it’s not. But we leave them with a way for them to understand this is something they can follow, buy, implement themselves.

[23:00] Adam Cooper: Yeah. I would say oftentimes this turns into us being the PMO to help with the technology change, and how that impacts and ripples through the organization. We’re there to help manage all of the change, not just the software, but the people and the process side of it as well.

[23:15] Greg Gorman: That’s right. And we’re doing a couple of those now, based off the fact that we built some roadmaps for other clients in their tech stacks. They liked what we had to say, and we gave them a solution, and now we’re helping them implement it. Yeah.

[23:27] Adam Cooper: Yep. Another question we often get is, “Do I have to have Procore to get a tech assessment?” And I would say definitively no. We work with plenty of companies that do not have Procore and are not in the process of getting it, or have no interest in getting it.

[23:42] Greg Gorman: I think that’s exactly right. We at Ascent do not mandate you have to have anything. We’re here to make your business run well for you.

[23:52] Greg Gorman: I’ve got a question for you.

[23:54] Adam Cooper: Okay.

[23:55] Greg Gorman: I don’t know if I have an answer yet, but I’m interested in your answer. Do you think that AI is part of a tech stack?

[24:04] Adam Cooper: Definitively, yes.

[24:05] Greg Gorman: Same.

[24:05] Adam Cooper: Or could be. If they’re not using AI yet, there’s certainly opportunities to put AI into your workflows, into your tech stack, whether that’s just using ChatGPT or Claude to do something, or having some type of an AI-empowered software. I certainly think it’s that time. It’s that day and age. It’s not going away. It’s just going to become more and more pervasive. And there’s a lot of leverage to be gained by using AI.

[24:38] Greg Gorman: Absolutely. And that’s why I think it’s important for people to know that it’s a tool. It’s a technology tool in your arsenal. So I’m just like you. I consider it to be part of someone’s tech stack. Whether they’re using it or not, whether they’re using it well or not, how they’re using it, what they’re using it for, those are all questions we would answer as part of this assessment. But I just wanted to get on the record that we both think that AI is part of someone’s tech stack and will continue to be.

[25:04] Adam Cooper: It’s becoming one of our recommendations. If you’re not using AI, here’s AI-empowered recommendations for you. And if you are using AI, here’s better ways to leverage, or other opportunities to leverage AI. And here’s other tools, either off-the-shelf tools that are pre-built, or ways that we can create dashboards with AI now very quickly, very easily.

[25:28] Greg Gorman: Yeah.

[25:29] Adam Cooper: It can synthesize the data between disparate systems. It can give you reporting that you’re looking for, and it can be taught how to do routine tasks already.

[25:39] Greg Gorman: I mean, sort of what you’re saying is, what we’ve seen, I think anyway, right, as we’re going down this AI path that we’re all on now, I think what I’ve seen is that AI fills in some of those blanks inside of someone’s tech stack. Maybe it does some of the things that maybe your other systems can’t do on their own. It’s sort of the glue that could hold your tech stack together. Maybe.

[26:03] Adam Cooper: Sure. Well, I mean, you just talked about somebody having 30 different versions of a spreadsheet coming from the field. You could use AI to compile those all every week, to get the data normalized so it’s actually usable.

[26:14] Greg Gorman: Now, that’s a great example. You could get a system that would get rid of those 30 spreadsheets, or you can use a tool like AI to keep your spreadsheets, if you like them, and try to consolidate that data into one thing. There are options. A tech stack is not one thing. There’s lots of things put together, and there’s lots of solutions.

[26:33] Adam Cooper: Yeah. I think, like the way you said it, it can almost be the glue that holds these pieces together and maybe prevents you from having to go through some major technology change, because you can use that tool to kind of fill the gaps.

[26:48] Greg Gorman: That’s what I think we’re probably all seeing, and I think that’s what probably some of our clients are thinking, which is why we’re talking, I think, about what does a tech stack analysis mean, or what does an assessment mean? It means looking at everything that’s out there and determining what’s best for your business.

[27:04] Adam Cooper: Custom middleware used to be a very expensive proposition, but it’s becoming very affordable now with all the new coding tools. And I think that we’re going to get to a point in the next few years where you’re just going to use AI to build your own custom middleware.

[27:20] Greg Gorman: I 100% agree. Or if not, you’re going to build 80% of it, or you’re going to get a lot further down the road on your own now than you used to.

[27:28] Adam Cooper: Developer cost should be coming way down on custom middleware, if things go the way I think they will.

[27:33] Greg Gorman: And the other thing that’s really interesting is, what are all these softwares going to do in response to AI? Are they going to make things better? Are they going to make things cheaper? Are they going to make things easier to use? Are they going to bring AI into themselves and let you do it through there? I mean, there’s a lot of questions to answer about what technology is going to look like with AI, but I think those are undefined right now. Those are undefined answers.

[27:59] Adam Cooper: Yeah, I would say I would be surprised if in the next three years every piece of software doesn’t have AI built into it. Like, if you don’t have AI in your product in the next couple of years, nobody’s going to buy it.

[28:15] Greg Gorman: I just got, I was on Instagram this morning, and I got the first pop-up for Meta’s embedded Instagram AI. Didn’t even know they had that till this morning. So, I think you’re right. I think every company is going to either do a version of their own

[28:30] Adam Cooper: Or there’s going to be a connection to where that’s

[28:33] Greg Gorman: That’s just how it’s going to be.

[28:34] Adam Cooper: Yep.

[28:34] Greg Gorman: Yeah.

[28:35] Adam Cooper: All right. Well, this has been a lot of fun. Thanks for your time. I appreciated the conversation, having this conversation around tech stack analysis, and trying to help educate people about it. Check us out on YouTube, Spotify, Apple, wherever you get your podcasts. Like and subscribe, follow, read the show notes, and everything else. We’ll see you on the next one.

Share

Recent Episodes