Jan Mikoláš
Glossary
SaaS
Software as a Service describes how a product is delivered and operated. It does not automatically determine the architecture, the number of customers sharing an instance, or the business model.
Short definition
The provider runs the application and the customer uses it as a ready-made service.
A SaaS customer generally does not install and manage the entire application stack on its own server. It signs in to a web application or connects another system through an API; the provider handles releases, service availability, monitoring, backups, and support according to the agreed terms.
SaaS is a type of software service, not a particular framework or database schema. It commonly runs in the cloud and uses subscription pricing, but neither cloud infrastructure nor recurring payment defines SaaS on its own. The defining point is that a customer uses an application operated by its provider as a service.
What it solves
It shifts operation of a shared product from the customer to the provider
Organisations can begin using continuously updated software without maintaining an operations team for every installation. In return, the provider accepts long-term responsibility for safe changes, availability, and data recovery.
- a business system for projects, documents, support, or invoicing used by multiple organisations
- an e-commerce or marketing service connected to customer systems through APIs and webhooks
- a specialised industry product with configurable workflows, roles, and permissions for each company
- an application with centrally managed upgrades instead of many installed versions that diverge over time
- a service for which the customer expects agreed support, availability, backups, and incident management
Practical example
A business SaaS product with isolated organisations
The application is used by two organisations, Alpha and Beta. Each has its own users, roles, records, notification settings, and integrations. Authentication verifies a person’s identity; server-side authorisation then checks their relationship to the organisation and the specific data for every operation. A tenant_id supplied by the browser is not a trusted source on its own.
Alpha may share an application instance with Beta while its data remains separated by a tenant identifier. A customer with more demanding isolation requirements may receive a dedicated database or an entire instance. Both arrangements can be SaaS: multi-tenancy is a common way to operate efficiently, not part of the definition.
The provider deploys a new version, performs a backward-compatible data migration, and monitors error rates by organisation without needlessly exposing their content in logs. Customers can adjust supported options but cannot arbitrarily modify the service’s internal code.
How it works
Organisation users → SaaS application → data and integrations
This text diagram describes a typical flow. Physically separate databases are deliberately shown as an alternative rather than a mandatory feature.
- A user enters the service The web interface or API accepts a request and establishes a verified identity.
- The organisation and permissions are determined The application evaluates membership, role, and permission to work with the specific record.
- The customer’s configuration is applied Its features, workflows, appearance, limits, or integration settings are enabled.
- The operation uses isolated data The tenant boundary applies to queries, caches, files, exports, logging, and backups.
- The service communicates with integrations Subject to permissions, it calls accounting software, an identity provider, or a customer API and records the outcome.
- Isolation alternatives Customers may share a database, use separate schemas or databases, or run in dedicated instances.
Key components and principles
The service must bring together the product, data isolation, and long-term operation.
In SaaS, one visible feature affects every supported configuration, data version, and operational process.
Customer, tenant, and isolation
A tenant is a logically isolated customer space. Isolation must prevent leaks through database queries, cache keys, files, search, exports, and asynchronous jobs.
Users, roles, and access
A user may belong to several organisations and have a different responsibility in each. RBAC helps group permissions, but resource ownership and tenant boundaries must still be checked.
Configuration instead of code branches
Supported options, feature flags, and integration settings have a clear schema. Unlimited customer-specific exceptions can make shared upgrades impossible.
Upgrades and migrations
The provider controls application and data versions. Migrations must account for volume, rollback or forward fixes, and compatibility with work already in progress.
Availability and recovery
Monitoring, backups, restore tests, capacity limits, and an incident process are part of the service. A backup without verified recoverability provides insufficient assurance.
Integrations and data security
Customer tokens are stored securely and rotated, while integration calls use timeouts and bounded retries. Data exports, deletion, and audits must all respect the organisation boundary.
Benefits, limitations, and common mistakes
Centralised operation simplifies updates but concentrates responsibility.
Practical benefits
- customers do not have to deploy every fix and security update themselves
- the provider can measure the behaviour of one supported product line
- a new organisation can often be provisioned through configuration rather than a complete manual installation
- an API provides a controlled way to connect the service to customers’ existing systems
Limitations and mistakes
- mistaking sign-in for tenant isolation and failing to filter data on one of the access paths
- deploying an irreversible migration to every customer without measurement or a safe rollout
- allowing one demanding organisation to exhaust resources shared with everyone else
- treating cloud hosting, multi-tenancy, or subscription pricing individually as a complete definition of SaaS
- promising availability without monitoring, backups, and a verified incident process
Scope of use
The provider’s operational responsibility is the defining characteristic.
A web application describes a technical means of interaction over the web, whereas SaaS also describes the operational relationship between provider and customer. An internal web system that one company runs for itself is therefore not necessarily SaaS. Conversely, SaaS may offer a mobile client, desktop add-on, or programmatic API in addition to the web interface.
Cloud computing is a broader model for providing computing resources and includes infrastructure, platforms, and ready-made application services; in that comparison, SaaS means an application consumed by a customer. Deploying an application to the cloud does not turn it into SaaS. With conventional installed software, the customer takes on more of the operation even when the licence expires after a fixed period. A licence grants the right to use software, while SaaS describes its delivery and operation. Subscription is a common commercial model, but a service may instead charge by consumption, transaction, or another agreement.
What to consider
Every feature must work safely across different customer contexts.
Technical quality becomes most visible during a version change, dependency outage, data restore, or an attempt to cross a tenant boundary.
- test cross-tenant access in APIs, background jobs, exports, files, and caches
- monitor service availability and error rates as well as each critical integration
- take backups against defined recovery objectives and regularly verify actual restoration
- deploy compatible changes and plan migrations for large customer datasets
- limit configuration to supported variants and maintain a traceable audit of sensitive operations
Common questions
SaaS in practice
Must SaaS be multi-tenant?
No. Multi-tenancy is a common operational choice. A SaaS product can use a separate database or an entire dedicated instance for a particular customer and still remain a provider-operated service.
Is every web application SaaS?
No. An internal application operated by an organisation for its own use is a web application, but is generally not a service delivered to customers by an external provider.
Is SaaS the same as cloud computing?
No. Cloud computing is a broader model for providing computing resources, while SaaS is one way a customer consumes a ready-made application. Merely running an application in the cloud does not mean it is offered as SaaS.
Must SaaS be paid for through a monthly subscription?
No. Subscriptions are common, but pricing may be based on consumption, transaction volume, a contractual period, or the service may be offered without direct payment.
How can customer data be isolated?
Options include a tenant key in shared tables, separate schemas, separate databases, or dedicated instances. The choice depends on risk, operating costs, and customer requirements.
Experience with operated applications
I design applications with data, permissions, and long-term operation in mind.
For web and business systems, I connect product needs with safe change, integrations, and observable operation.