🎙️Transcript: Build vs. Buy - Infraday Mountain States

Infraday Mountain States • Denver, CO
"The Great Debate: Build vs. Buy"
Moderator: Cari Stieglitz (Kaivolve)
Panelists: AJ Waters (Kahua), Ralph Barsi (Kahua)
June 24, 2024

📺 View on YouTube

Summary

This entertaining and insightful debate tackles one of the most critical decisions facing construction organizations: whether to build custom software in-house or purchase off-the-shelf solutions.

AJ Waters and Ralph Barsi engage in a playful yet substantive discussion that intentionally blurs the lines between the two approaches, ultimately revealing that the binary choice itself may be outdated.

AJ opens by championing the buy side, emphasizing that commercial software comes ready on day one with built-in best practices, professional training programs, and ongoing maintenance and scalability handled by the vendor.

Having experienced building software from scratch twice at Kiewit before finally deciding to buy, AJ speaks from hard-won experience about the hidden costs and complexities of the DIY approach, particularly around creating training materials and managing the testing and maintenance burden.

Ralph Barsi counters with passionate advocacy for building in-house, arguing that no matter how "off the shelf" a solution claims to be, software vendors simply don't understand your specific business the way you do.

He points out that industry best practices often ignore fundamental construction concepts like change orders, back charges, and production factors because they're built by technologists rather than construction professionals.

Ralph emphasizes that building your own software provides ultimate flexibility to add features, automate workflows, and maintain competitive differentiation without waiting in feature queues or paying vendor upcharges.

However, as the debate progresses, both speakers begin subtly shifting positions, with Ralph acknowledging the value of standardization and AJ conceding the importance of nimbleness and quick adjustments.

The debate's clever structure intentionally leads to both debaters switching sides by the end, demonstrating that the real answer lies in a hybrid approach.

Moderator Cari Stieglitz brings the discussion full circle by introducing the concept of low-code platforms that offer the best of both worlds—software that works out of the box on day one but provides the flexibility to configure and customize as business needs evolve.

She shares real-world examples of clients who stood up systems in 60 days and later reconfigured them when delivery models changed.

The session concludes with unanimous agreement that the future of construction software lies not in choosing build versus buy, but in selecting platforms that offer immediate value with the configurability to adapt to unique business processes without requiring a decade-long commitment to a single implementation partner.

BIG Takeaways

• Off-the-Shelf Software Provides Day One Value with Built-In Best Practices – AJ Waters emphasizes that commercial software's greatest advantage is immediate usability—it's ready to deploy on day one with lower cost and faster implementation than custom solutions.

More importantly, vendors have already done the heavy research to identify and build industry best practices into intuitive workflows, so users instinctively understand how to click through processes.

This includes professionally developed training programs, which AJ notes from painful personal experience is "a lot more work than people give it credit for" when you have to create everything from scratch.

Additionally, commercial software comes with ongoing maintenance, rigorous testing, and built-in scalability, meaning as your company grows, you're not responsible for upgrading hardware or becoming the de facto IT help desk for every bug report.

• Building In-House Protects Competitive Edge and Business-Specific Processes – Ralph Barsi argues that the fundamental problem with purchased software is that vendors simply don't know your business as well as you do.

Many "industry best practices" ignore construction fundamentals like change orders, back charges, and production factors because they're designed by technologists focused on software rather than construction operations.

When you build in-house, you maintain competitive differentiation because you're not using the same system as all your competitors, and you can implement the specific standard operating procedures that have driven your company's success.

Building also provides ultimate flexibility to add missed process steps, automate new workflows without vendor upcharges, and make changes whenever you want rather than submitting feature requests that languish in a queue because they're "not a priority for other customers."

• The "Always Done It That Way" Paradox Reveals Hidden Assumptions – During the debate, when Ralph argues that successful contractors do things a certain way because "they've always been done that way," AJ immediately counters that this is "the most dangerous phrase in business."

This exchange highlights a critical tension: while established processes may have driven past success, clinging to them can prevent beneficial standardization and efficiency gains.

Ralph's character acknowledges that sharing resources across projects with repeatable processes could decrease time to ROI and increase efficiency, revealing that the real question isn't whether to preserve every unique workflow, but rather which processes represent genuine competitive advantages versus inefficiencies masquerading as trade secrets.

The "secret sauce" of great contractors lies in the numbers they create and the people who generate them, not in how they view documents or look at data.

• One Size Never Fits All—But Configuration Beats Customization – Ralph delivers a pointed critique of off-the-shelf software by noting that "one size fits all" is a myth—he can't remember the last time two projects handled change orders the same way, let alone entire companies.

However, as the debate progresses and positions shift, the discussion reveals a more nuanced truth: while you can't use software in exactly the same way as competitors, you also can't afford to build and maintain everything custom.

The solution lies in configuration capabilities that allow you to make "little tweaks" to match your terminology and workflows without fundamentally rebuilding the system.

Cari shares that most clients start wanting to change software "day one" even when buying off-the-shelf, which is why selecting platforms with robust configuration options provides the best of both worlds.

• The Development Bottleneck and Hidden Costs of DIY – AJ raises critical points about the expertise required for building software that organizations often underestimate.

Questions like "Where do you put the action button?" and "What's the difference between return and enter?" illustrate the depth of UI/UX knowledge that professional software developers possess. Every tweak to a homegrown system requires retraining users who wonder "Where'd my button go?" and why it doesn't work like it did last week.

Cari reinforces this with her personal story of helping a client build software using Access databases, which provided initial flexibility but ultimately created a development bottleneck that took 12 years to resolve by migrating to commercial software.

The hidden costs include not just initial development but ongoing maintenance, testing, hardware scaling, training materials, and the opportunity cost of IT resources that could be focused on revenue-generating activities.

• Low-Code Platforms Represent the Future—70% of Software Development – Cari introduces the most forward-looking insight of the debate: according to Gartner, 70% of all software development this year will occur on low-code platforms, signaling that the traditional build versus buy debate is becoming "archaic."

Low-code platforms offer a third path that combines immediate out-of-the-box functionality with the ability to configure and customize through visual interfaces rather than traditional coding.

This approach means organizations can "walk, crawl, run"—starting with standard functionality to solve immediate business problems quickly, then configuring the system as needs evolve, and eventually building custom extensions when truly unique requirements emerge.

The Platform-as-a-Service model mirrors smartphone app ecosystems where you don't wait for Apple to develop every feature; instead, a community of partners continuously creates new capabilities that you can adopt.

• Begin with the End in Mind—and Leverage an Ecosystem of Partners – Ralph concludes with the wisdom that "whether you're leveraging software vendors and partners, or whether you're doing it yourself, if you don't know what the end game looks like, it's just going to be an uphill climb."

This principle of beginning with the end in mind requires understanding your business processes, desired outcomes, and long-term vision before making technology decisions.

Critically, Cari emphasizes the value of partner ecosystems over single-vendor lock-in—her clients benefit from having two or three Kahua partners on average per project, each bringing specialized expertise without requiring decade-long commitments to a single implementer.

This approach distributes risk, increases flexibility, and ensures organizations aren't held hostage by any single relationship. Additionally, leveraging vendor ecosystems means benefiting from security compliance, FedRAMP certification, and other "heavy lifting" that has already been done rather than bearing that burden in-house.

Transcript

Cari Stieglitz (00:07):
So what we're going to try to do today, and I encourage you guys, if you hear something you like, if you agree with a point, we're asking for a little rowdy participation. You can clap, you can cheer, do a little woo-hoo. Whatever you want to do to agree.

If you don't hear something you like, I don't know, is booing okay?

Ralph Barsi (00:27):
Sure.

Cari Stieglitz (00:28):
All right. All right. You can boo, can be thumbs down. All that fun stuff.

So today we are doing the best debate of the year. I'll let you guys decide and maybe by the end of the debate you'll switch sides. Maybe you'll say, "Maybe I should have built it from scratch." Or maybe you'll say, "Oh no, definitely build is the right way to go."

So we have two debaters here today. Let's start out with AJ. AJ is representing our buy side. AJ has a long experience in the industry, not as long as Ralph still maybe. Yeah. How many decades you got too? Okay.

So AJ is a veteran in construction space. He's also led a lot of teams to actually help selecting software, choosing software, helping to roll it out. And then eventually he came over to the dark side of consulting and decided to work with Kahua where he serves as someone who helps people to understand what they would like to do with their software.

Ralph, two decades in the industry, no stranger—built and helped grow multiple SaaS solutions. And SaaS solutions, if you guys haven't heard of that, software as a solution. So sometimes we see a little flexibility with there on what you can build using a platform or low code.

So we have both sides represented well today and I'll go ahead and kick it off with AJ if you want to begin with your side.

AJ Waters (01:55):
Alright, thank you Cari and good morning everyone. As mentioned, my name's AJ Waters, Chief Evangelist at Kahua. My background for the last 10 years now, I've worked with different companies to make this decision: Should I buy or should I build?

Obviously I was representing the buy side for those 10 years because prior to that I worked for a company called Kiewit. Some of you might be familiar with them. After building it from scratch twice, we finally made the decision to buy.

I went through that process a couple of different times and that's what led me to some of these points today. So first and foremost, the reason you buy software off the shelf is out of the box. Software is ready on day one. It's lower cost, it's quicker to implement and it's very easy to use.

And speaking of easy to use, they build in the best practices.

AJ Waters (02:52):
So the point of the software as a service is they went out and they did all the research themselves. You don't have to do that research to find what the best practices are, build it into the system and make it intuitive so that the user kind of knows how they're going to click through, make their next move and where this process is supposed to go.

With that though, they also do this little thing called training. I don't know if you are familiar with training, but when you build the software yourself, that means you build the training yourself too. And that was a nightmare the first time we had to build software from nothing at Kiewit.

That was actually my main role—was to lead the training team that rolled all that stuff out. And it's a lot more work than people give it credit for. But the last thing I'll say before letting Ralph try to rot your brains is that when it's off the shelf commercial software, it's already built with maintenance, with testing and with scalability.

A lot of times the homegrown solution, again, you are the tester. Good luck with that. You are the maintenance team. Every bug that comes in, they're calling you. And last but not least, as your company grows, so does the hardware that supports your software.

So those reasons right there are exactly why you need to buy off the shelf.

Cari Stieglitz (04:22):
All right, good points. Anybody? No boo. All right, so very good points, AJ. Ralph, the floor is yours.

Ralph Barsi (04:32):
Thank you Cari and thank you AJ for setting me up so well this morning everybody. My name's Ralph Barsi. I'm a huge fan of building it in-house.

My friend AJ over here—very handsome guy, very nice guy. Looks good. He's got a full head of hair. I don't. He's wrong. Everything he's saying is wrong.

In fact, everybody in their respective organizations wants to do three of many things. One is they're aiming for cost efficiency. The second is they want to streamline their processes and the third is they want to have a competitive edge.

Now I've been speaking to colleagues for many years and a lot of colleagues who have bought software have told me, "Hey look, we were sold a bill of goods a couple years ago and the off-the-shelf solution apparently was the way to go. But we came to the realization that no matter how out of the box or off the shelf a software offering is, they do not know our business."

Ralph Barsi (05:40):
We know our business better than anybody else. So I have a couple notes here just from my experience of building in-house that I think AJ over here really needs to hear. Alright, so in many cases, this system of industry best practices that we all hear about always ignores some of the industry fundamental construction 101 terms.

Things like change orders, back charges, production factors were foreign to a solution built by technologists—people who are focused on software versus our business. And in order to find something that would keep our competitive edge, we found out really quickly that we had to do it ourselves.

I mean, let's face it, you're never going to have all the requirements outlined for a technology purchase the very first time. Building your own software makes it easy to make changes whenever you want. So for example, if you missed a step in a particular process, just add it in.

If you decided you wanted to automate an additional workflow without a significant upcharge from a vendor, go ahead and build it out. Decided you spent over two years building out a solution, which is right about what it takes to implement software a lot these days.

Ralph Barsi (06:40):
You heard what AJ said about training. Once you implement a software application, it takes months if not years to train all the users on that software application, especially at scale. So you see there are some very specific ways that we do things and that the way we've done things and they've always been done that way.

AJ Waters (07:20):
Always done that way. That's right. Most dangerous phrase in business, according to my friend at—

Ralph Barsi (07:26):
Hey look, let me finish. All right? We're talking about an incredibly successful, incredibly profitable contractor. Obviously doing things our way was a driving factor to our success.

I mean, buying a software that was off the shelf and used by all of our competitors wasn't going to protect our edge. No, that was going to bring us backwards in terms of processes. We had our standard operating procedures and that's what we were going to build.

Couple that with a plethora of resources and you have a win-win for continued profitability and success.

AJ Waters (08:03):
Listen here, Mr. Bezos, not everybody has unlimited dollars and resources to go to the moon whenever they want.

Cari Stieglitz (08:11):
Alright, Ralph, you started out by saying that AJ was completely wrong.

Ralph Barsi (08:16):
That's right.

Cari Stieglitz (08:17):
Do you want to talk about that a little bit more?

Ralph Barsi (08:19):
Well, sure. I mean, construction gets a bad rap. There's an old meme that I know of that has a dinghy called "original contract," right? And it's tied to a yacht called "change order."

Software companies make us look like novices in extending implementations. And when was the last time one size actually fit all anyway? Out of the box processes inherently assume everyone works exactly the same way. I can't remember the last time two projects handled a change order the same way, let alone entire companies.

Maybe that's where the meme, right? Because it definitely doesn't come from asking a software vendor for a new feature. The second we run into something, AJ, that isn't quite as intuitive as they say or doesn't quite complete a process, we have to load our request into a feature queue and we wait and we wait. And then we hear that it's not really a priority for other customers.

I might as well go stand in line at the DMV.

Cari Stieglitz (09:21):
Alright. Okay. Okay. Ralph, I think you've had your turn. AJ, would you like to rebut that?

AJ Waters (09:29):
Yeah, I would. Now that Ralph has spoke half our time. It's interesting because one software implementation experience is what he's going off of. That's where he builds his "while this was horrible" experience.

But what he's not taking into account is when you build the software yourself, tell me how many UI/UX classes have you taken? Where do you put the action button? What's the difference between return and enter?

Ralph Barsi (10:07):
Okay, well, there's exactly my point. What is the difference between enter and return?

AJ Waters (10:12):
Well, you should know this because you're older than me, but the return key was because it was a keyboard on a typewriter and it returned you to the other side. Once it became more of an action button on a computer, they changed the name to enter.

See, these are the things that building it yourself doesn't quite understand because software people know things. And this continued tweaking and just adjusting a feature—if you will remember the training part—every time you tweak, you mess up some person on the other end that went, "Wait, where'd my button go? Why didn't it do what it did last week?"

Every little tweak matters. And this is my favorite one, my favorite one's the trade secrets one, because there are secret sauces that make contractors great, but it's not in how they view documents. It's not in how they look at numbers, it's in the people and the actions and the leadership.

The secret sauce is in the numbers they've created, not how they look at 'em. So while all of these little things that you might want to tweak could be configured in some softwares, building it yourself and trying to keep doing that over and over and over is going to get you into trouble.

Ralph Barsi (11:38):
Look, there's nothing standard about how we do business. All right? I mean, sure, it would be great to be able to share resources across projects with processes and procedures that were repeatable, but we'd need a solution that streamlined these processes to support an initiative like that.

Of course, standards like this could decrease time to ROI and increase efficiency, but would it be worth the trade-off?

AJ Waters (12:06):
It's worth the trade-off if you can connect the missing links, if you can do a little bit of those configurations and get to the point where the system is at least for you. Yeah, not all systems are for everyone, but enough little tweaks, it'll be right.

Ralph Barsi (12:22):
Sure. But to do that, you'd have to be constantly tweaking and updating your user training and guidelines. I mean, there would need to be certain core aspects of the system that didn't change, like a common user experience and an intuitive interface.

The more you look to build or change, the more important it is to keep things familiar to the end user. I mean, there's no room for clunky screens that are hard to navigate or siloed systems that look nothing like the other.

Cari Stieglitz (12:49):
Wait, wait, wait, wait. Are you still talking about building here?

AJ Waters (12:52):
Well, but I mean, let's step back. It's got to be familiar to you as a company. You need it to be familiar because when it's familiar, it's quicker learning. So if you can make those little tweaks, you can get to a point where you learn it faster. Right?

Cari Stieglitz (13:06):
Okay. And weren't you supposed to be representing the buy side right now?

Ralph Barsi (13:09):
Yeah, AJ, as you can clearly see the correct solution to the problem of digital transformation in construction is to buy a system that is off the shelf and built around industry best practices.

AJ Waters (13:22):
No, I think you're wrong on that point. I really think if you're going to be nimble and you're going to move quickly, you have to build it yourself. You got to be able to make the adjustments on the fly.

Cari Stieglitz (13:33):
You guys, you cannot just switch sides in a debate. I am just saying, you can't just flip like that.

Ralph Barsi (13:39):
Come on. It happens all the time. Help us out, Cari.

Cari Stieglitz (13:43):
All right. Well, I actually want to share a little bit about my experience. First off, can we hear it for build versus buy? Yeah!

Ralph Barsi (13:53):
You're too kind.

Cari Stieglitz (13:56):
What I would like to touch on, and for the raise of hands of folks that have actually been through this, my question is: How much should business process come into play when you were gathering requirements? A lot? Little? A lot, right?

So what we do is we work with a lot of different softwares. Kahua is one of the first that we, I'd say, why can't we have both? There's a lot of softwares out in the marketplace that are really quick. You can have 'em day one, but then what happens is day one, you already want to change it.

And I don't know if you guys have had this experience, but I was looking for an app on how to manage my to-do list. And we all have smartphones. Most of us have smartphones now. And haven't you ever wondered why can't my software implementations just work?

Cari Stieglitz (14:44):
Like the apps on my phone, I download it and then it works. I went through this experience where I downloaded right off the shelf, didn't quite work the way I wanted it to, downloaded another one, didn't work quite the way I wanted it to. And then I downloaded a third and I was like, "I should just go into app development and build it."

And I don't know if you guys have had that experience when you bought things off the shelf, but almost day one you want to say, "But that's not what we call it. We want to tweak it slightly."

And so understanding how you all do business and how you'd like to do business and do it in a similar fashion for me tends to be the biggest debatable. So once you do that, then you could figure out build versus buy. But why not get a software that does both? Right?

AJ Waters (15:32):
Exactly.

Cari Stieglitz (15:33):
And I'm curious for the people that built off the shelf—raise the hands—day one, did it work the way you wanted it to? All right. So did you guys end up tweaking it anyway a little bit or depending on the software you bought, maybe you tweaked, maybe you didn't.

I'm a little adjustment there. So what we like to talk about when we talk about software is the walk, crawl, run. And first off, there's a lot of conversations around out of the box, configuration, customization, building it from scratch. And we've heard a lot of really great points on both sides today.

What I would say is it doesn't matter which one. Okay, you guys close your ears for a second. We work with a lot of different softwares. They say, "What is the best project management system?" And I say, "The one that you can start using tomorrow."

Cari Stieglitz (16:24):
So being able to use that off the shelf is really important because a lot of times when you're going to pick a software, you're solving a business problem. The quicker we solve that business problem, the quicker we can get to getting better dashboards, getting better information, having better controls around our projects.

But when you are ready, you start using it and you say, "Hey, there's some things we want to tweak." Now the configuration comes into play. I heard an astounding statistic. Gartner said 70% of all software this year will start to be developed on low code.

So as an industry, we're shifting this whole build versus buy. It's archaic. We're all going to be shifting to low code where we can have the best of all these worlds. And that's what I think. And now you can open your ears.

One of the things that I've loved as—and I am a partner of Kahua—about four years ago, we went back into the marketplace and we said, "What does the PMIS marketplace look like right now?"

Cari Stieglitz (17:29):
We implement, we help clients and we want to make sure we're investing in the right software. And so what I loved about this, I used to have this conversation where I would say, "Okay, but how much do you want it to match your business process versus a quick stand-up?"

And we would kind of do this back and forth scale of, "Oh, well, if you want really a quick stand-up, I would recommend this software. If you want a lot of customization, I would recommend that software."

And then the aha moment for us—that we were implementing for a transit agency that's tunneling under San Francisco Financial District, and they knew their business process and we had them standing up within 60 days. However, they changed their delivery model. They're now exploring P3, and we are actually able to go back in and help them change that to match their new delivery model.

So having the right software is important when you have flexibility and you need that flexibility.

Cari Stieglitz (18:29):
The development bottleneck—I just want to talk about that because I want to share a little story. I also did help a customer build software from scratch using—anybody remember Access databases? Yes. That was our big powerful tool for non-developers back in the day, the folks of us that didn't develop software, but we still wanted flexibility.

So I went through some of that pain of the DIY, which is you are building from scratch. The cost efficiency of actually, yes, you get exactly what you want, but then when you have to upgrade, you have to do all these other things.

And I actually helped that same client 12 years later moved to an off-the-shelf software. So it's that thing of knowing who you are as an organization, what you want to do, what your processes are, and then picking something that can be flexible.

Also, because I am a partner, I'll talk about the ecosystem of partners.

Cari Stieglitz (19:26):
One of the things that I really like about working with Kahua for my clients is that they don't have to depend on me. Kahua has a lot of partners that are out there that can do different things, specialize in different things, and that's a good thing.

We don't want to have to have a software that you have to have a contract with a certain implementer for 10 years in order to make it work for you. There's a lot of different folks that you can reach out with. Most of the projects, we have two or three Kahua partners on average.

AJ Waters (19:54):
And for people who aren't familiar with Platform as a Service, I like to liken it to your phone. You don't have to wait for Apple to develop the next app. They're constantly being developed by that ecosystem of partners.

Cari Stieglitz (20:08):
Yep. And then of course, you can always go direct, right? You can always go direct to—Kahua has that capability as well. You want to talk about security, Ralph?

Ralph Barsi (20:21):
It's critical, as we all know. So one thing that you get the benefit of when you're not building it yourself and you are leveraging software vendors and the ecosystem of partners that Cari and AJ were just talking about is you get the reliability, you get the compliance that's necessary with the highest standards.

For example, if you're part of a FedRAMP environment, all that heavy lifting and upfront work has been done by that software vendor and by that ecosystem of partners so that you have that peace of mind now going into a relationship and into a new approach, knowing that everything is locked down, for lack of a better term.

But if security is not a priority of yours, of course, I can't encourage you enough to be thinking about it a lot more. And I do know that we have a panel this afternoon. I think it's around two or two thirty specifically centered on cybersecurity that I'd encourage you to take a listen to. But yeah, critical and I can't emphasize that enough.

Cari Stieglitz (21:29):
Alright, so I'm just curious, did we switch anybody? Is anybody really into build now? The one person, sorry. Anybody into buy? Who wants the blend? Who wants it all? Nobody. Okay, just kidding.

Ralph Barsi (21:50):
Well, I think if I may, a key point was made in the panel just previous to ours, and it's the concept of beginning with the end in mind. Whether you're leveraging software vendors and partners, or whether you're doing it yourself, if you don't know what the end game looks like, it's just going to be an uphill climb. It's going to be a tumultuous process for everybody.

So leverage the resources that exist that have done this before and have run into similar scenarios in terms of the challenges that you're facing today. And help let those resources help you in terms of prepping the page, knowing how many phases this project might have, what the key milestones are going to be, when it's going to come to completion, et cetera. And let others do the heavy lifting. Help us help you by beginning with the end in mind.

AJ Waters (22:40):
And to double down on what the panel before us said, it is a people business first. And at the end of the day, the people pushing the buttons are the ones that are going to be dealing with what you select more than anyone else.

And so often we've seen selections be made off of the pretty dashboards or the pretty reports that get generated because—

Cari Stieglitz (23:02):
That's—well, we want those too, right?

AJ Waters (23:03):
Well, yeah, you want those too because that's what the executives are looking at. But knowing how hard it was to make that is critical because we would walk in—we used to walk into demos and we'd sit down with someone and we'd show them the exact dashboard that they wanted and they were like, "That's cool. I already get that dashboard."

And that's where we turn to one of their button pushers in the room and go, "How long did you tell us it takes to make that dashboard?" And that person would go, "Well, it takes me anywhere from eight to 10 hours, depending on how much data I have to track down to populate the spreadsheets that create that dashboard."

And we turn back and say, "It's live as they push the buttons in our system." That's the difference when you get to some of those. So it is a people business first, and at the end of the day, the folks pushing the buttons are vitally important. That's why the business process step is a part of the debate upfront.

Cari Stieglitz (24:05):
But to be continued, maybe next year, that'll be the next great debate. Okay, so round of applause. Was this the best debate you heard this year or the best debate that you heard this year? Just curious. Right. And without further ado, one minute early. Here we go.

Ralph Barsi (24:23):
So we'll—you've all been generous with your time. Thanks for listening to us.