EMZETT.SaaS
In short: “Software as a Service” — software used via subscription through the browser, instead of buying and installing it locally (e.g. Stripe, Vercel, Resend themselves are SaaS products).
In more detail: With the SaaS model, the provider centrally runs servers, updates and maintenance; customers usually pay an ongoing subscription instead of a one-time licence. For developers, this means: integration usually via an API/a dashboard, no server management of your own needed — the basic principle of almost all third-party services documented in this wiki.
In Depth
SaaS is one of several “as-a-service” cloud models, which differ in how much the provider takes on and how much control stays with the customer: IaaS (Infrastructure as a Service, e.g. raw virtual servers) gives full control over the operating system, but requires your own maintenance; PaaS (Platform as a Service, e.g. Vercel) handles infrastructure and the operating system, with the customer only supplying their application code; SaaS goes furthest — the customer uses a finished application via browser/API, without worrying about any underlying technology at all.
For developers, integrating SaaS services usually means: getting an API key, developing against a documented API, setting up webhooks for asynchronous events (e.g. a successful payment). The big advantage is speed — instead of building payment processing, email sending, or authentication from scratch yourself, you integrate a specialised provider that professionally solves exactly this one problem. The trade-off: dependency on an external provider (price changes, outages, discontinuation of the service are outside your own control).
Multi-tenancy as the technical foundation
Almost every SaaS product is based on “multi-tenancy” — a single application instance serves many customers (“tenants”) at once, whose data has to stay strictly isolated from each other, even though they share the same underlying infrastructure. This lets the provider spread costs across many customers (one server cluster instead of one installation per customer), but requires careful design, so that, for example, a database query never accidentally returns another tenant’s data — a flaw in tenant separation is among the most severe possible security vulnerabilities in SaaS architectures.
Pricing models
SaaS providers usually use recurring billing models instead of a one-time payment: usage-based (per email sent, per API call — suited for irregular load), tiered pricing by user count/feature set (“tiers”, e.g. Free/Pro/Enterprise), or flat rates with caps. These models let small projects start with low running costs and only pay more once they actually grow — a clear difference from earlier software licensing models, which often required high upfront investment, regardless of actual usage.
Vendor lock-in as a risk
The central long-term downside of SaaS is “vendor lock-in” — the more deeply a SaaS service is integrated into your own application (proprietary APIs, service-specific data formats, hardwired workflows), the more effort a later switch to another provider or a self-hosted alternative becomes. Experienced teams limit this risk through abstraction layers (e.g. your own payment interface, behind which Stripe or another provider could be interchangeably hidden) or by deliberately choosing services with standard export formats for your own data.