SaaS, PaaS, and IaaS: How to Decide What Your Company Should Own

When a startup says “our infrastructure is built on SaaS and PaaS,” the difference between treating this as a technical preference and reading it as a strategic statement can significantly alter the quality of your technical due diligence. The choice of SaaS, PaaS, or IaaS is a declaration of where a company creates value and where it treats capabilities as commodities.

This article provides a framework for non-engineer investors and M&A professionals to interpret these decisions in the context of business judgment.

Definitions: Organized by “Who Is Responsible for What”

SaaS, PaaS, and IaaS are not classified by technical implementation differences, but by where the boundary of responsibility lies between the service provider and the user.

Figure 1: Responsibility boundaries across SaaS, PaaS, and IaaS

IaaS (Infrastructure as a Service) provides virtual servers, storage, and network resources on demand. AWS EC2, Google Compute Engine, and Azure Virtual Machines are the prime examples. Users handle everything from OS installation to middleware configuration and application operations. IaaS offers maximum flexibility and customization, but comes with a corresponding level of technical management responsibility.

PaaS (Platform as a Service) provides a managed execution environment — runtime, middleware, and supporting services — so developers can focus on application code and data. Heroku, Google App Engine, Cloud Run, and Vercel are typical examples. Platform management, patching, and most operational concerns are delegated to the vendor.

SaaS (Software as a Service) delivers application functionality directly as a service. Salesforce (CRM), Slack (communications), Notion (documentation), and Stripe (payments) are familiar examples. Users are responsible only for configuration and their own data; everything else is managed by the vendor.

The Decision Framework: What Should Your Company Own?

Understanding these three categories is the first step. The more important question is that the right choice depends entirely on the nature of the business. Two primary axes drive the decision.

Axis 1: Is This Function a Source of Competitive Advantage?

Functions that are core to a company’s competitive differentiation warrant lower dependence on external services. Conversely, commoditized functions that every competitor also needs are well-suited for SaaS.

Consider a startup whose competitive edge is a logistics optimization algorithm. Running that computational logic on a PaaS execution environment is entirely rational. Using SaaS for internal HR management is equally rational — competing on HR management is not their strategy.

By contrast, when a fintech startup decides “Stripe is sufficient for payment processing,” the question behind that decision is whether there is a conscious strategic rationale: “payment flows themselves are not our differentiator — the user experience and financial products built on top of them are.” If that reasoning exists, the decision is sound. If it doesn’t, it may simply reflect an absence of strategic thinking.

Axis 2: How Does the Cost Structure Change at Scale?

SaaS, PaaS, and IaaS each have different cost scaling characteristics.

SaaS typically scales with user count or seat count. Costs are predictable per user but grow proportionally as the organization expands from 100 to 1,000 people.
PaaS scales with product usage — request volume, processing time, data throughput. As users increase, cloud costs increase, directly affecting gross margin.
IaaS carries higher initial setup costs but tends to be most cost-efficient at significant scale. Netflix’s deep IaaS optimization exists precisely because they have reached that threshold.

In early stages, leveraging SaaS and PaaS minimizes operational overhead while maximizing development speed. As a product scales, cost efficiency may drive decisions to migrate certain functions from PaaS to IaaS, or from third-party SaaS to in-house development.

Reading Cost Structures

In M&A and investment evaluation, the ratio of SaaS, PaaS, and IaaS in a company’s stack affects how legible the cost structure is.

The risk of SaaS overuse is “invisible fixed cost accumulation.” The more SaaS tools an organization uses, the more subscription costs pile up. Startups with more than 100 employees often spend several million yen per month on technical SaaS alone. These costs are often dispersed across departments, with no single owner tracking the full picture. During due diligence, simply collecting all invoices and contracts to understand the complete SaaS footprint can require significant effort.

The risk of IaaS overuse is “internalized management cost.” Running IaaS effectively requires specialized infrastructure engineers. All the work that PaaS or SaaS vendors handle — server configuration, patch management, scaling design, security hardening — must be done in-house. A startup with few engineers that is heavily dependent on IaaS is, in effect, also running an infrastructure management business on the side.

Evaluating Vendor Dependency Risk

Heavy SaaS and PaaS usage means accepting exposure to vendor price changes, service discontinuation, and terms-of-service revisions. Three questions matter most in evaluation.

First, concentration in a single vendor. If a specific SaaS handles core business operations — for example, all customer data concentrated in one CRM — price increases or service termination from that vendor can directly threaten business continuity.

Second, data portability. Can data stored in the SaaS be exported? Is it accessible in standard formats (CSV, JSON, etc.)? Heavy dependence on a vendor’s proprietary data format significantly increases migration costs.

Third, contract transfer risk in M&A. When acquiring a company, the target’s long-term SaaS contracts may transfer to the acquirer. Reviewing contracts for cancellation penalties, minimum commitment periods, and automatic renewal clauses is a necessary part of due diligence.

Due Diligence Checklist for Stack Evaluation

Strategic Alignment

What is the technical implementation of the core competitive differentiator? — If the differentiating function depends on SaaS, confirm the rationale (deliberate cost decision, or lack of strategic thinking?).
Does a complete list of all SaaS tools exist? — Significant shadow IT (unmanaged SaaS) suggests low maturity in cost management, information security, and contract governance.
Are there clear reasons for technology stack choices? — “The engineer at the time was familiar with it” versus “we chose this considering cost characteristics at scale” signals very different levels of technical strategy maturity.

Cost Structure

Are the monthly total and breakdown of SaaS costs tracked? — Review total annual SaaS contract value. Costs that appear excessive relative to ARR indicate optimization opportunity.
What is the revenue-to-PaaS-cost ratio? — If cloud costs grow faster than revenue or user count, unit economics may deteriorate as the company scales.
Are there cost optimization practices? — Check whether unused SaaS seats and over-provisioned PaaS resources are reviewed and cleaned up regularly.

Technical Risk

Can critical data be exported? — Verify that customer data, transaction data, and content can be extracted from key SaaS tools.
What are the terms of long-term SaaS contracts? — Review cancellation penalties, minimum commitment periods, and auto-renewal clauses.
Are there contingency plans for service discontinuation? — Especially for niche SaaS dependencies, assess the impact and available alternatives if the service shuts down.

Stack Evolution Across the Startup Lifecycle

A final important observation: the optimal stack choices change as the business matures.

Early stage (pre-PMF) prioritizes speed and cost minimization. Maximizing PaaS and SaaS to minimize infrastructure management overhead is rational. Platforms like Heroku, Vercel, and Supabase — which provide fully managed environments — along with SaaS for authentication, payments, and email, represent a sound early-stage approach.

Growth stage (post-PMF through Series B) involves cost structure optimization and addressing technical debt. Decisions emerge about whether to in-house certain functions previously delegated to SaaS, or to migrate to more cost-efficient PaaS or IaaS.

Scale stage (Series B and beyond) is where deep IaaS optimization can become a competitive factor. As scale increases, the optimization potential in infrastructure costs grows accordingly. If IaaS operational expertise doesn’t exist internally at this stage, recruitment and training become a constraint.

Evaluating whether the current stack matches the company’s lifecycle stage is a useful lens in investment and acquisition contexts. It helps answer: “How much technical debt has accumulated?” and “What investment is needed to support future growth?”

The SaaS/PaaS/IaaS discussion pairs naturally with cloud vendor selection. Cloud Services Explained: Reading AWS, GCP, and Azure as Business Decisions covers how to evaluate which cloud provider to choose.

For system design choices, Architecture Patterns: How to Evaluate Monolith, Modular Monolith, Microservices, and Serverless as Business Decisions addresses how application architecture choices affect business outcomes. Reading it alongside this article builds a more complete picture of the full technology stack.

For the overall framework of technical due diligence — including technology stack evaluation — see The Complete Picture of Technical Due Diligence and Its Seven Evaluation Axes.

Tied Inc. provides technical due diligence support for VC investors and corporate M&A teams, including technology stack evaluation. Visit our investor services page or startup services page, or contact us to discuss your needs.