What is SaaS?

Strip a SaaS offering to its parts and it is a bundle of responsibilities:

• The application itself, delivered through a web interface or an API.
• The infrastructure and its operation - the customer never sees a server.
• Upgrades and fixes, applied by the vendor rather than scheduled by the customer.
• Identity and accounts - sign-in, roles, invitations, sometimes directory integration.
• Storage of the customer's data inside the service, on the vendor's terms.

The customer keeps the decisions that cannot be delegated: what data enters the system, who may see it, how it is classified, and whether it can be exported elsewhere. Those last two are the ones worth checking early, because the switching cost of a SaaS product is dominated by the work of extracting its data and re-teaching the people who use it.

SaaS is the top of the service-model stack: the customer consumes an outcome and operates none of the machinery. Below it, platform services hand you a deployment target, and infrastructure hands you machines. Software teams building a product for others are usually building SaaS; the model distinctions matter most when you are deciding which layer to buy or to build on.

For the side-by-side reading of the three levels - what each one takes on, where accountability moves, how the pricing differs - the comparison lives in IaaS, PaaS and SaaS on VirtEngine. This page defines only the top term.

SaaS is also how most people meet cloud computing without ever using the phrase: an account, a browser tab and a recurring charge form the entire visible surface, while the infrastructure, the platform and the people operating both stay behind the vendor's interface. That layering matters when something breaks. The support path runs to the provider for everything below the interface, and only configuration, data and access control remain in the customer's hands - which is a narrower set of levers than the phrase self-service suggests.

Procurement conversations tend to circle the same questions. Can the data leave - what export formats exist, and does the API cover the same ground as the interface? Does it fit the organisation's identity system, or will accounts be managed by hand? Is the charge per person, per unit of consumption, or per tier, and what happens at the boundary between them?

A separate class of questions concerns the vendor: where the data is held, who can access it, how the service is notified of failures, and what happens to the data when the contract ends. None of these are answered by the feature list, which is why they appear in the evaluation rather than the demo.

Contracts add a second layer of the same questions. What happens to the data at the end of the term, whether the service can be paused, and which promises the product itself enforces - rather than an agreement enforceable only by complaint - are all worth reading for. A service whose export, access and deletion paths are built into the interface is materially easier to leave than one where they depend on a support queue, and ease of leaving is worth pricing in before adoption rather than after.

A software plan behaves like a listing on VirtEngine. The provider publishes what the plan includes - entitlements, capacity components, support terms - so buyers compare contents directly instead of negotiating a private quotation. Ordering funds an escrow account first, and the fulfilment path for that lease activates the account on the provider's side.

From there the same settlement rail applies as for any other lease: the provider reports entitlement and usage as signed records, validated line items are drawn from escrow after the dispute window, and any balance left when the deployment closes returns to the tenant. Payment risk is therefore bounded on both sides - see escrow and settlement for the mechanics.