Software as a service, or SaaS, changes how software is delivered, maintained, and paid for. This guide explains the model from both sides of the contract: what the provider operates, what the customer still owns, and how recurring revenue relates to the cost of delivering an ongoing service.
What Is the SaaS Business Model?
SaaS is software that a provider operates and makes available over a network, commonly through a browser or an application connected to a hosted service. Customers often pay a recurring subscription or usage-based fee instead of managing the full application infrastructure themselves. The provider handles much of the technical operation, but customers still have responsibilities for users, data, configuration, and appropriate use.
What makes software a service
The defining idea is ongoing delivery rather than simply renting a software license. The provider runs the application environment, maintains the service, and supplies access under agreed terms. Users do not normally manage the servers or operating system supporting the application.
AWS's SaaS overview describes this provider-managed delivery model and common access patterns. A browser is common but not essential: a desktop client, mobile app, or API can connect to a SaaS backend. Some products also offer limited offline features that synchronize later.
SaaS differs from infrastructure as a service, where customers generally manage more of their software environment on rented computing resources. It also differs from installing a licensed application on an organization's own servers. These options allocate work differently rather than forming a simple ranking from old to new.
A subscription alone does not prove that a product is SaaS. Locally installed software can also be sold by subscription. Conversely, a hosted software service may have a free tier, transaction fees, or metered usage instead of a fixed monthly charge. Delivery model and pricing model are related but separate concepts.
How hosting and tenancy work
Many SaaS products use multi-tenancy: one service supports several customer organizations while separating their data and access. Shared infrastructure can let a provider spread maintenance work and capacity across customers. However, isolation depends on architecture and controls; sharing a service does not automatically make the data secure.
Other products use separate application instances, databases, or deployment environments for some customers. A single service can also combine shared and isolated components. There is no requirement that every SaaS product use exactly one instance or deploy updates to every customer simultaneously.
For customers, the important questions are practical. How is tenant separation enforced? Which staff can access customer information? Where is data processed? How are backups protected, and what happens when an account is deleted? A tenancy label alone does not answer these questions.
Provider-managed updates reduce the need for customers to install server patches. They also mean the customer may have less control over interface changes, feature removal, and upgrade timing. Release communication, compatibility commitments, and administrative controls therefore matter alongside the product's current feature list.
Availability also depends on a chain of services. The application may rely on hosting, identity providers, payment systems, and external APIs. Ask how outages are communicated and what the customer can still do during disruption. A hosted delivery model does not eliminate operational dependencies; it changes who manages them.
Understand the shared responsibilities
SaaS moves substantial operational work to the provider, but it does not transfer every security obligation. Microsoft's shared responsibility guidance explains how responsibilities shift across cloud service models while customers retain important duties around data and access.
| Area | Typical provider role | Typical customer role |
|---|---|---|
| Application operation | Run and maintain the hosted service | Understand limitations and configure approved use |
| User access | Supply authentication and permission features | Assign access and remove departed users |
| Customer data | Protect and process it under agreed terms | Decide what to upload and who may use it |
| Service recovery | Maintain the agreed recovery capabilities | Plan business continuity and verify needs |
| Integrations | Provide supported interfaces | Secure connected accounts and credentials |
| Legal obligations | Meet the provider's applicable duties | Assess obligations for the customer's use case |
Specific contracts can change this allocation. For example, a provider may offer backup restoration only under defined conditions, while the customer needs an independent export for business continuity. Do not assume that a recycle bin is equivalent to a full recovery service.
Configuration mistakes remain consequential. An organization can expose information by allowing broad sharing or retaining former employees' accounts even when the underlying service is well maintained. Review permission settings, require suitable authentication, and identify who administers the account.
Likewise, using a SaaS vendor does not establish regulatory compliance by itself. Evaluate data categories, processing locations, retention, subprocessors, and contractual commitments with appropriate specialists where needed. A general security statement is not a substitute for requirements specific to the organization.
How SaaS businesses earn revenue
A provider may charge per seat, per workspace, by usage, by feature tier, or through a combination. Pricing should relate to customer value while covering the cost and risk of providing the service. The unit that is easy to count is not always the unit customers consider fair.
Per-seat pricing can be understandable but may discourage inviting occasional users. Usage pricing can align with activity but make bills harder to predict. Feature tiers can separate needs effectively, provided essential controls are not obscured and buyers understand what each plan includes.
Contracts may be monthly or annual, with different renewal, cancellation, and refund terms. An annual payment can improve the provider's cash position, but it also creates an obligation to continue service. Cash received, recurring revenue metrics, and recognized accounting revenue are not interchangeable concepts.
Providers also earn income from implementation, training, or custom work. These services can support adoption, but one-time charges should not be mixed into recurring subscription metrics without clear labeling. Otherwise, reported growth can overstate the durability of the customer base.
Discounts and free tiers need similar care. A large number of free accounts does not establish a viable business, and discounted contracts may not renew at the standard rate. Explain which customers, prices, and fees are included whenever comparing revenue figures across periods.
Work through the recurring economics
Consider a hypothetical provider with 50 customers paying $200 per month each. Its subscription monthly recurring revenue is $10,000 before any discounts, credits, or contract changes. If five customers cancel and nothing else changes, $1,000 of that monthly base is lost.
Now suppose the provider spends $2,000 per month on direct service delivery, including relevant infrastructure and support costs under its chosen accounting definition. The remaining $8,000 is not net profit: product development, sales, administration, and other expenses may still need to be paid. The example is illustrative, not an industry margin benchmark.
Expansion can offset cancellations. Some customers may add seats or move to a higher plan while others reduce spending. Distinguish customer retention from revenue retention: keeping the same number of organizations does not guarantee the same revenue, and revenue growth can hide the loss of smaller customers.
Acquisition cost and customer lifetime value are useful ideas, but early estimates can be fragile. A company with little renewal history should not assume a stable customer lifetime based on a short observation period. Use conservative scenarios and update assumptions as actual cohorts mature.
Recurring revenue can improve planning because contracts and renewals provide visibility. It is not inherently guaranteed or profitable. Reliability, continued value, service costs, and customers' alternatives determine whether the recurring relationship persists.
Assess the benefits and trade-offs
For a customer, SaaS can reduce the work of deploying servers and maintaining application updates. It can also make collaboration and remote access easier when the service supports them. Those benefits depend on connectivity, product design, permissions, and the organization's workflow.
The trade-offs include ongoing fees, dependence on the vendor, limits on customization, and the effort of moving data elsewhere. Compare the full cost of ownership rather than contrasting a monthly fee with only the purchase price of installed software. Internal maintenance and migration effort belong in the comparison too.
For a provider, one shared product can serve many organizations, but delivering a dependable service creates continuing work. Support, incident handling, security maintenance, billing, abuse prevention, and customer onboarding do not disappear when the software is shipped.
Before committing to a service, test the exit path. Export representative records and attachments, inspect the resulting format, and determine whether relationships and history survive. Ask what happens after cancellation and whether access to exports requires an active paid account.
Finally, evaluate fit for the actual workflow. A low-cost plan may become expensive if it requires extensive manual work, while a more capable service may save time only if the organization can adopt it. The right model is the one whose responsibilities and economics match the need.
Questions About the SaaS Model
Is SaaS always cheaper than running software yourself?
No. Compare subscription fees, implementation, integrations, administration, connectivity, and exit costs against the full operating cost of alternatives. Workload scale and internal expertise can change the result.
Can SaaS work without an internet connection?
Some products offer offline clients or cached functions, but this is product-specific. Check which actions work offline, how conflicts are handled, and what happens when authentication expires before relying on that capability.
Who owns data stored in a SaaS application?
Ownership and permitted processing depend on the contract and applicable law. Review the terms for content rights, provider access, model training uses if relevant, export, deletion, and retention rather than assuming a universal rule.
What happens if the provider closes the service?
The contract and shutdown process determine what notice and export options are available. Maintain a continuity plan proportionate to the application's importance, including current exports where appropriate and a realistic replacement route.
Understand the Service Behind the Subscription
SaaS replaces much of the customer's software-operation burden with an ongoing service relationship. Understanding that relationship means examining delivery, responsibilities, pricing, retention, and the ability to leave—not just the monthly subscription amount.
Next steps: Follow the SaaS startup building guide, review SaaS startup strategy, or visit the SaaS startups hub.
Sources
- AWS — What is SaaS?
- Microsoft Learn — Shared responsibility in the cloud
This guide is general education, not professional financial, legal, or security advice.