Rumors of the SaaS demise are greatly exaggerated

Nivia Henry says technology was almost a family inheritance: her mother programmed at IBM, her father was an engineer, and they met at work. She studied computer information systems to gain practical, hands-on skills and graduated in 2001, just as the dot-com crash made finding a job extremely difficult. She says persistence and “grit” carried her through. Before the conversation, she spent eight years at Spotify and two and a half years at Netflix, working on products and experiences used by many listeners.

Ryan asks whether companies are replacing SaaS vendors with internally built, AI-generated tools. Nivia says the question is real because build-versus-buy decisions once generally favored buying specialized SaaS, while engineers now say they can build a replacement in two weeks rather than accept a six-figure contract. She warns that the initial build is only the beginning: someone must maintain it, handle upgrades and bugs, provide on-call support, productionize it, and add features. She jokes that everyone keeps trying to rebuild Jira and eventually falls back to Excel.

Ryan introduces open source as the middle option between building and buying. Nivia values its low cost and the community that contributes fixes and improvements, but says enterprise users still face hosting, security, data, and operational limitations. She is seeing less support for open source, while maintainers report AI-generated “slop,” burnout, and abandoned projects. She worries that when open-source communities disappear, people lose an important way to learn; she recalls downloading Java code from Stack Overflow early in her career and says relying only on AI creates an increasingly tight echo chamber.

Nivia evaluates licensing, ownership, and growth costs before choosing to build, buy, or borrow. In one organization becoming AI-native, giving every engineer a cloud-coding budget would create high acquisition costs and duplicated effort, while a third-party workflow platform could provide reusable skills across systems. Yet external tools may access production data, creating security, privacy, compliance, consent, and maintenance burdens. For sensitive, high-PII environments, she concludes that building internally can be safer and cheaper than accepting an annual license. Internal tools still carry infrastructure, observability, storage, and variable token costs.

Nivia agrees that SaaS products built around easily automated tasks are especially vulnerable, while infrastructure remains difficult to replicate and therefore provides a stronger moat. She identifies data—particularly privacy and compliance-sensitive data—and cost management as the most durable advantages. SaaS vendors also cannot assume they have permanently outsourced risk, because breaches are more common and providers are limiting their own liability. She argues that products such as Spotify can defend themselves by turning accumulated data into unique analytics: Spotify gave artists information about listeners, demographics, locations, and listening trends unavailable elsewhere.

Nivia says microservices may not have delivered on their promise: companies adopted them for loose coupling, partitioning, and organizational boundaries, but the resulting orchestration overhead became its own problem. Unless a company has the size and complexity to justify them, she recommends starting with a monolith and extracting only the hottest or most necessary services. She tells engineers to understand the business lifecycle upstream of engineering, because AI-generated work may arrive as “a bag of trash.” Better judgment, she argues, means systems thinking: understanding how tools fragment data, insights, security, and accountability.