Build vs. Buy vs. Open Source

About this Episode

In this episode of the Acima Development Podcast, host Mike kicks things off with a personal story about his wife’s jewelry-making hobby to introduce the episode’s main theme: the classic “build vs. buy vs. open source” dilemma in software development. Using analogies like 3D printing and sourcing beads, Mike illustrates how creators often rely on third-party resources rather than building from scratch. The conversation, joined by guests Justin, Kyle, and Will, highlights how this decision-making process mirrors software strategy—balancing time, cost, scale, and business priorities when choosing whether to build proprietary solutions, buy from vendors, or leverage open source tools.

As the discussion unfolds, the group explores real-world applications of these choices, especially at scale. Will draws from his experience in academia and enterprise to explain how even cutting-edge innovations are often built atop existing open-source frameworks. Justin stresses the importance of aligning technical investments with what drives a company’s revenue, while Kyle adds that factors like security and infrastructure complexity often make buying solutions the safer choice. The team discusses examples like login systems and reporting platforms, agreeing that while DIY solutions might work early on, scale and security typically justify outsourcing or adopting proven services like Auth0 or Snowflake.

Toward the end, the conversation veers into the implications of AI and large language models (LLMs) on the future of development. They debate how junior engineers might adapt, how architectural decoupling can future-proof integrations, and how the rise of AI could alter productivity expectations. With humor and insight, they emphasize that every decision—whether to build, buy, or adapt—requires thoughtful consideration of timing, scale, and evolving business needs. The episode wraps by reinforcing the idea that good architecture, adaptability, and a keen sense of timing are essential for sustainable tech development.

Transcript:

MIKE:  Hello, and welcome to another episode of the Acima Development Podcast. I am Mike, and I am hosting again today. I apologize: my voice is a little bit raspy. I've had a little bit of probably a virus [chuckles] going through the family. I feel much better today than yesterday, which is good [laughs]. But I may be a little bit raspy.

I've got a small group with me today. We're actually moving offices at Acima, moving to nicer, I guess, you know, a little bit updated offices just a couple of buildings down. So, same complex, it's not much of a move, but [laughs] upscaling a little bit today. So, a lot of people are tied up in that. But I've got with me here Justin and Kyle. And we should have a great, more close personal conversation today than we sometimes do. That'd be great.

I'm going to start by talking a little bit about my wife [chuckles].

JUSTIN: I'm a little curious how you're going to spin this because this is the build or [laughs] buy --

MIKE: That's right [laughs]. So, my wife is an artist. She doesn't paint very much. She makes stuff. She's a maker, and she's made a lot of things. But the thing that she does most, and she's done this for years, she makes jewelry. I cleared this with her beforehand [laughter], you know.

JUSTIN: You’re going to be internet famous, hun.

MIKE: Yeah, exactly [laughs]. I've mentioned her before. She makes stuff. She makes jewelry, not, like, diamonds necessarily. She uses natural stones...diamonds are natural stones. But she generally does more, like, beadwork. She'll do complex subbead things, you know, of patterns of natural stones. There's one she uses a lot called labradorite that is just this beautiful stone. Kyle's nodding, like, I know the one [Chuckles]. It's translucent, but if you look at it in the light, it has this blue shine in it. It's really pretty. But she uses other stones as well. And she'll make these patterns and put, you know, she uses a lot of, like, so it's like a larger stone as the centerpiece. It’s kind of chunkier sort of stuff, really pretty.

And she spends a lot of time, you know, like, hand tying it between the beads [chuckles], and she'll say, “Oh no, I messed something up. Now I got to undo, like, two hours of work [laughter].” And so, she'll have to undo two hours of work to go and retie it and move on. And she spends a lot of time building this stuff. Really cool. And so, you know, each is one of a kind; that's how she does it, which is really cool. You get these one-of-a-kind things that she makes.

But there's some interesting aspects about this. She doesn't make the beads. She doesn't make the stone. I mean, the earth made the stone [laughter], and then you have somebody in the supply chain, you know, somebody whose job it is to go collect the stone from a quarry somewhere and distributes that out to suppliers. Some of the suppliers will buy the stones. They'll take those stones and make them into...and they'll make lots of different things, but some of them will make them into beads of different sizes. So, she'll buy it several steps down from the original source.

She buys the stones. She doesn't make those herself because we don't have the manufacturing equipment, nor would we. I mean [laughs], it would require a lot of upfront costs. Now, if that was your thing, then that would be a very reasonable thing to do. She was actually talking to me the other day like, “You know, I see these people who have their own stone shops, and I'm tempted to [chuckles] start small and go into that.” I don’t know if we'll do that or not [laughs]. But she's thinking about expanding and doing some of that, you know, to actually start getting some of that stuff wholesale. We'll see.

This ties into our topic, by the way. This isn't just an aside. It's very relevant [laughter]. So, we could potentially buy some of that equipment, but it has not been worth it thus far based on the business that she does. She doesn't do this, but I know people who have 3D printers, so who do buy the supplies and start making it themselves. Justin's, like, pointing [laughs] to 3D printing equipment over [laughter] in the corner. We only publish this in audio, but we record it with video. Maybe someday we'll do the recording, you know, post the video, but [laughs] we only post the audio.

So, he's got the 3D printer, and 3D printing is super cool. You can print out all kinds of cool stuff, but, like, the stuff for making the beads out of the stone, you have to buy the equipment. And you can download the designs. They're great. I mean, you can download all kinds of cool open-source stuff on the internet, where people have published the 3D models, and you can print them out yourself. But you've got to buy the stuff.

You've got to buy the resin. You know, you're taking responsibility for everything in the process. Whereas if you're not doing that, you just order from somebody who does it online, and they ship it to you unless you get to a certain scale. Justin, have you reached the scale where it's actually been economical for you?

KYLE: [laughs]

MIKE: Hear the laughter? Hear the laughter, listeners [laughs]? Of course not, but it was cool. So, you did; you got to do it [laughs]. I've got Matt who's been on the podcast quite a bit. He has a 3D printer. I've got a nephew who does it. I don't think it's ever been economical for any of these people, but you do get to do...I know Matt just does a lot of his own 3D designs. I don’t know if you do that, Justin, or not.

JUSTIN: Not as much as I'd like but, I mean, that's the intent, right?

MIKE: Right. The intent. So, it's one of those, someday [laughs]. It's like my big, beefy computer I've got on my desk here for machine learning that I'm not using right now [laughter]. When I get a moment, we'll use. So, we talked about...oh, and Will is joining us. He's been a bit delayed, but Will Archer is joining us, which brings us to our topic for the day. And you're joining us right on time. We're going to talk about, in software, when do you build; when do you buy; when do you use open source?

And we've just talked about very practical, tangible items, but software follows a lot of the same rules, right? And there are times when any one of those three is appropriate. And you think about things in the tangible world, and a lot of the same rules still apply. And I'm going to stop talking for a little bit because I've set the stage, and I'm curious what your thoughts are based on kind of the stage that I have set.

WILL: I feel like I've had a little bit of a unique career in that I've spent a decent amount of time kind of on the edge of technology, like, actually doing brand-new stuff that has never been done. Because I came from academia, where we're, like, hardcore research, like, stuff that isn't commercial, and it's not going to be commercial for a while, and then brand-new technologies where there weren't libraries. It wasn't, you know, necessarily sort of your standard web CRUD systems kind of integration stuff.

And what I have found, personally, is you will almost never be going soup to nuts, brand-new stuff. The most out there, woo-woo stuff that I ever developed was a static analyzer for embedded device drivers. And what we were trying to do is we were trying to prove memory safety, where it was this low-level super tiny code set, and we were trying to use...and what we were doing there was, like, we were using a publicly available open source, another woo-woo research project theorem prover. And so, we were sort of trying to analyze the code, you know, get a formal specification for this embedded network, you know, firmware driving...I'm, like, throwing bits on your, like, you know, like, real, real nitty gritty thing.

But I was only doing this within the ecosystem of this previously available open-source stuff. I did a bunch of, you know, kind of pushing audio processing forward on the iPhone when it came out just, like, real cutting-edge stuff. But even then, I was taking a bunch of existing open-source stuff for Linux like C++ drivers, and files, and processing stuff, porting it over to this thing, making it run there, then adding my tiny, little secret sauce, which was cool. It was cool. I did stuff that pushed hardware forward a little bit.

But even then, I was doing just a little bit, like, just this extra thing. There was this decoder thing. There was the analyzer thing, and none of them worked for this, and I made them work for that. And then, I added on some sauce. As far as I've gone, it's just incremental improvement. And that's in a case that I think, you know, outside of those two gigs, I don't do stuff like that anymore. I'm doing big enterprise line of business stuff, where I'm, you know...I hate to call it an assembler, systems integrator, you know, because I write plenty of custom code, nothing like that. Even as far out onto the ice as I've gotten, that's all it's been, you know what I mean, so...

MIKE: Absolutely. So, standing on the shoulders of giants.

WILL: Well, exactly. Absolutely.

JUSTIN: Personally, I think, you know, the question is, you know, build, buy, or open source? It comes down to what makes your business special? Because you need to determine what is making you money, and you got to maximize that and minimize everything else. And if what is making you money is something unique that you have to write custom software for, yeah, go do that. But if it's something that's not core to your business, buy it or open source it. Push everything else away. Just focus on what makes you money. At the end of the day, if you aren't making money, you know, what are you doing as a business [laughs]? I mean, maybe you got a lot of money pouring in from investors, but long-term, you got to maximize your, you know, the thing that's making you money.

WILL: Okay. So, I'll play devil's advocate here because one of the things, you know, when I was working with Acima, and one of the things that I do, like, right now for my large retailer, is at big enterprise scale, small efficiencies add up. One of the things that like, you know, like, I don't feel like I'm talking too much out of school here, but I spent a lot of time dealing with various, you know, financial infrastructure providers trying to get a couple of basis points on a billion dollars’ worth of credit cards.

JUSTIN: That's making you money.

MIKE: That’s making --

WILL: That's not Acima’s business. It's never been Acima’s business. It is not core business. That's not core business. That's just like, yo, at this scale, if you can get me a couple of basis points, you just paid for your whole team forever. But that isn't why Acima exists. It's nothing to do with Acima’s core intrinsic value proposition, whether I can run cards for, you know, 3.5% or 3.45% has nothing to do with whether the business lives or dies. But if I can get it, you know, 500s of a percent more efficient, that justifies the entire team's salary, [chuckles] forever because it is kind of cross-purpose, you know. It's not going to double the business. That's not going to --

JUSTIN: But like you said, it's going to pay for stuff.

WILL: Sure.

JUSTIN: So, if you can identify something that you can write that is custom that is worth a lot to you or to the company in some way, you focus on that, and that's what makes you unique, probably. And, at the end of the day, though, it's like, do you have to write your own code to optimize for that, or can you buy something that optimizes for that? And so, you're always going to have to do this juggling, this evaluation of is this ultimately going to be worth it and make more money for the company? You know, buying versus building.

And a really good example for this, where I'm currently at, or every place that has a login, to have a good, secure login, that takes a lot of skill. And there are companies that have figured out how to do that at scale and sell it as a third-party provider, you know, Okta, OAuth, you know, Okta, sorry, OAuth.

WILL: Auth0.

JUSTIN: Auth0. And, you know, there's a number of other providers and Omni, for example, or, you know, where I'm currently working, we're not in the business of login. So, obviously, we're going to be, you know, hey, this is very important that we get something that did it right. And so, we will shift the risk and the responsibility to this third party, and we will pay them gobs of money to own that. Because, at the end of the day, that's still going to be more secure and cheaper for us than writing it ourselves.

KYLE: I think you brought up another variable in what you were saying there, too, depending on what it is that you're looking at, different variables play a larger or a lesser role, and in login, security is massive. You can roll out your own login stuff, but it's like, do I want to risk it, or do I just want to go with the golden standard? I'll pay that premium for that golden standard, the tried and true that we know works.

And I think we run into that with a lot of SaaS products, where there might be a really good, even open-source product out there, but it may not have the name. It may not have the GitHub stars or whatever you're using to qualify it. You know, you're not willing to risk your business. Even though it's a massive cost difference, you're not willing to risk your business in going for that open-source solution versus the paid-for solution.

MIKE: Well, you're not just paying for the software. Going back to what we talked about with the 3D printer [chuckles], software is free with open source, but that is not the only cost. You now have to own everything about this, make sure that every configuration is right, because if you get it wrong, then your business gets compromised [laughs]. And now you're paying for the security experts. Now you're paying for, you know, the liability that one of them has done something wrong. And you start adding up those costs, and it's not actually free [chuckles]. It's not actually anywhere near free, and the cost is likely higher than just paying for it.

KYLE: Well, and, to your point, how many of these larger companies have we seen spawn where none of their software really is proprietary? They're just using open-source software, and they're selling it to you as a service. There are so many companies out there right now that, you know, they'll use the ELK stack. And they're using, assumably, some of the more open-source type portions of that. Maybe it's licensed to some extent. But I'm saying you are just paying for the support. You are paying for them to manage your infrastructure for you and to have that reliability.

WILL: Got it [inaudible 17:19] not like us. We would never just put together a bunch of open-source software and sell it to people [laughter].

KYLE: No, never.

MIKE: Or [laughs], as you say, shoulders of giants. Does anybody build an operating system from scratch if you're not in the operating system business? No. And even the people who are in the operating business, a system business, if you're Red Hat, you didn't build it. I mean, you built some of it [laughs].

KYLE: You've contributed to the community.

MIKE: You contributed to the community. And even Windows is moving a little bit in that direction. It’s not a great model [laughs] to have to build the infrastructure. You know, everybody lives on top of that. And the infrastructure works really well when it's shared. And you look at all the cloud platforms. Yes, AWS, you could replicate a lot of what they do pretty easily, but you don't [laughs].

KYLE: No.

MIKE: Or, you know, I mentioned one cloud provider. There are others, of course, that are also very competitive in there, you know, Google Cloud Platform or Azure. They provide that.

WILL: Well, but AWS and Oracle, let's say, you know, some other ones, they do provide a counter narrative here in that, I mean, Oracle is maybe the furthest along the curve where their opacity has...like, when I run into some ops team who's just like, “Yeah, we're deep in Oracle,” I'm like, “Oh man, I'm so sorry.” Because Oracle runs...everybody I've ever talked to says that Oracle runs a real type database. They run good database.

MIKE: 100%.

WILL: Their stuff is as good as you'll find. But I don't know a lot of new people, a lot of new builds that are getting on them because they really charge you for it. And so, what you are running into...oh, maybe Kyle could speak to this better than I can. But I know a lot of people who have been pushing back on AWS pricing because you get real locked in real deep to AWS. I don't know, I have personally, in my own personal little micro projects, looked real hard at some of the other providers, you know, other than AWS for some of the stuff. There is a lot of people who are taking it back to the colo, the independently run colo just because AWS has been tightening in the screws bit by bit by bit. And that is the counter-narrative.

You get locked into a system, and there's some very smart MBAs. And if they don't have very smart MBAs, some hedge fund will buy them and install a team of very smart MBAs to [laughter] slowly bleed you dry, you know.

JUSTIN: I think we've talked a couple of kind of extreme examples, but I do want to look at one that may be a little harder to evaluate, and we all know what Snowflake does.

WILL: I don't know what Snowflake does.

KYLE: Well. [laughter] Yeah, we should probably touch on it for our listeners.

JUSTIN: I think Mike could say what Snowflake does.

WILL: [laughs]

MIKE: They provide data warehouse services, so backend, not real-time reporting data, real-time transactional databases, but business intelligence reporting, you know, all of the post-transactional database stuff and the whole ecosystem for making that tie in together.

JUSTIN: Yeah. And so, that data, Snowflake itself didn't generate that data. That data lives in our data stores, you know, in our databases. And, theoretically, business could come to the engineers and say, “Hey, I need this report.” And the engineers could go in and generate the report for them, right? And so, there's nothing that Snowflake is doing that is absolutely necessary for the business to run necessarily, you know. But it does [chuckles]...it does make the engineer's lives a little better since they don't have to interact as much with the business folks. It gives them tools to dissect that data. So, the question is, do we build a reporting system? Do we buy Snowflake, or do we use some sort of open-source thing? Like, what are the pros and cons there?

MIKE: The answer is don't ever build your own reporting.

[laughter]

KYLE: Please don't.

JUSTIN: Why not? It's our data.

MIKE: I've done it. I've done it before. Have you ever seen what happens when said business person runs a report against your production database that has grown a little bit bigger than it was a year ago [laughter]?

JUSTIN: Why isn't the website responsive [laughter]?

MIKE: That's what happens. Yes. And then, you end up using a data warehouse service like AWS Redshift. And [chuckles] next thing you know, you're rebuilding something like Snowflake. Now, you don't have to go to Snowflake. You don't have to go that far. But building reporting yourself, I mean, if you've been living under a rock for the last 20 years, data has become important [laughter], and it drives a lot of business and is actually, you know, what's driven all of this AI revolution that we've had over the last few years. It's the reason we have smart devices. You can talk to them, assistance, because there's a lot of data around. Data has become this huge, huge thing, and well-run businesses use that to run. They need that data.

And so, reporting has been done before. I don't know how clever you think you are. Just like you're not going to build your operating system from scratch because you're not actually that clever, it takes a team of very smart people years to build that. You're not going to build a better reporting stack for cheaper than what's out there. So, there is my strongly held opinion. If you are building the reporting, except perhaps if you're building some special visual chart that nobody else is doing, your own little special sauce on top of the framework that others have built, then there might be a business there.

But, generally, if you're not in the business of specifically reporting, I think the answer is if somebody asks you to build a report, you say, “Okay, what tool are you going to use for that?” That is the answer [laughs]. The answer is not, “I will build that.” Now, push back if you think I'm wrong, because I could be wrong.

WILL: I don’t know.

KYLE: I’ll tuck onto what Mike said there and say that, when you do that, what I've seen is you have a database that is then dual purpose like that. And as a platform, DevOps, whatever you want to call me, engineer, trying to support that infrastructure for my engineers, it's one of those things where scaling for those different types of workloads is vastly different. And so, when you have that dual-purpose database, how do you scale it? So, if you're not using another solution like this, it's almost impossible.

WILL: Well, no, I suppose I could say, you know, push back because I think all this stuff there are arguments for both. And the biggest argument for doing it yourself...and there’s maybe two. One is there's this super special thing that only I can do, and no one is doing it. It's a niche thing that's just unique to me. And then, what do you do? You take an open-source ecosystem and solution, and you build on your little thing on top of it. That's usually how it gets done. And then, two is you just need a little thing. You just need this one thing. You just need to run this one report. It’s just one. I just need to run, you know, sales for the end of the week, just tally it up, right? And everybody's laughing. It’s like, oh, doing it yourself is a dumb idea.

No, doing Snowflake for some tiny ass thing is the bad idea because it’s only a bad idea when the thing snowballs. And you have a goer, and this thing is working, and, like, you're doing more and more. Instead of every day, it's every night. Instead of every night, it's two times a day, and then things get bad, right?

But no one's counting the times where it was just a thing that you built, and then it didn't get any bigger, or you stopped using it in the first place. It was just something where it's just like, oh, it's a thing. It's like, ah, yeah, it was dumb. Whatever. Like, it is definitely worth investing in something that's a goer, and you're using it a lot, and it's starting to impact the organization. But, like, most of my ideas are bad, you know, I just try it out. Just try it out. You’re like, oh, that was a dumb idea. It's like, yeah, put it with the others [chuckles].

KYLE: Just, like, so maybe as a proof of concept or as a start, it's not a terrible idea, but if it grows at all, you probably want another solution.

WILL: Exactly. And then, the real devil becomes, oh, it's growing. But like, were you watching it? How big did it grow? How long has it been? How many people are running that report and how often? [inaudible 26:46] how that’s going to go [laughs].

JUSTIN: I think this goes back to if you are in a startup, like, a small startup, and you're trying to figure out how to make money, and you're, like, my budget is zero, and, you know, whatever needs to happen, you know, depends on me, and the money that squeezes out of my wallet that, you know, I made doing something else for 10 years. So, if you're in that startup mode, I think it goes back to what you said, you know, you are doing everything by yourself to see, you know, does it make any sense, you know, to run it at least once? Because a report, like you said, you know, I could run an SQL statement and done, and, you know, I can automate that and done then, you know, it grows and so on and so forth.

But it's like, a lot of this time, in startup mode, you are exploring everything because there's some sort of business need and, usually, if you can identify that business need, and it's some small X unit of time to execute it once, you're probably going to do it and try it out just so you understand what's going on. And then, once you’ve ran that proof of concept, then you can decide, oh, this took me, you know, half a day to do, but I could see it growing a lot. Now I can evaluate the open source, or I can evaluate the vendors, because I know what's required. I don't think you know enough to make those other decisions until you've tried it yourself. It's really hard to do that until you've tried it yourself.

MIKE: I should put an asterisk on what I said before, at scale [laughter], at scale, don't build reporting yourself. But I am completely in line with what's been said and figuring out what that line is. Where does this count as scale is the whole reason we're having this conversation; otherwise, it would be so obvious. We wouldn't have it in the first place. Because when you are small, you've got to build it yourself. You've got no other choice.

WILL: Yeah, everybody starts small. You know, everybody starts with nothing. Even in a big company, like, if you don't already have, you know, your Snowflake, your Red Shift, whatever, whatever you're doing...Even in a big company, if you've got a Snowflake contract, no problem. If you've got OAuth contract, no problem. All good.

But the first person to be like, yo, this is out of hand. Like, we've lost our minds. And then, the six-month grind to move all the old junky stuff onto the new, shiny infrastructure that's brutal. But we've all migrated, where it's just like, this can't go on, and it's just like, oh, we have to drain the swamp now. Okay, nuts. Well, that's going to take a while, and that's just the nature of the business.

It's like, was it Chesters + Spence? If you go back, you know, you don't assume perfect knowledge as you go back in time. All of the terrible engineering architectural infrastructure decisions that we've made that are actively ruining our lives on a day-to-day basis were not only reasonable, but the optimal decision at the time, you know?

JUSTIN: I was thinking about this earlier this week, and everything that we write will eventually be tech debt.

MIKE: I've heard it defined a little differently. All code is tech debt. It has a cost, right? It's infrastructure that you now have to maintain. It doesn't matter how awesome it is. It could be the most beautiful thing ever. It's still costing you money. You've got to maintain that thing. Unless it's out there bringing in revenue, it's pure cost [laughs], so it's only hurting you. And there's always...it's never in the middle. It's never purely making you money. There was a cost to building it. There's a cost to maintaining it.

WILL: Yeah. All my commits will die a hero or live long enough to become the villain.

[laughter]

JUSTIN: I'll put that on a t-shirt, Will, and send it to you.

WILL: Right [laughs]? Yeah. All that tickets, man [inaudible 31:07] nothing. Oh, dude, it is terrible when your tenure at a company has extended long enough that you start popping up in the git blames, where it's like, who is responsible for this?

MIKE: And you're the one doing the git blame [chuckles]?

WILL: Yeah. I’m like that fucker. [chuckles] God.

JUSTIN: So, I guess I got a question for this. It's like, given the fact that everything's going to change, I mean, you got your buy, your build, and your open source. I think there comes a time when you are going to be, you know, you're going to be switching in between those, especially, you know, you probably built a lot when the company was small, and now you're moving to buy and build. So, what can you do if you are small, or even if you're big, you know, what can you do to minimize the cost of that switching?

WILL: I remember reading this, and it sounded good, so I never checked their sources. But successful companies spend, I want to say, like, 10% of revenue on research and development. It could be 20, but I think it was 10. It was 10% is R&D money. If you're successful, over the long term, you're spending 10% in research and development. And I think, you know, you should be spending 20% on technical debt. If you're spending less, you’re screwing up. If you're spending more, then, hopefully, that's sort of you're paying off the old credit card bill, and it's going to get down to a slim amount.

But I think that's probably [laughs], like, probably, you know, 10% on research and development, new stuff, 20% on paying off the mortgage that, you know, your company makes its living on. And then, the rest is just sort of operations and line of business stuff. I think that's probably the right mix. Because if you're much under that, you know, I mean this is, like, long-term, broadly over the scope of a year, I think if you're much under that, you're running up your balance.

KYLE: What company gives you 20% for that? Because [laughs] I've never been in one.

MIKE: Acima, historically, said 30% for tech debt.

KYLE: Really? Okay.

MIKE: Yeah. There's been a bit of a tightening of the belt over the last year, but I think that that's going to be...we’re going to go out, like, another couple notches [chuckles] in the coming year, which is I think an important thing because I actually am aligned with Will. I think those numbers are about right.

KYLE: They sound good.

MIKE: You could argue is it 15? Is it 25%? But it's somewhere in that range. It's pretty close to the right amount. If you're not spending about that much time improving your stuff, it's not going to get better. But then, going back to the question, how do you avoid that problem? You know, sometimes you can't see the future, and you shouldn't try. But good software architecture never goes out of style [chuckles]. Decouple your things. Don't make a big, tangled mess. Build discrete components. I don't care if it's in a monolith or it's in separate services.

Make sure that you have separate components that can be separately maintained. There's a clear boundary between them, and [chuckles] they don't know about each other's business. Don't let things grow too big. And then, when you have to replace your component with the thing that you buy, it's not very hard.

JUSTIN: I totally agree, and I think that lends itself to not being a single-shop company. Like, oh, we're a Microsoft shop. Everything we own is Microsoft. Or we're, you know, a Salesforce shop. Everything we have is Salesforce, and it drives our business, and it drives our website, and things like that. So --

KYLE: Or an AWS shop.

JUSTIN: Yeah [laughs]. Or an AWS shop. The funny thing is, I was chatting...like, with all this AI stuff, and I hesitate to bring it in here, but the thing is Google and Microsoft both just released frameworks for having an Uber AI agent that understands all the systems that it's plugged into and --

MIKE: And so did Anthropic, by the way.

JUSTIN: And so did Anthropic, yeah. So, you have this mother chatbot that can do all these things that's owned by a single company. And, obviously, if it's like Microsoft, everything will be tied together in a single chatbot. And it gives my little security heart nightmares to think of that because if you crack that one, you got everything. But the thing is, can you just imagine, if you were a Microsoft shop and you had the Microsoft chatbot, whatever copilot they deem it be, it's going to be so hard to move off Microsoft because everything will be tied together.

KYLE: Yeah. You're at their mercy.

WILL: I think that's their hope. But I actually don't think it's going to go that way. I actually think a consistently well-designed AI-engineered sort of system is going to be predictable in a way that the coupling is going to be very portable from one chatbot to another. Because, yeah, Microsoft they're going to make their lock-in chatbot, but then Google is going to make their unlocking chatbot. And I’ve seen this thing is like the kind of thing that an LLM is going to be very good at porting over and translating from one to the other.

MIKE: I've got a case study at Acima. Not going to go into all the details, but we happen to have integration with an LLM because it's running part of our business. I’m not going to go too much into the details of the business [laughter]. But there's been some really important things we've built that use some of that AI tech, and we built a generic interface that none of our clients, internal clients have any idea which company is powering it behind the scenes.

Nobody is integrating directly with the provider, with, you know, Microsoft, Google, Anthropic. They integrate with our internal client. It makes you have to do a little more work, right? Now you have to build this in between, but because we have that, we could switch providers just like that. We'd have to probably rewrite some queries and do some validation, but none of the clients would have to change a thing. You absolutely can build your infrastructure. You can build with good architecture. If you always put that layer there to decouple, now you are not committed to that one provider, and you can swap it out.

WILL: I would say even if you're running on vibes, if you're running on pure vibes, say, okay, the LLM task is, okay, let's say it's my messaging queue. Okay, I'm an AWS guy, and I want to go out, you know, my...what is it? SNS queue. That's my event queue. And it's like, “Hey, LLM, write me a facade over this thing so that I have a uniform, not AWS-specific interface.” And that task is a task that an LLM, you know, coding buddy can take on and win.

MIKE: That's true.

WILL: Like, sophisticated refactoring? Maybe not for them. Because we're just moving data payloads around. This data goes in this pipe, you know, format the data for this pipe, format the data for that pipe. It's a translation. It's a translation problem scheme, you know, that you're coming through. The LLMs are really great at translating stuff. Really great.

I see the vibe, but I also see the win for, you know, empowering the vibes because you could define this ecosystem. It's not everything under the sun. It's our stuff that we fully understand, and we've exhaustively tested. I kind of like it. I'm kind of into this, you know, for just hammering out web apps? Oof.

MIKE: But that still led to good...I mean, you're doing vibe coding on an LLM, cool idea, but you're still architecting the system at a high level to be, you know...

WILL: Decoupled.

MIKE: What’s that? I thought I heard a word there.

WILL: Decoupled

MIKE: Decoupled. Exactly. Decoupled.

WILL: I mean, no, no, the vibe guy is on the beach with a pina colada. He's paying me to do that. Now you've transcended the vibes. The vibes are not enough. Like, now you need to elevate your game to somebody who actually does something. That's fine. You go prospecting, put your shovel down. If you strike gold, then you call me. Just be like, “I would like to keep this mine operating.” Why go to a [inaudible 40:32]? And I’ll be like, “Yes sir. Right away, sir. Make the check out to cash that.”

MIKE: So, you're saying the same thing we've been saying all along, though. You start small. You are willing to do things differently than when you hit that scale, and you should, and you should.

WILL: I love it, man. I love it. I see clearly the distance, my dream of the golden 30, where I could just get, like, 30 hours a week, just coming in, getting my stuff done, bang, bang, bang, being the overseer to a team of AIs. They're doing stuff, but somebody at some point in the chain needs to know what the hell is going on. That'll be me. God help a junior developer, you know, in the year of our Lord 2025. But I'm not that guy. I love it, man.

JUSTIN: My kids are all going through high school. Well, no. I got two kids in college and two kids in high school. And the high schooler, the youngest one, he is going through math class, and he has LLM helping him out. I mean, he basically really dislikes the teacher because he doesn't learn well from her for whatever reason. But he comes home, pops it in ChatGPT. ChatGPT solves it, and he's like, “Okay, really teach me how to do this.” ChatGPT goes through each step, teaches him half a dozen ways to figure it out. And then, he knows he learned better from ChatGPT than from that teacher. And my other kids have had similar experiences.

So, it's like, I'm kind of optimistic about the junior developer because they could go in, ask ChatGPT, “Explain this code to me, like I'm 5. Explain it like I'm 10. Explain it like I'm 5.” And they gain a deeper understanding of that code than a senior engineer perhaps would have the patience to teach them. So, I don't think it's all bad for the junior developer, other than the fact that the senior developer is suddenly going to be, like, 10 times more productive, and there may not be work for the junior developer. But for them learning, it’s --

WILL: Yeah. Well, I mean, that is effectively it. If I get more productive, then all the low-hanging fruit is gone. And the kinds of problems that I've worked with day to day, and the kinds of problems that I don't really see going away, LLMs are going to struggle because they're going to hurt. They’re going to hurt on the kinds of issues...because it's never just a repo or just a codebase or, like, how does this work together? It's just weird crap, you know? And that is --

JUSTIN: They may struggle now, but we're still early days.

MIKE: We are.

WILL: Yeah. You know, who knows?

MIKE: But, well, we talked about this a few weeks ago, that software engineers have become more productive consistently for at least 60 years, and the industry has only grown. The need for people who can think clearly about problems, and I'm going to say explain those, so be able to understand the problem that needs to get solved and understand the solution at a high level, is not going away. People who think clearly about problems are going to be needed, I think, for the foreseeable future.

Now, the tools that they use have been changing for all of 60-plus years, and I expect will change maybe dramatically with these AI tools. But businesses have never said...I've never heard of a business saying, “I'm making a bunch of money,” and then said, “Stop. Okay, that's enough. That’s enough. I'm making enough money. I don't need to do this anymore.” If we become more productive, so is every other company out there, and that competitive landscape just raises the stakes. And they're going to need smart people to drive the business further, or else they go out of business.

WILL: It's true.

MIKE: How is this any different than it was 10 years ago, or 20 years ago, or 50 years ago? You still have a competitive landscape, and now your competitor is using these tools, then they're way more effective. Well, you better be doing the same thing, and you better be hiring some experts who know how to do that.

WILL: That's true. I think it's true that we may be under...so, the technical sophistication that you need to quote, unquote, “vibe code,” it's like, oh yeah, I'm a senior software engineer, holy shit. Vibe coding is going to get rid of all of our jobs. And I'm like, yeah, but let's get a senior product manager and see whether the vibes are still flowing so freely, you know, not exactly the same level of vibes. I think Mike put it precisely. Our productivity has been going up and up and up and up and up decade by decade by decade by decade.. This is nothing new. And if I double my productivity, you are going to want three times as much output.

[laughter]

KYLE: The one thing that was pointed out to me on this was, you know, when I was coming up through school, it was, “Oh, you can't use your calculator. You have to do all this without a calculator.” And then, you start really thinking about that and how many places you'd never have a job where they say, “You can't use a calculator.” I mean, that's just ridiculous.

And to kind of go with what Will is pointing out there, it depends on your calculator as to how good you are. Some of the stuff that I've seen people do with those old TI-82s, or whatever, like, it was brilliant. I wasn't able to do, you know, some of the things and some of the equations and saving some of that stuff, you know, that they were doing. I was clueless. And I think we're going to run into that same thing with juniors, you know, they're going to be clueless what to really do, even vibe coding. You're going to need a senior. You're going to need somebody, an architect that actually understands what's going on in order to actually be able to efficiently use the tool.

WILL: I actually think...so, this is a little bit of a tangent. I'm going to go old man shakes fist at the sky. But, like, generationally, I think the late ex, early millennial, that we may have actually peaked in terms of technical sophistication because you still had to do it. If you're a teenager, do you know what a C drive is? You know, God help me, do you know what slash vol is? You do not.

You don't know that because you don't know...why would you invest in this arcana? But it matters. If you want to be in the business, that matters to you in ways that you don't understand. My generation we were both exposed to everything hot off the presses, like, every good technical innovation, like, up until this LLM, you know, it's a bunch of Gen Xers. We made you. We made LLM for you, Rugrats. You're welcome. It's our final gift to you, you know?

[laughter]

We got it all right as it was. People my age, like, 45, you know, thereabouts, early to mid-forties, we're not a bunch of COBOL programmers. All that hot stuff that the kids are getting, we made it for you. We made this, not you guys. It's not rock and roll or fashion or whatever. There's no new slang. This is just us.

MIKE: We're on a tangent. I'm going to roll with it and tie it back.

WILL: Yeah, I get it.

MIKE: So, I think there's something you said. Those of us who fit in that category, especially maybe the higher end of that category [laughs] in terms of age, you may also notice that there aren't so many car guys out there anymore. There used to be all these car guys. I'm saying guys. There are women. I'm using this generically. But there was a stereotype --

WILL: They exist. But you counted --

MIKE: They exist. But gender norms of the era [laughs]. There were a lot of these people who were car people, and it seemed like they were all over the place, and they’re becoming a rare breed. Because you don't need to have that expertise to keep your car running, because cars are better than they used to be, and they're becoming more technology-driven. So, you bring it to somebody who's an expert in that. And so, that generation is going. We hit peak car guy, right?

WILL: Oh yeah. Like way back ‘80s, maybe ‘70s, OBD2, baby. Just plug it in. Listen, tell me where it hurts, baby [laughs].

MIKE: So, you know, I think that there's something there. I mean, we've seen that happen at that other technology. We had this other technology where it's not like cars have gone away, but the person who can take care of everything end to end they don't exist much anymore. They don't even really exist. Those people work on classic cars. They don't work on the new cars anymore. And they might even shake their fist to the, you know, the sky around the new cars because the technology has moved on. It doesn’t mean the technology is worse. But yeah, I think that there's something to be said for that, that the end-to-end person is going to probably fall out of existence.

To bring it back to our topic, that build versus buy, you know, our expertise becomes specialized. And you've got to build the thing that actually provides value, and everything else you buy or you're working with another system. You build on that existing system and recognize that's how this works. You can't build everything yourself, and that's okay. In a complex civilization [chuckles], you wouldn't want to build everything yourself because there's a huge loss that you incur by saying you're going to do everything yourself.

WILL: I'm not smelting aluminum, man. I just want my Coke.

MIKE: Exactly [laughs]. Exactly. There are times you're literally part of the world that you should build. You should build your art and buy the rest, or use open source when you're at the appropriate level of scale.

WILL: Yeah. Get some samples. Get you a drum machine, some turntables.

KYLE: I think as we've hit some of these newer technologies, and kind of like you're saying with the car analogy, it's the same thing is happening in software where you can't have one...I guess things are more complex than the generalized do you buy, build, or open source? Because, in the platform world, we go between what's the appropriate option? And you got to look at all these things, too, where, oh, this is a great buy. But then we've got to employ the person that maintains that software for us. And then, you've also got to tack on, like, so that's been around, but the newer portion of this is infrastructure as code.

Well, this might be the top of the industry, but the next one down may look like a better option because, well, this one has infrastructure as code support. And maybe we don't want somebody that, you know, their entire job is to actually click ops this entire solution. We want somebody that's going to go through and automate all of this.

And so, now it's like options that maybe you wouldn't have taken advantage of prior you're taking advantage of because of other variables like infrastructure as code, or something like that. Because now you've got to weigh the costs of the offering, the costs of what it's going to cost to maintain, and then the cost of the code behind it. And those weren't things we worried about before. Like, you didn't worry about putting infrastructure as code there. That's, what, 10, 15 years new?

WILL: Yeah. They all want more. I mean, like, the past, you know, all the infrastructure, all of our technical infrastructure advancement, I think it's maybe thirds between better user experience, developer productivity, and increased performance, and stuff like that. But I'll be the first to tell you that, in my opinion, the past 20 years of Moore's law speed ups have all been consumed by shitty JavaScript.

[laughter]

KYLE: That's so bad, but it's true.

MIKE: You know, what's being consumed with now is kids asking ChatGPT to generate cat images.

WILL: God bless them. They're generating all kinds of images, all kinds.

MIKE: All kinds. That is true. And we're going to keep going, not on that topic [laughter].

WILL: Nope. Nope. You know, yeah, whatever comes out of the other end of your little creative writing essay about what you're imagining between you and God and OpenAI presumably.

MIKE: [laughs] I think we're coming to a good closing point here.

WILL: [laughs] I think we’ve shot way past a good closing point.

MIKE: Yeah [laughs]. We did. We went on this tangent where we started talking about the details of specific tech, but it comes down to these same trade-offs. It comes down to these same trade-offs. Hopefully, we've given you some things to think about [chuckles] as you're making these trade-offs. Where are you at? Where are you at in this cycle of your business? What trade-offs should you make, and what can you do? And Justin's question was well placed. What can you do to be prepared for the trade-offs you will inevitably need to be making in the future?

WILL: Absolutely. I think, in the end, I have to call it, like, an evolutionary process in that, whatever you're building, the initial step, I think if you're doing it right, if you're doing it the smart way, is whatever is the least resource impactful. If you are broke, if your budget is zero, you're going to slap something half-ass together, you know, that works and call it a day. If you've got a big enterprise, then get a hundred bucks a month subscription to something. Your boss will sign off on it. It's going to be fine.

And then, you take it as far as it'll go, and, at some point, the real art is going to be seeing that inflection point where you need to take a fork in the road. And either what you're doing is, in the gross majority of cases, something, you know, not essential to the business. Just buy something to take it off your plate. Or, you know, occasionally, you'll find something where it's like, this is a competitive advantage, and this is special sauce that only I could produce. Then you'll get there. And the art is identifying that fork in the road and not just getting pulled along, you know, whatever path you initially chose through inertia. That's really the art of it, in my view.

MIKE: That's perfect, I think where we'll leave things, and we'll see you next time on the Acima Development Podcast.