Vijay Raina is a preeminent specialist in enterprise SaaS technology and software architecture, known for guiding major organizations through the complexities of digital transformation. With a deep background in designing scalable, secure systems, he has become a leading voice in the “SaaSpocalypse” debate, exploring how artificial intelligence is rewriting the rules of the traditional software industry. His insights bridge the gap between cutting-edge AI experimentation and the rigorous requirements of highly regulated corporate environments, providing a roadmap for leaders navigating the shift from standard subscriptions to bespoke, AI-generated internal tools.
In this conversation, we explore the rising trend of “vibe coding” and its potential to disrupt the “buy vs. build” paradigm that has dominated IT for two decades. We discuss the hidden costs of software subscriptions, the “security taxes” imposed by vendors, and the architectural guardrails necessary to ensure that automated development doesn’t compromise organizational safety.
Many organizations are moving away from standard software subscriptions toward AI-generated internal tools to avoid rising costs. How does this shift change the traditional “buy vs. build” decision, and what specific metrics should a company track to ensure these custom replacements remain cost-effective long-term?
The “buy vs. build” decision used to be heavily weighted toward buying because the maintenance of custom code—patching, capacity planning, and security updates—was an enormous “cost center” for non-core applications. However, AI-driven development, or vibe coding, is shifting that curve by allowing an engineering lead to recreate core functionality in a matter of hours rather than weeks, as we saw recently when a startup faced a 100% price hike on a SaaS renewal and chose to build a replacement instead. To ensure long-term viability, organizations must track “technical debt velocity,” measuring how much effort is required to update AI-generated code compared to a subscription fee. They should also monitor the “maintenance-to-innovation ratio” to ensure that the time saved by not managing a vendor isn’t swallowed up by fixing “hallucinated” bugs or off-by-one errors in the custom stack. Finally, assessing the total cost of ownership must include the compute costs for the AI models used to maintain the code, ensuring the “bespoke enough” software doesn’t eventually become more expensive than the original subscription.
Some software vendors lock essential security features like single sign-on or advanced logging behind expensive enterprise tiers. How can vibe coding help teams bypass these “security taxes,” and what practical steps must be taken to ensure these home-grown tools don’t create even larger vulnerabilities?
Vibe coding allows teams to build lightweight, internal versions of these tools that integrate directly with their own existing identity providers, effectively bypassing the “enterprise tier” requirement for basic security hygiene. For example, instead of paying for a top-tier CRM just to get SSO, a team can generate a custom interface that talks to their internal database using their own secure authentication hooks. However, the risk of creating a “security debt” is real, so teams must implement automated security testing from day one—something one large organization is already doing by ensuring every small AI project has full test case coverage and documentation. We must use AI to write code that is secure by default and employ deterministic architectures that limit what the code can do, regardless of whether it was written by a human or a model. It is about shifting the responsibility from the vendor’s pricing model to internal, automated guardrails that verify model provenance and code integrity.
As development speed accelerates, the traditional requirement for human review of every line of code is becoming increasingly impractical. What alternative guardrails or deterministic architectures can be implemented to maintain safety, and how do you prevent emerging threats like “slopsquatting” in an automated environment?
We are reaching a point where the sheer volume of AI-generated code will make human review a bottleneck that most aggressive organizations will simply ignore, which is why we need “AI-to-review-AI” workflows. Deterministic architectures are crucial here; these are known controls implemented in rules and hard-coded limits that act as a “sandbox” for AI-generated services, ensuring that even if a piece of code is malicious or poorly written, it cannot access sensitive data or perform unauthorized actions. To combat “slopsquatting”—where attackers exploit low-quality, AI-generated dependencies—organizations should integrate automated fuzzing and real-time URL allow-list maintenance into their deployment pipelines. This creates a “dark factory” environment where the safety is built into the infrastructure and the hosting platform, rather than relying on a tired developer to spot a subtle flaw in 10,000 lines of generated code.
Maintaining legacy systems often creates significant technical debt and security risks for established firms. How can automated tools be used to refactor these old applications into memory-safe languages, and what is the step-by-step process for applying these techniques to critical, non-core business infrastructure?
AI has a unique ability to handle the “hygiene” tasks that humans find tedious, such as refactoring a decades-old legacy application into a memory-safe language like Rust or a more modern framework. The process starts with using AI to document the existing “undocumented” logic of the legacy system, followed by generating a comprehensive suite of test cases to ensure parity between the old and new versions. Next, the AI can perform a staged refactoring of non-core components, such as reporting modules or data entry forms, before tackling the more critical business logic. Finally, the organization can use AI to continuously update the threat model of this newly refactored code, essentially paying off years of accumulated security debt in a fraction of the time it would take a manual team. This transition allows firms to keep their proprietary data on-premise or in private clouds while benefiting from modern, secure codebases.
Vibe coding is currently most common in risk-tolerant startups for relatively simple tasks. How will this trend eventually migrate into highly regulated, risk-averse sectors, and what specific milestones must the technology hit before it can manage mission-critical business functions?
The migration will follow three axes: complexity, importance, and risk aversion, starting with simple internal tools and gradually moving toward mission-critical systems. For highly regulated sectors like banking or healthcare to adopt this, we need to hit milestones in “model provenance”—the ability to prove that the AI wasn’t trained on malicious data—and “confidential computing” guarantees that protect data during processing. These organizations will likely wait for the emergence of “Regional Guarantees” and standardized AI-assurance platforms that can certify AI-generated code against regulatory frameworks. We saw this exact pattern with cloud adoption; it took nearly 20 years for governments to feel comfortable, but the business pressure eventually made it inevitable. Once the “vibe-coded” solutions can demonstrate better uptime and fewer vulnerabilities than aging SaaS platforms, even the most risk-averse CFOs will make the switch.
AI has the potential to handle time-consuming hygiene tasks like maintaining URL allow-lists or generating test cases. How can teams integrate these capabilities into their daily workflow to improve security, and can you share an anecdote where automation successfully reduced an organization’s technical debt?
Integrating AI into daily workflows should focus on the “invisible” security tasks that often fall through the cracks, such as the permanent updating of threat models or the generation of “fuzzing” tests for every new feature. I know of a large organization that recently embraced this, making it a mandatory part of their CI/CD pipeline so that even the smallest “vibe-coded” utility has the same level of automated security testing as their core banking software. This automation successfully reduced their technical debt by identifying redundant URL connections in legacy apps and automatically generating the allow-lists to block unnecessary traffic. By letting AI handle the “drudge work,” the security team was freed up to focus on high-level architecture rather than manually reviewing firewall logs. It turned a reactive security posture into a proactive one without increasing the headcount.
Software providers that survive the next decade may need an inherent “moat,” such as regulatory compliance or a critical mass of proprietary data. How should businesses evaluate which platforms are truly irreplaceable, and what strategies should they use to migrate the rest to AI-managed alternatives?
Businesses should conduct a “moat audit” of their SaaS portfolio, asking if a provider offers something that cannot be replicated by a multi-agent AI “town” or a bespoke internal tool. Truly irreplaceable platforms are those that provide cross-customer data insights, meet complex global regulatory requirements, or manage physical infrastructure—what we call “Infrastructure-as-a-Service” (IaaS) and “Platform-as-a-Service” (PaaS). For the rest, the strategy should be a gradual migration: start by “vibe coding” the peripheral features of a SaaS tool as internal extensions, and once the core functionality is replicated and tested, terminate the subscription. This allows the organization to regain sovereignty over its data and workflows while only paying for the high-value infrastructure that actually requires a specialized vendor.
What is your forecast for the future of the SaaS business model?
My forecast is that the SaaS model will undergo a massive bifurcation over the next 5 to 10 years, where “commodity” software will be almost entirely replaced by internal AI-generated tools, while “moated” platforms will become even more entrenched. We will see a shift away from the per-user subscription model toward “outcome-based” pricing or even “compute-based” licensing as vendors realize they are competing with their customers’ own AI agents. The survivors will be those that transition from being a “tool you use” to a “platform you build upon,” offering deep integration and compliance that an isolated AI cannot easily replicate. Ultimately, we are entering an era where software becomes more disposable and more bespoke simultaneously, forcing vendors to provide genuine, irreplaceable value or face the “SaaSpocalypse.”
