For nearly two decades, large enterprises have leaned heavily on third‑party cloud platforms—CRM suites like Salesforce, marketing clouds, and generic storage services—to manage customer and user data. The appeal was obvious: rapid deployment, subscription pricing, and a rich ecosystem of integrations. Yet as digital operations have become core to competitive advantage, many organizations are questioning whether it still makes sense to entrust their most sensitive data and differentiating workflows to multi‑tenant SaaS providers.
A growing number of enterprises are now building custom applications and data platforms in‑house, using modern cloud infrastructure, containerization, and internal product teams. The shift is not simply about cost; it is about control: control over data residency, security posture, change velocity, and the ability to encode unique business logic without fighting against the constraints of a generic platform.
The economic and strategic reality of this transition is captured by venture capitalists and software theorists Martin Casado and Sarah Wang of Andreessen Horowitz in their work, "The Cost of Cloud, a Trillion Dollar Paradox" (2021), where they point out the structural scale limits of renting infrastructure: "If you are operating at scale, the cost of cloud can at least double your infrastructure bill... With a large portion of a company’s margin potential tied up in the cloud, it is clear that optimizing—and in some cases, repatriating—this spend is a top-tier strategic priority."
The structural risks of third‑party cloud platforms
Cloud CRM and similar SaaS platforms centralize vast amounts of customer and user data in multi‑tenant environments. While leading vendors invest heavily in encryption, identity and access management, and regulatory compliance, the architectural reality remains: data is stored and processed on infrastructure the enterprise does not own, under operational and legal regimes it does not fully control.
Scholarly analyses of cloud CRM platforms highlight both strengths and weaknesses of this model. Research on Salesforce and comparable systems emphasizes robust security controls and compliance with regulations such as GDPR and CCPA, but also points to persistent challenges around data isolation, performance variability, and the complexity of managing privacy in multi‑tenant architectures (Pookandy, 2024). These tensions become more acute in sectors with strict data residency rules, such as finance, healthcare, and public administration.
When customer data is the core asset, “outsourcing” its storage and processing is never a purely technical choice—it is a strategic bet on someone else’s governance.
Multi‑cloud strategies have emerged as a partial response, allowing enterprises to combine SaaS platforms with their own environments on AWS, Azure, or Google Cloud (Mulpuri, 2025). Yet even in sophisticated multi‑cloud architectures, the CRM or marketing cloud often remains a central hub that dictates data models, integration patterns, and release cycles. The enterprise adapts to the platform, not the other way around.
The "Build Revolt" in action: Real-world repatriation
This shift is no longer theoretical; it is a documented market phenomenon. Organizations are actively replacing massive SaaS suites with custom-built internal platforms to escape subscription sprawl and reclaim control.
- Klarna: In a highly publicized architectural shift, the fintech giant completely shut down its enterprise Salesforce CRM and Zendesk instances, replacing both with custom-built internal platforms integrated with their own AI architecture to bypass high seat-license costs and rigid workflow logic.
- 37signals: Led by software pioneer David Heinemeier Hansson (2023), the company executed a highly publicized exit from AWS, championing the realization that true operational resilience lies in owning your own hardware and containerized software.
- Dropbox: In one of the earliest massive infrastructure reclamations, Dropbox migrated over 90% of its user data off Amazon S3 and onto a custom-built, in-house storage platform (Diskosity), securing total control over its primary business asset.
The scale of this shift is captured in industry data, such as Retool’s Build vs. Buy Report (2026), which notes that "Thirty-five percent of organizations had already replaced at least one major SaaS tool with a custom-built internal solution in the previous year... The build revolt is not limited to engineering-led initiatives. It includes finance leads, operations managers, and other non-technical builders who have gained access to AI coding tools."
The shift is fundamentally a battle for digital sovereignty. As technology theorist and author Cory Doctorow argues in "Chokepoint Capitalism" (2022), relying on highly consolidated, proprietary digital platforms creates a system where "when platforms lock in their users and suppliers, they can extract rent from both sides. For the enterprise, true operational resilience lies in retaining the ability to walk away, which requires owning your own infrastructure and code."
The question has shifted from "Can we build this ourselves?" to "Why are we paying a premium to not own it?"
Case studies: Industry-specific platform models
Financial services: internal CRM and data residency
Large banks and insurers have been among the earliest adopters of cloud CRM, but they also face some of the strictest regulatory regimes. Several institutions have moved from heavy reliance on third‑party CRM to hybrid or fully internal solutions. In these architectures, customer master data, transaction histories, and risk models are stored in bank‑owned data platforms, while SaaS tools are reduced to presentation layers or are replaced entirely by internal front‑end applications.
Research on architectural decision frameworks for large‑scale Salesforce implementations shows that even when a SaaS platform remains in use, enterprises increasingly favor custom development for unique processes, complex integrations, and regulatory requirements (Balachandran, 2025). This pattern illustrates a broader trend: the more critical and differentiated the process, the more likely it is to be implemented in code the enterprise owns, rather than in configurable metadata on a vendor’s platform.
Healthcare: owning clinical and patient data flows
Healthcare organizations have historically relied on third‑party electronic health record (EHR) systems and patient engagement platforms. Recent initiatives, however, show hospitals and health networks building internal data platforms that centralize clinical data, consent records, and analytics, while exposing APIs to custom applications for clinicians and patients.
In this model, third‑party tools are treated as interchangeable clients of the internal platform. Sensitive data never leaves the organization’s controlled environment; external tools consume only the minimum necessary information via well‑governed interfaces. This inversion of control allows healthcare providers to meet stringent privacy requirements while iterating rapidly on user‑facing applications.
Manufacturing and B2B services: platform thinking beyond CRM
Manufacturers and B2B service providers often have complex, long‑lived customer relationships that span sales, service, logistics, and after‑sales support. Many initially adopted SaaS CRM to unify these touchpoints, but found that the generic data models and workflows could not fully capture their domain‑specific processes.
Case studies in these sectors describe enterprises building internal platforms that combine order management, asset tracking, IoT telemetry, and customer interaction histories into a single, owned data fabric. Custom applications for sales, field service, and customer portals are then built on top of this fabric. SaaS tools, when used, are integrated via APIs and can be swapped out without disrupting the core data and logic. The result is a more resilient architecture with clearer boundaries between commodity services and proprietary capabilities.
Enterprises are discovering that the real “platform” is not the CRM vendor—it is their own data and domain model.
Design principles for building in‑house solutions
Moving away from heavy dependence on third‑party platforms does not mean rejecting cloud or modern practices. On the contrary, successful internal platforms tend to embrace:
- API‑first design: Every core capability—identity, customer profiles, billing, analytics—is exposed via stable, versioned APIs, enabling multiple internal and external applications to consume them.
- Modular services: Microservices or well‑bounded services allow teams to evolve parts of the system independently, reducing the risk of large‑scale rewrites.
- Containerization and orchestration: Technologies like Docker and Kubernetes provide portability and operational consistency across environments, making internal platforms as flexible as SaaS in practice.
- Governance and observability: Strong logging, monitoring, and security governance ensure that internal platforms meet or exceed the compliance posture of third‑party vendors.
- Selective use of SaaS: Commodity capabilities—email delivery, basic analytics, collaboration tools—can still be sourced from SaaS providers, but they are kept at the edges of the architecture.
Critically, enterprises that succeed with in‑house solutions treat their internal platforms as products, not projects. They invest in product management, developer experience, and long‑term roadmaps. This mindset counters the historical failure modes of bespoke systems—stagnation, technical debt, and poor usability—while preserving the strategic benefits of owning data and logic.
Conclusion: choosing what to own
The decision to build custom applications instead of relying on third‑party providers is not binary. Most enterprises will continue to use some SaaS tools, especially for non‑differentiating functions. The critical question is where to draw the line between rented capabilities and owned platforms.
Scholarly work on cloud CRM (Pookandy, 2024), multi‑cloud architectures (Mulpuri, 2025), and large‑scale platform implementations (Balachandran, 2025) suggests a clear pattern: as regulatory complexity and the strategic importance of data increase, so does the rationale for owning the core application and data stack. Enterprises that recognize this and invest in internal platforms gain the freedom to design exactly the workflows, controls, and experiences they need—without being constrained by the assumptions baked into someone else’s product.
Sources
- Balachandran, S. K. (2025). Architectural Decision Frameworks for Large-Scale Salesforce Implementations: Balancing Configuration and Custom Development. International Journal of Computational and Experimental Science and Engineering, 11(4), 4758–4765.
- Pookandy, J. (2024). Exploring Security and Privacy Challenges in Cloud CRM Solutions: An Analytical Study Using Salesforce as a Model. SSRG International Journal of Computer Science and Engineering, 11(9), 8–18.
- Mulpuri, R. (2025). Comprehensive Review of Multi-cloud Architecture for Salesforce in Enterprise Environments. International Journal of Science and Research Archive, 15(3), 1825–1838.
- Casado, M., & Wang, S. (2021). The Cost of Cloud, a Trillion Dollar Paradox. Andreessen Horowitz (a16z).
- Doctorow, C. (2022). Chokepoint Capitalism: How to Win Back Creative Labor from Big Tech. Beacon Press.
- Retool. (2026). The State of Custom Internal Tools: Build vs. Buy Report.
- Heinemeier Hansson, D. (2023). Why We Are Leaving the Cloud. 37signals.
