Build vs. Buy: SaaS Speed Traps and Enterprise Failure Risks

In a 2025 LinkedIn post, engineer Francesco Hayes argued that founders underestimate time more than infrastructure risk, especially when AI-assisted coding makes building internal tools feel fast and inexpensive.

His account describes teams choosing to implement their own customer relationship management or access-control systems instead of adopting low-cost software-as-a-service options. The result, he observed, is weeks of unexpected work that displaces progress on the core product.

Hayes lists the additional work that turns a quick prototype into a production system: authentication, compliance, permissions, edge-case handling, bug fixes and documentation. Each of these requirements is standard for software that must handle real users and regulated data, yet they are rarely included in the initial estimate for an internal tool.

His warning is that the apparent savings from avoiding a monthly subscription often vanish once these hidden tasks are included.

The build versus buy question does not end at the startup stage. A 2024 update to CrowdStrike’s Falcon sensor created a global outage that Microsoft later estimated affected about 8.5 million Windows devices, or less than one percent of all Windows machines.

According to a blog post on the official Microsoft site, the faulty update led to blue-screen crashes across many corporate environments and disrupted airlines, banks and other services around the world.

A subsequent analysis by cyber insurer Parametrix, summarized in its impact report, estimated that the July 2024 CrowdStrike-related outage caused roughly 5.4 billion dollars in direct financial losses for United States Fortune 500 companies excluding Microsoft.

The report highlights that traditional industries relying heavily on physical computers faced longer recovery times than cloud-native firms. Together with Microsoft’s figures, this estimate illustrates how a single software update from a widely used vendor can become a macro-level economic event.

These two reference points, drawn from startup practice and large-enterprise disruption, frame the central problem.

At one end, small teams lose time by rebuilding tools that already exist as stable SaaS products. At the other end, highly concentrated reliance on a small set of providers can create shared points of failure with sector-wide costs.

The challenge is to identify when time is the scarcest resource and when resilience against correlated outages should dominate the decision.

Startup Pressure: Time Lost to Not-Invented-Here

Not-Invented-Here syndrome describes a preference for internal solutions even when external options are available and tested.

A 2024 article in MIT Sloan Management Review examines this bias across hundreds of projects and reports that it appears in a majority of cases studied.

The authors link NIH tendencies to lower project success, noting that teams that insist on building everything themselves often struggle to match the quality and speed of specialized providers.

Hayes’s description of founders deciding to create "just a simple internal tool" aligns with this pattern. The initial decision is framed around saving a small subscription fee or maintaining control, rather than a clear forecast of the engineering time required to reach production standards.

As unplanned tasks accumulate, the internal roadmap shifts from customer-facing features to maintenance of supporting systems that do not differentiate the product in the market.

In his LinkedIn post, Hayes cites a remark widely attributed to Bill Gates: measuring programming progress by lines of code is like measuring airplane construction by weight. The exact original source of the quotation remains uncertain, but the sentiment reflects long-standing criticism of using volume of code as a proxy for value delivered.

In the context of build versus buy, the quote underscores that writing more code for internal tools does not necessarily move the business forward if the same function already exists as a commodity service.

For early-stage startups, the opportunity cost of such internal projects is especially high. Small teams must choose between building features that directly affect revenue or investing time in infrastructure, administration panels or integrations that established vendors already provide.

Hayes argues that engineers, including himself, are tempted to choose the latter because building software feels productive, even when it delays progress on customer problems.

In this environment, a practical heuristic is to favor buying for any capability that is not a genuine differentiator. Commodity functions such as authentication, payments, analytics dashboards or basic customer management usually have multiple mature SaaS providers.

Adopting these tools allows founders to allocate scarce engineering capacity to the narrow slice of functionality that defines their product, while deferring infrastructure decisions that can be revisited once the company has more data and resources.

Enterprise Exposure: When Convenience Becomes a Single Point of Failure

The CrowdStrike incident illustrates that the same properties that make SaaS attractive to startups create concentrated risk at scale.

In a July 2024 post on the official Microsoft blog, the company described how a defective configuration file in a Falcon update crashed Windows machines globally and required coordinated remediation with cloud providers and customers.

Instant, automated deployment meant the faulty update propagated rapidly across environments that depended on the service for endpoint protection.

The Parametrix report on the outage concludes that direct financial losses for affected Fortune 500 companies reached an estimated 5.4 billion dollars. Analyses citing the report, including coverage on Cybersecurity Dive, note that insured losses represented only a fraction of total business interruption costs.

For many firms, the most significant impacts were operational, including grounded flights and delayed transactions, rather than permanent data loss.

A Beige Media article on SaaS reliance and enterprise single points of failure uses the CrowdStrike event as a case study in concentration risk.

The analysis focuses on how many organizations depend on overlapping sets of vendors for endpoint security, identity management, communications and core applications.

When these services sit on similar cloud infrastructure or share deployment channels, a defect or outage in one link can affect many layers of a company’s stack simultaneously.

The U.S. Department of the Treasury has also documented concern about this pattern. A 2022 Treasury report on financial services adoption of cloud services warns that a cyber incident or outage at a dominant cloud provider could affect many financial institutions at once.

The report, available on the Treasury site, points out that heavy reliance on a small number of providers can magnify the impact of any operational failure, even when each provider has strong internal controls.

In the European Union, the Digital Operational Resilience Act introduces a framework to classify certain cloud and information and communication technology providers as critical third parties.

Under DORA, described in guidance cited by the Beige Media analysis, supervisors can subject those entities to direct oversight when their services support multiple regulated institutions.

This regulatory approach treats technology vendors as part of the financial system’s infrastructure rather than as neutral suppliers.

Market Signals: SaaS Backup and Dependency Governance

Industry forecasts reflect a shift from viewing SaaS as inherently resilient to treating it as another layer requiring contingency planning.

In a 2024 press note, Gartner projects that by 2028 about 75 percent of enterprises will prioritize backup of SaaS applications as a critical requirement, compared to 15 percent in 2024.

Analyst Michael Hoeck is quoted in that note stating that SaaS backup will move from a niche concern to a standard expectation.

This change in posture implies that organizations no longer assume providers will always prevent or absorb failures. Instead, they expect to maintain independent copies of key SaaS data and to measure providers against explicit recovery time objectives.

Vendors respond by emphasizing export tools, backup options and regional redundancy in their product descriptions, while customers ask for more detailed information about outage scenarios and remediation pathways during procurement.

Beige Media’s analysis frames this evolution as part of a broader need for dependency mapping. Rather than tracking only primary vendors, the article recommends that enterprises document upstream and downstream connections, such as identity providers, cloud platforms and security tools that support customer-facing services.

Without this mapping, it is difficult to assess whether nominally distinct SaaS products in fact represent a single shared point of failure.

The combination of Gartner’s backup forecast, Treasury’s cloud-concentration concerns and the CrowdStrike case study suggests that enterprises must treat SaaS adoption as a structured risk-management exercise.

The relevant variables include not only service-level agreements and price, but also the degree of overlap among vendors, the ease of exporting data and the organization’s ability to operate in a degraded mode when a provider is unavailable. These questions are operational, not merely contractual.

Over time, this perspective can push organizations toward hybrid approaches. Some systems may remain fully outsourced with strong contractual protections and backups, while others move to controlled self-hosting or are redesigned to limit reliance on automatic updates.

The goal is not to eliminate SaaS, but to avoid architectures in which a single update mechanism or identity provider can disrupt multiple business-critical processes at once.

A Stage-Based Rubric for Build Versus Buy

Taken together, Hayes’s observations and the enterprise outage data point toward a stage-dependent framework.

For very small teams, typically under twenty people, the scarcest resource is time. At this stage, the risk of total systemic failure from a vendor outage is relatively low, while the risk of missing product milestones due to internal tool-building is high.

The default in this phase should be to rely on SaaS for any non-differentiating capability and to invest engineering time in features that directly support users or revenue.

As organizations grow into the range of tens to a few hundred employees, their external footprint and regulatory exposure increase.

At this growth stage, it becomes feasible and necessary to map external dependencies on a regular schedule, such as quarterly reviews that inventory providers for authentication, payments, communications, analytics and security.

The objective is to identify shared dependencies, to evaluate whether certain functions should have multi-vendor coverage and to ensure that contracts include clear service-level and remediation terms.

For larger enterprises operating at public scale, the priority shifts to resilience and governance. In this context, Beige Media’s article suggests that organizations consider self-hosting systems that embody core intellectual property or that support legally critical processes where outage tolerance is low.

Commodity functions can remain with SaaS providers, but with structured diversification across at least two vendors where technically and economically feasible, along with tested procedures for switching or failing over between them.

Across all stages, maintaining an export path for data is a unifying principle. Systems that can only be used through one provider’s interface or that lack complete, documented export capabilities make it harder to recover from outages or vendor exit.

By favoring tools with standard formats and well-documented application programming interfaces, organizations preserve the option to migrate, back up or re-implement critical workflows if provider risk becomes unacceptable.

Another cross-cutting practice is to validate assumptions about deployment and update mechanisms. The CrowdStrike outage showed that automated updates can introduce correlated failures even when providers and customers share strong incentives for reliability.

Enterprises can negotiate staged rollouts, opt-in channels, or additional testing gates for high-impact changes, while startups can at least track version changes and maintain minimal rollback plans for tools that sit directly in the product’s critical path.

AI as a Multiplier for Both Speed and Concentration

Hayes explicitly notes that his time-risk warning is sharpened by the availability of AI tools. Code-generation assistants and AI-enhanced frameworks reduce the effort required to create an initial implementation of an internal system.

This can make the decision to build feel more attractive, because the first version arrives quickly and appears functional. However, his checklist of production requirements remains valid regardless of how the code is written.

The AI era also affects the vendor side of the equation. Many AI-powered SaaS tools rely on a small set of large model providers and cloud platforms for inference and training.

While the Beige Media article focuses on security and infrastructure vendors, the same concentration logic applies to AI infrastructure.

If multiple applications within an enterprise depend on the same underlying AI platform for critical decisions or user-facing features, an outage, policy change or quality problem in that platform can have effects similar to a traditional SaaS failure.

This dynamic suggests that organizations should treat AI dependencies as part of their broader vendor and infrastructure map.

Questions include where models are hosted, how inputs and outputs are stored, whether local fallbacks exist and what alternative providers or models could be used in case of disruption.

These considerations are nascent compared to more mature SaaS risk practices, but the CrowdStrike example shows how quickly a widely adopted technical layer can become a systemic point of failure.

At the same time, AI can support better build versus buy decisions by making dependency analysis and risk modeling more tractable.

For example, automated tools can help identify shared providers across a portfolio of SaaS applications or simulate the impact of a provider outage on different business processes.

Used in this way, AI does not remove the trade-offs described by Hayes and Beige Media but can make them more visible to decision-makers across technology and finance teams.

Aligning Build and Buy With Real Costs

Both Hayes’s startup-focused post and Beige Media’s enterprise analysis converge on the idea that the visible cost of a technology choice is often a small part of its real impact.

For founders, the missing component is usually time and attention diverted from the product. For large organizations, the missing component is often correlated outage risk and the difficulty of recovering from failures that originate in shared external services.

A practical way to reconcile these perspectives is to define, for each significant system, the primary constraint it must respect.

Early-stage teams might frame constraints in terms of weeks of engineering bandwidth and near-term runway, while later-stage organizations might emphasize maximum tolerable downtime, regulatory obligations and cross-system dependency graphs.

The same build or buy decision can have different answers under these different constraints without either side being inconsistent.

The CrowdStrike outage serves as a reminder that placing too much functional responsibility in a small number of external services can produce losses that exceed the visible savings from outsourcing.

The NIH research, together with Hayes’s examples, shows that rejecting mature external solutions can also be costly when it leads to duplicated effort and slower delivery.

The common thread is that decisions anchored solely on subscription price or control preferences miss important dimensions of risk.

As AI tools change the economics of building and as regulators pay closer attention to concentration in cloud and ICT services, organizations that revisit their build versus buy assumptions regularly will be better positioned to adjust.

A stage-based rubric that evolves from speed-focused SaaS adoption to resilience-focused diversification and selective self-hosting offers a way to manage this transition.

The key is to treat each major system as a portfolio of risks over time rather than a one-time procurement choice driven only by near-term cost.

Sources

• Francesco Hayes. "Founders underestimate time more than infrastructure risk." LinkedIn, 2025.
• MIT Sloan Management Review. "Beating the Not-Invented-Here Syndrome." MIT Sloan Management Review, 2024.
• Microsoft. "Helping our customers through the Crowdstrike outage." Official Microsoft Blog, 2024.
• Parametrix Insurance. "CrowdStrike’s Impact on the Fortune 500." Parametrix Insurance, 2024.
• U.S. Department of the Treasury. "The Financial Services Sector’s Adoption of Cloud Services." U.S. Department of the Treasury, 2022.
• Gartner. "Gartner Predicts 75% of Enterprises Will Prioritize Backup of SaaS Applications as a Critical Requirement by 2028." Gartner, Inc., 2024.
• Beige Media. "When SaaS Reliance Turns Into an Enterprise-Wide Single Point of Failure." Beige Media, 2025.