SaaS終焉説は誇張されている：AI時代の「作るか買うか」の判断

Hello, and welcome to the Stack Overflow podcast, a place to talk all things software and technology. I'm your host, Ryan Donovan, and today we are talking about whether the SaaS apocalypse is real or rumors of SaaS's demise are greatly exaggerated. And my guest for that is Nivea Henry, who is an engineering leader most recently at Netflix. And we are here at the floor of the LDX conference by LeadDev. So welcome to the show, Nivia. Thank you, Ryan. Thanks for having me. I think before we get into the topic, we'd like to get to know our guests. Can you give us a little flyover of how you got into software and technology? My parents were technologists. My mom was a programmer for IBM, and my dad was an engineer, and that's where they met. And so I feel like, in a way, it was always destined to be. Watching them growing up, I knew that this was for me, how life-changing it could be. And so I wanted to go into software engineering and I did for college.

But then as soon as I graduated and I graduated with a computer information systems degree, because my thinking was I wanted to get more of the practical skills and really get more hands on experience. I graduated in 2001. So can you guess what was 2001? It was the dot bomb that made getting work very, very hard, but I persisted, just had grit and pushed through. And eventually I am where I am now, where I'm looking at two and a half years at Netflix and before that, eight years at Spotify, building some of the most incredible products and experiences that many listeners probably have interacted with. Sure. People at engineering companies are starting to think about replacing vendors with internally vibe-coded products. Do you feel like this is a reasonable approach? Is this a real thing that's happening? The question is certainly real. In other words, we used to have a lot of build or buy decisions. And a lot of the build or buy decisions were an expectation that we would lean towards buying because there were so many readily available SaaS products that fit a particular niche.

More often than not, we're leaning towards buy. I just had a build or buy conversations where the same questions surface, which is, does it make sense to leverage our engineers that way? But then the difference with AI is our engineers were like, yeah, it'll take us two weeks, though. Right. You know, so what am I getting into a six-figure contract if my engineers could do it in a few weeks? Exactly. Now, there's a bug to that, which is, you know, after you build it, who maintains it? Right. You know, who ensures that it's always up to date? Who does upgrades when there are bugs? Who's on call? Who productionizes it? Who adds new features? Do you want to set up a new JIRA board for years? Oh, God. It's so funny. I say that Microsoft Excel will never be out of business because everybody's trying to rebuild JIRA and just default to Excel. But to me, that's a new paradigm and a new question I'm encountering all the time, which has led me to wonder about the much lauded deaths of SaaS. Yeah. I still see viability with SaaS when there is a complex workflow, when there is just not enough bandwidth within the engineering team.

And also when the team is big enough and long-lived enough where there needs to be some kind of operational maintenance. But more often than not, these days, I really am fighting the urge to just build it in-house because we can customize the heck out of it. The old build versus buy question. There was always a sort of midpoint with open source, the borrow. Right. But you still had the hosting issue. So you could sort of get this pretty good software that has updates coming in and you could customize it. Is that still on the table or are people just like, I get two weeks, let's go rebuild. I love that you bought and borrow because so, first of all, part of why, other than the fact that, you know, more often than not, it's free or low cost when you go open source. But it forces you to also the community to care for the product, to contribute to the product. However, the perpetual problem, again, as you know, is like the whole what is the tragedy of the commons often happens. So when I'm thinking about especially software at the enterprise level or software where there's quite a bit of either security or data or like these types of demands that are not easily solvable.

I think that's where borrowing still has limitations. Now, in terms of how has AI changed that paradigm, I don't know if AI changed it, but I am seeing less and less support overall for open source. And I'm curious if you're seeing the same thing, too. Well, I'm seeing a fair amount of open source maintainers sort of complaining about all the slop coming in and then other ones where it's like burnout and abandoning software and some organizations adopting on a security level. Exactly, exactly. And to your point, I worry about the burnout quite a bit because once that happens, slop takes over, then, you know, we've lost the utility of whatever the app or platform or whatever it was that was open source and then everybody suffers. And I also noticed that when folks aren't contributing to open source software or solutions anymore, it's a source of learning for a lot of people. I mean, in early days, I used it.

In addition to Stack Overflow, I used to literally download Java code from Stack Overflow. When these go away, then all we have left to learn is from AI tools. And that is really, really dangerous. That's like an echo chamber that's like ever, ever tightening. It's a collaborative learning. I know, like, Netflix is a big supporter of open source where they were solving new problems, right? So they say, we solved it. We have this chaos engineering thing. Check this out. We've got these microservices things. But we're seeing a lot of open source software being used to build a business, too, because the business end is supporting it, hosting it, doing the security updates, right? At Netflix, what I've witnessed personally, both regarding open source and the evolution of microservices, is that once a business reaches a maturity point, the dynamics change quite a bit. I love being part of companies that are at the tip of you know the learning sphere or they sort of in the vanguard in the front lines And I love it when they give back to the community that way What I would like to see more is those companies without acquiring the technology as we

seen within a few instances, companies that just abandoning that once they've leveraged the community and the community is contributing maintenance, it's contributing fixes. It's like it is actively improving the product. And so when you have a company that then just privatizes that, it kind of feels like, well, my work is co-opted. Or if a company abandons it, then it becomes a leading sponsor that abandons ship and it sort of has a cascading effect. So that's the thing I'd like to see more of in general at Netflix and other companies is really just like, how do we maintain this, especially in the age of AI? Because we are just losing so much of that community knowledge. There's a lot of licensing where even if you fork it, privatize it, still has to be open source, right? Or it has to at least have attribution, right? I think about these companies that are built on open source. It's like the actual product there is the maintenance. It's the support. So for those folks who are looking at AI and being like, oh, get rid of that vendor contract, right?

What is the actual thing they have to take on now? When I am in a room thinking about these questions, even before I'm thinking about where I'm going to acquire, whether I'm going to build, buy or borrow, the questions I have for me is what is the cost of the licensing? What is the cost of ownership? And what is the cost of growth? Like those are the three buckets that I think about. So to your point, I usually chart this down and sort of like have the three areas. Oftentimes, I am optimizing for some kind of speed. And so I am looking outward towards, you know, an open source solution or even a third party because they can build it faster. It used to be true. It used to be true, but they could build it faster. So I am working with an organization that is looking to become AI native. And on that journey, we are looking at the workflow tools that we might use. So one option is, you know, everybody gets a budget for cloud code and individual engineers are then tasked with building out their entire workspace, their IDE, their CLI, whatever it may be.

But that's a very high acquisition cost when you think about it for each engineer. Like a chance to duplicate a lot of work, too. Exactly. Right. The other option, though, is to go with a third party tool that helps us build workflows, repeatable workflows that then sort of become packaged skills that one remains consistent across platforms, across domains, across systems. And so when I go back to that mapping of like, what is the cost of acquiring it? In that situation, the cost of acquiring it is like, okay, it is better to go externally because the individual engineering costs are high. Okay, then what is the cost of ownership? Next question, right? And so the cost for us of ownership is now we have a third-party tool that may or may not have access to our data, our production system. Those are things we also have to factor into that cost of maintenance because now you think about security concerns, you think about privacy, you think about compliance matters. And as soon as you integrate with a third party, you introduce that kind of gap into your system.

And you may also have to update your users to ask them to consent to third parties. And so you would think that the cost of maintenance would come out in favor of a third party tool or, you know, even a borrowed open source tool. But it actually was lower internally because now we don't have to open up these security risks, prompt injections. Like there's a lot to think about there. So we said that the cost of acquisition was low, but the cost of maintenance is actually relatively higher. As we evolve, how adaptable does that tool become? And again, same comparison. And internally, we looked at it. OK, this gives us packaged workflows. But there is a point at which you build out your workflows across your domains. You chain them up. You have agents and subagents deployed and everybody's leveraging those workflows and agents into tasks and executing. But really, at least in this use case, that's not an infinite game. Even when you're building software, you're not building brand new foundational software all the time.

Right. Especially if your company is not necessarily in a hyper growth or a new product development phase. I would say you have to then look at the calculus of how much net new code am I actually generating versus am I really just maintaining or, you know, adding features like moving pixels. And then that becomes, OK, if I'm not generating a lot of net new code again, it means that it's not going to be somewhere where I need a lot of feature adaptability. So, internally. So, surprisingly, the calculus lets out that although it would be cheaper to acquire, it's sort of like ready-made, it's actually more secure, less risky to build internally. And we think that we could build something internally that gives us just what we need without locking us into like an annual license for something that doesn't fit our use cases for that entire year. So, that's just an example. If you're billing internally, you own all the security risk. You own all of the liability, right? This is another thing that has to go through SOC 2 compliance. Fair enough. You have a company that's their bread and butter.

That's their money. They're going to get SOC 2 compliance. They're going to get all of the stuff. And if there's a problem, they're going to pay the bills. It's an and, not a but, because you're absolutely right. What's also true is this. We're seeing a lot of just data breaches in general. And AI has made it much easier in my own observation. So the likelihood of data breaches has significantly increased. The wonderful thing about SaaS companies is, as you said, you can outsource the risk and the liability in many ways, but that's becoming less and less true because those companies are also trying to limit their own risk and liability. So it's a bit of a rat race. So I would say for many use cases, if there isn't necessarily a higher than normal privacy, I'll give you an example, right? At the end of the day, when you enter into an app like Spotify and Netflix, what information are you really providing? It's not going to be PII information necessarily. But if you can think of other situations or other apps where you might be entering very very personal information there are limits to what you can truly outsource and then the inconvenience because you still have to semi audit There still a lot of work to be done It just not worth it at the moment That might change But when you dealing with very sensitive data

high PII environments, high compliance environments, where in my case, it happens to be in the moment, it was just not worth that outsourcing. The other thing I get against building it in-house is the infrastructure costs, because then you're adding cloud compute. You get your S3 buckets growing. You get the inflow outflow. Yes, your token grows. Right, your observability costs. Yes, and a lot of those costs, they used to be somewhat fixed, but they're quite variable now, especially your token costs. So I would, more often than not, it's going to be an advantage to buy and use a SaaS company because they can at least control it through the license. Yeah. Situationally, I would say from an infrastructure standpoint, especially when you think about the providers in that space, you know, Amazon S3, you know, GCP, so many companies where not only is it their bread and butter, but they also do it very well. Yeah. And it is very hard to replicate. You know, when I think about SaaS companies that might be at risk in this new equation, I think about the fact that they haven't necessarily built a unique enough moat that is hard to replicate.

Infrastructure cost specifically, I think, is a hard mode for sure. Yeah. The Stack Overflow Developer Survey, we looked a little bit at whether people were building in-house. And we found when we asked it broadly based, only about 15% were building in-house. It's about 50%. But that was sort of a mirage. It was only about 10% of the developers we asked were actually doing that. So it seems like this is an easy thing to do. but on some level, does your company want to be a to-do list provider? Exactly. You hit the nail on the head. To play back what I'm hearing from you based on this survey is like, at the end of the day, if you are a SaaS where you're providing things that are easily automatable, I think that's a big, big risk to be in these days because everybody could build that quickly and hyper-customize it in a way that you simply cannot compete with. But if you have a real moat, that's where your business is a little bit more protected because nobody internally also wants to be building tools that are not necessarily centered to their own lines of business, especially when it's an expensive endeavor.

Yeah. Talk about the real moat. Yeah. What is the real moat? Like I've heard of some about a year and a half ago, it was data was the moat. Right. And now. Data is still the moat, I would say. To your earlier point, when I'm making build internal decisions, it's usually because there is either, as I mentioned before, a data and a privacy constraint or some kind of compliance PII, which to me still is in the realm of data. So I would say that's still a mode. And I would say cost management is your other mode. You know, is it cheaper, especially with variable costs? Those are the two modes that I can most readily think of. Yeah. For the big engineering organizations, the ones that have Uber, for example, I've talked to three or four companies that spun out of Uber open source. I think I talked to a company that spun out of Netflix open source. These are primarily like microservices glue. Are those ones in danger? Because do you need a durable execution provider when you can sort of build it?

Yeah. Oh, boy. That's where it gets a little spicy. Yeah. they're not at the forefront of risk, but I think it's coming for us all in some ways. Oh, man, that sounds so dire. It does. Oh, boy. It's coming for all your cron jobs, too. It's really coming for all. I mean, the cron jobs were painful to begin with, but, yeah. What I would say is, first of all, I already have a controversial perspective anyway, which is microservices have not served us necessarily in the promise of microservices have not served us. So what I would say is for those companies where that is their moat, they don't have to necessarily prove their build versus buy value because I think at the end of the day, they can still provide the more economical option. The real fight for them, I think, is whether or not microservices make sense nowadays. I think we all jumped on that wagon because, you know, we wanted to have tight constraints. You know, you wanted to have loosely coupled and make sure you had like good partitioning. And it seems like an organizational fix in a lot of ways.

It is because what you're trying to do is replicate your org chart, right? You orient your services towards deep. There it is. Conway's law, right? But the reality is it's a lot of overhead because now you need so much to manage your services, orchestration. It's become its own nightmare. And I think companies are realizing that unless you have the size to warrant that and the complexity to warrant it, Start with a monolith and then like splice out a few of the core services that really need that partitioning and everything else. Isolate your hottest services, your hottest services. What are the things that you think everybody should just provide to code their own? Just have your org do this. Basic project management tools. Sure, there is some benefit if you have thousands of people on, you know, initiatives that you'll get out of, you know, some of the software out there. But for personal project management and for smaller projects, you're going to get much better utility of customizing it.

Because by the time you have to set up and customize JIRA with all of these permutations, these different sub workflows and different types of workflows, you can probably build your own in much less time. So that's an example. So any of that personal productivity tools, gone. Everybody's doing their personal productivity. I talked to somebody here at LDX. He built a workflow that used to take him hours to do. He was able to do it, build it once and use it repeatedly. And that's improved his life. And customized it for his particular workflow. Literally, because a lot doesn't change in those things. So he can pre-fill the text. And all that's changing is the amount, really. And so why do you need to pay a subscription for that? It seems like the software that was built to be highly customizable, it's like, why do I need that software to customize it? Exactly, exactly. It's true. And so there going to be some enterprise clients for sure but for most cases these days it is much easier to just customize and personalize And it take you half the time if not more or less So for an engineer at a midsize company, they're thinking about how to make an impact.

If they can run their feature by themselves, should they be thinking about workflow changes? Like, should they be thinking about maybe I can do this part of the workflow better? They should be completely upending how they work. Absolutely. When I said they were all coming for us, I was half kidding about how dark that sounded. But the thing that's coming for us is that we all have to up level and really rethink. So if you're an engineer at a midsize company, one of the first things you need to understand, critically understand if you don't already, is like, what business am I in? How am I generating, you know, whatever pays my paycheck? And you need to understand those life cycles upstream very clearly. because well before it comes down to engineering, it goes through ideation, it goes through design, it gets greenlit. And the reason why that's important in these days is because, first of all, those things used to be a hard board around them. Now folks think that they can vibe code their way through that. And so it's either not coming to you at all potentially or coming to you in a very janky, sloppy way.

So either way, you have to be cognizant of that and try to help that upstream flow because you're just going to get a bag of trash otherwise. So that's one. And two, you should always be thinking about, at the end of the day, works, businesses, teams, or systems, you have to apply systems thinking. I hear a lot in the talks about, like, we need better judgment in the age of AI. You know, I would refine that a little bit to say, we all need to understand the systems in which we operate. That's really what it means to have better judgment because you'll have better context. Yeah. I see folks applying the engineering not to the code of the product, but to the SCLC itself. They're making these software factories. Now you're looking at build versus buy on the system, right? Does this piece of software serve the system? Yes. And how do you make sure you don't have a ton of third-party software in different areas of the system? Not only is it creating crust and flop, but it's also going back. It is fragmenting your data. It's fragmenting your insights. The thesis for this conversation is about the death of SaaS. In many ways, the AI may have accelerated the death of some SaaS, but I think the first domino was about that fragmentation to begin with, right?

And so as an engineer, as an engineering leader, that fragmentation has real world impact to the product, the developer experience, the ability to chain data across different systems and to manage that data, to instrument, to use it for insights, to build a data spine and data lakes and whatever else is we're building. Right. All bodies of water of data. So to me, going back to build versus buy, no matter what you choose, you have to be able to understand, okay, what else is in the system? How are we making sure that there's consistency, there's accountability, and there's still a place for all that data to end up so that we can leverage those insights. Otherwise, what you're really doing is you're actually trading. You're trading security and risk for your own data. And that's a short-term game, baby. Sure. Then that becomes vendor lock-in. That becomes their moat, right? How do you sit into a system? How do you get data in, put data out, and have a business that they come back for renewals? Yeah, looking at it from the SaaS lens, that must be very, very tough.

I think about Sigma as an example. They lost 70% of either market share or value recently as a result of people playing with this notion. And so if I were to put my shoes in their lens, yes, everybody's doing the slapping on AI, just like rubsome AI. on it, right? Just like we used to rub some Agile on it back in the day and, you know, rub some DevOps on it. I don't think that that's going to serve long term. I think what will serve long term potentially is if you can then, you have the data, what can you offer? Maybe you can offer better analytics. Maybe you can offer better insights. What can you do that I can't do? What can you do with my data that I can't do? Exactly that. I think that's probably the biggest saving grace and potential moat for those companies. It's no longer just enough to say, I have your data, therefore you must stick to the subscription. It's, I have your data and here are some useful things. So I would say Spotify and my tenure there did that very well for artists because artists

were on the platform, but the insights they were able to gain from being on the platform, you can gain nowhere else. So it's no longer just a place to house your music. It's now a place to gain insights about who are your listeners? What are the demographics? Where are they? What are they trending? What are the cycles looking like? That's how you play it smart, in my opinion. You know, for a lot of this question, it is an engineers and developers question. Engineers want to build everything. There's very few companies that do. I think Jane Street is probably one of the few that builds everything. And so it becomes the question of, do you just build everything? Does the C-suite stop you? Does RevOps come in and be like, no? because at some point you do have to justify the expenditures. You have to justify where you're putting your people. I've heard of companies putting like 150 engineers on a product that you could buy. Thank you for listening. I've been Ryan Donovan. I host the podcast, edit the blog here at Stack Overflow.

If you have questions, concerns, comments, topics, cover, you can email me at podcast at stackoverflow.com. And if you want to reach out to me directly, you can find me on LinkedIn. And I am Niv Henry. You can find me on LinkedIn. And if you are a geek, you can also find me on Blue Sky. My handle is at Lanouba, L-A-N-O-O-B-A. Thank you for listening, everyone. And we'll talk to you next time. Thank you.