Three terms, one confusing taxonomy

SaaS, PaaS, and IaaS — software as a service, platform as a service, and infrastructure as a service — are terms that get used frequently in technology discussions and just as frequently misused or confused. If you are making decisions about what to build or what to buy for your business, understanding the distinction clearly is worth the effort.

This post explains each model plainly, with examples, and then turns the question around: given what you are trying to accomplish, which model — or combination — should you be thinking about?

Infrastructure as a Service (IaaS)

IaaS providers give you virtualised computing infrastructure over the internet: servers, storage, networking, and related resources. You rent the hardware; you are responsible for everything else — operating systems, middleware, runtimes, data, and applications.

AWS EC2, Google Compute Engine, and Microsoft Azure Virtual Machines are IaaS. You spin up a virtual server, configure it however you like, and run whatever software you want on it.

You control: Operating system, middleware, runtime, applications, data

Provider controls: Physical infrastructure, virtualisation

IaaS gives maximum control and flexibility. It also requires maximum operational expertise. Someone needs to configure and harden the operating system, manage security patches, monitor resources, and handle incidents. This is appropriate when you have specific requirements that more opinionated platforms cannot accommodate, or when you need to operate in an environment where you control the full stack.

Platform as a Service (PaaS)

PaaS sits above IaaS. The provider manages the infrastructure and the platform — operating system, middleware, runtime, scaling infrastructure — and you deploy your application code and manage your data. You focus on your application; the provider handles the plumbing.

Heroku, Google App Engine, and AWS Elastic Beanstalk are PaaS products. You push your code; the platform handles deployment, scaling, and much of the operational overhead. Vercel and Railway are more recent examples popular with web developers.

You control: Applications and data

Provider controls: Runtime, middleware, operating system, infrastructure

PaaS is a significant productivity gain compared to IaaS for teams that do not need to control the full stack. You spend less time on operational concerns and more time on product. The tradeoff is less control and potential vendor lock-in to the platform's conventions and capabilities.

Software as a Service (SaaS)

SaaS is the model most people are familiar with. The provider manages everything — infrastructure, platform, application — and you access the software over the internet, typically through a web browser. You configure it within the bounds of what the application supports; you control nothing below the application layer.

Salesforce, Slack, Notion, Gmail, and Xero are all SaaS products. You use them; someone else builds, operates, and maintains them.

You control: Configuration and data (within the application's capabilities)

Provider controls: Everything else

SaaS is the lowest operational overhead option. You do not manage servers, patches, or infrastructure. The tradeoffs are limited customisation capability, dependence on the provider's availability and pricing, and less control over your data.

As a business: buy vs build

The practical question for most businesses is not "which of these is best" but "what should I buy as a SaaS product, and what should I build?"

The general principle: buy SaaS for commodity business functions (email, accounting, CRM, HR) and build for the things that are genuinely core to your competitive advantage. If your differentiator is not in how you run your accounts payable, use an accounting SaaS. If your differentiator is in how you analyse and act on customer data, that might be worth building.

The build vs buy calculation also involves total cost of ownership. Building something yourself has a development cost, an ongoing maintenance cost, and an opportunity cost of the time your engineering team could have spent on something more differentiating. SaaS has subscription costs and the switching cost of being dependent on a vendor.

As a developer: what infrastructure model to use

If you are building a SaaS product yourself, the question is which layer to build on. The choices are roughly:

IaaS (build everything): Maximum control, maximum operational burden. Appropriate for products with specific infrastructure requirements or very large scale where cost optimisation at the infrastructure level matters.
PaaS (focus on application code): Good default for early-stage products. Get to market faster, operate with less operational expertise, and migrate to IaaS if you eventually hit the limits of the platform.
Managed services from IaaS providers: A hybrid approach where you use IaaS but take advantage of managed database services, managed Kubernetes, managed queues, and so on. You retain more control than PaaS while avoiding some of the operational overhead of self-managing everything.

For most early-stage SaaS products, starting on PaaS or managed services is the right call. The operational burden of self-managing everything on raw IaaS is a significant distraction from product development. You can always migrate to more control later; it is harder to recapture time spent on operational work instead of product work.

SaaS vs PaaS vs IaaS: What Your Business Actually Needs