SaaS application development is much more than simply writing application code, then sending it to a public cloud provider.
It requires a continuous engineering effort to create secure tenant boundary systems and develop a shared infrastructure with recurring billing systems. In practice this means creating operational models able to withstand multiple organizations hammering the same resources without creating problems such as cross-tenant data leaks or performance collapse.
This technical guide details the components of database isolation, deployment lifecycle, and architectural models that must be in place in order to properly build a functional multitenant software product.
Key Takeaways: What Is SaaS Application Development?
SaaS is a business model and not a technology by itself. Microsoft and AWS both define their architectures in a manner that clarifies although SaaS is a delivery mechanism for software, multitenant architecture is the foundation that supports it. Both of these forms of software are interrelated with one another but cannot be interchanged.
Authentication does not equal separation of customers. A user can effectively authenticate into a SaaS platform and complete the authorization checks; however, if appropriate tenant contexts are not enforced independently on every database query, that user can potentially view another company’s data.
Your cost estimates will vary based on the definition of the minimum viable product (MVP). A minimal viable product built to test demand as a lean validation prototype will generally have a much lower cost than building a complete production MVP with live billing, monitoring and compliance security.
Microservices should not always be required right out of the gate. Starting with a modular monolith is frequently a common sense means of going to market by decreasing the overhead associated with tracing, networking, and deploying until such time as independent scalability becomes a requirement.
What is SaaS Application Development?
Many agencies provide very basic definitions stating that SaaS is simply a piece of software that runs in the cloud via a browser (no installation) and can be purchased as a subscription. However, while this gets you started on what SaaS is, it does not begin to scratch the surface of what is actually involved.
The way that a provider develops SaaS applications is centred around the fact that the provider accepts complete ownership for all aspects of SaaS application development. This includes the provider being responsible for ensuring availability of the system, providing continual updates to the software, providing secured access to customer information, managing billing, processing support tickets, and paying for infrastructure (i.e., server) costs on an ongoing monthly basis.
In contrast, creating a standard web application is relatively straightforward; you simply have to connect the frontend to a database. Whereas building a SaaS application is much more complex and requires significant engineering effort to create the underlying platform that will accommodate the operation of thousands of different accounts, all sharing the same resources and servers, in real-time.
Websites vs. Software Operations
Standard web applications are designed for individual users, while SaaS platforms are designed to serve an entire organisation. This difference drastically alters how back-end developers design and develop backend application code.
In the event that a standard web application no longer has access to the internet due to a server failure, the users will be forced to wait until a resolution is found. When a B2B SaaS application has a similar problem, there is a clear impact on the business and all of the associated SLAs will be breached and customers are entitled to a financial resolution. Because of this, the development process needs to account for failure boundaries, so when one component fails, the rest of the application is still functional.
The methods that you will use to deploy software will look completely different. For example, to deploy a simple update to a standard web application, a developer may simply push a change through the deployment tool. A SaaS application may require the use of zero-downtime deployments, backward-compatible database migrations, and feature flagging when deploying the latest changes to specific user segments without breaking the existing product for all other users.
The Multitenancy Architecture Foundation
Technical leaders need to separate the delivery model from the overall system design. Building a SaaS application takes advantage of a multitenancy architecture that permits a single application to be utilized by various groups at the same time.
Microsoft's architectural guidance makes it clear that some items shared among tenants can be components of the architecture itself, while other components can be completely separate from each other. You can also use a combination of shared and isolated resources to create a multitenant environment.
According to the AWS documentation, one of the more fundamental security tenets is that authentication only establishes who a user is, while authorization establishes what a user is permitted to do. Neither authentication nor authorization support tenant isolation out of the box; tenant isolation must be established through the application itself using tenant contexts to know what rows in the database and what resources in the cloud a request may access.
Core Tenancy Types and Database Isolation
The core of SaaS application architecture is not a choice between React, Node.js, Go, or Kubernetes; rather, the most critical choice is how to define the boundary lines between organizations.
It's essential to determine the following:
What constitutes a tenant?
How do you establish the data boundaries?
Who owns the billing account?
How do you define administrative privileges?
The Pool Tenancy Model
With the pool tenancy model, all customers utilize the same database instance and database schema, meaning all tables within that instance have a tenant_id column to determine which rows belong to which tenants.
Although this represents the lowest cost in terms of infrastructure since it's essentially a single database instance, the level of operational risk associated with this model is very high. The potential for cross-tenant data leaks is significant. When an engineer produces a query to a relational database and fails to write the necessary condition specifying 'tenant_id', every customer's data is returned and displayed on the user's screen.
The pool tenancy model also suffers from the "noisy neighbour" problem. Especially when a large enterprise executes a million-row data export, they will deplete the shared connection pool, slowing down the application's performance for all other paying customers.
Bridge Tenancy: Logical Schema Separation
The bridge tenancy structure is a middle ground for managing customer data. A shared database instance is used, with each tenant having its own isolated schema.
This offers tenants stronger logical isolation than a pool model. Accidental querying of other customers' data is much less likely, as the application must first create a connection to the desired customer's schema before executing any read or write operations.
The downside of this model is increased operational complexity. For example, adding a new column to a table can no longer be accomplished by executing a single database migration. Instead, this requires looping through and executing a migration on hundreds or potentially thousands of distinct schemas, ensuring that none of the executions fail during the process.
Silo Tenancy: Maximum Control
Silo tenancy separates the foundational resources of each tenant. Each tenant will have their own independent instance of a database and in some cases, independent application servers as well.
Silo tenancy provides tenants with maximum possible logical isolation and absolute control over blast radius. A tenant can experience a substantial database failure without affecting any other customers. In addition, strict compliance regulations such as HIPAA and PCI DSS encourage many organisations to use this model as a way of ensuring that sensitive data never resides in shared storage.
The impact of a single customer accounting model leads to significant server resource and administrative expenses. To be clear, there is absolutely no way to have an effective customer-based solution model without charging customers for baseline server resources, regardless of how little they may use the product. There are additional complexities in provisioning new accounts, and applying system-wide updates as well as having to go through the logistical difficulties of doing these type of things to all of your customers.
The Hybrid Tenancy Approach
Many companies eventually take a hybrid approach to the way that their platforms are packaged. In general, for small to mid-market customers, the platform defaults to utilizing shared pool architecture. For large enterprise customers, the service provider must build a dedicated instance of isolated infrastructure that provides the level of security that is being demanded of them.
In this case, the service provider can continue to provide the benefit of low-cost shared or multi-tenancy models to all of its customers, while still being able to take advantage of large enterprise contracts that require dedicated (and much more costly) database instances.
Data Isolation and Security Integration
The requirement for implementing isolated tenant data security is not simply a checkbox you check when building your application and launching it into production. It is something that you need to fully integrate and implement into your application's request flow from the time you start building it.
To clarify, there are significant architectural ramifications associated with implementing a project management solution. You need an established mechanism for controlling and allowing for the movement of data from your end-users, through your back-end processes, into your datastores.
The way that we enforce isolated tenant contexts in a production application is by requiring the identity provider to authenticate that user, and identify the user's organization. Immediately upon the user authenticating and logging into the application, the API layer must automatically assign their identity as the active tenant context. From that point on, the actions of that individual user are taken in a limited way to that one tenant context.
When the application queries the PostgreSQL database, the tenant context is passed as a part of that query. When background jobs are triggered by AWS EventBridge or by Kafka to do their processing, the same tenant context identification must be transmitted with those jobs. A monthly subscription charge in Stripe Billing maps directly back to its corresponding tenant's subscriptions file (Tenant Subscription File).
Preventing Cross-Tenant Data Leaks
The most common source of data loss/intrusion across tenants in a SaaS application occurs as a result of "dropping" the tenant context when developing the SaaS application.
An API endpoint that was built to create a report based on a project id must also verify that the provided project id actually belongs to the tenant that created the report request. If this validation does not occur as expected, an authenticated user can easily modify the project id that corresponds to their user session and request to download the private data of a competitor. Authentication worked. However, tenant isolation was completely compromised.
Control of implementation should be very strict and automated. The development team should build controls that rely on tenant scoped repository methods and composite indexes, including at minimum a composite index of tenant_id and created_at.
Using PostgreSQL? Consider implementing row-level security policies (RLS) in your database engine. This will prevent cross-tenant queries from being executed based on database engine requests made by the application code.
Every single action in the system should result in the generation of an audit log that includes both the actor id and the tenant id. This allows security teams to know who accessed what data.
The Process of SaaS Application Development
The SaaS development lifecycle is generally described by competitors as: validate the idea, design the user interface (UI), write the code, and launch. However, it fails to address significant technical considerations for maintaining a stable SaaS application.
Defining a Production MVP
Many founders and product managers mistake a prototype as a production MVP.
An MVP is a fast, inexpensive way to create a prototype for validation of an entire workflow. The minimum viable product (MVP) for production at a cost of $5,000 may take a total of three weeks to complete but cannot take credit card payments or handle secure information about customers.
The difference between an MVP for production and one for development (non-production) is that in order for an MVP for production to support real paying customers, there need to be an active security layer, an integrated billing system, a production-level database, a monitoring tool (such as Datadog or Grafana Cloud), and customer support available. Without well-defined data boundaries as well as defined data recovery protocols, there should not be a product MVP launched in SaaS application development.
Microservices vs. Modular Monolith
The assumption that all engineer teams developing SaaS applications will be using the microservices model from day one is a dangerous assumption leading to excessive costs. For a new product, there are many times where the modular monolith model is a better solution; indeed, it allows the code to remain in a single repository and enables easy local testing and easy deployment. In contrast, with the microservices model, you will experience several challenges such as complex networking latency, the need for distributed tracing, and the need to manage a large number of alerts.
The most logical approach for structuring the architecture is to only move to the microservices architecture model when there is a clear reason for needing it to operate independently or scale. First start with a clearly defined modular monolith and use appropriate design patterns for easy extraction of services later, as the customers' (business or consumer) needs arise in demand.
Pricing Models and Backend Complexity
Pricing models for SaaS products directly impact the complexity of the backend of the SaaS product. Flat rate pricing plans make it much easier to develop and implement on a backend level; whereas, usage-based pricing may increase the overall infrastructure requirements to provide the service provider (SaaS provider) with the tools and capabilities needed to collect and process usage metrics and charge customers accordingly.
If you choose to charge your customers based on the volume of actions taken, you must implement high-volume event measurement systems and establish a means to track each customer's actions specifically. To implement this, you will require a messaging queue, an accurate invoice reconciliation process, and the appropriate storage management practices in place to prevent your billing log from becoming too large and crashing your production database.
AI Features and Custom Retrieval
AI features also add complexity in the background of SaaS application development. For instance, if you are developing a SaaS application that offers AI-based search capabilities, you cannot merely query one of the commercially available large language models for your tenant's search queries. Instead, you need to create custom retrieval logic for each tenant using vector databases like Qdrant or pgvector. This enables your AI to only search the documents associated with a single tenant at a time.
Cloud Budgeting, Timelines, and Product Metrics
SaaS applications' budgets based solely on universal pricing tags will quickly lead to financial loss. The actual cost of developing your SaaS application will depend solely on the scope of work, tenancy model, and anticipated growth.
Development Timelines and Funding Allocations
Custom, lean MVPs are reported to cost between $15,000 - $45,000 and take 8-12 weeks to develop. For production MVPs that are comprehensive and secure, costs can be anywhere between $30,000 and $80,000, with a timeline of 2-4 months.
The costs can vary immediately due to the various drivers of effort. For example, RBAC can extend the timeline, while integrating with multiple APIs or necessitating a mobile application can escalate the price.
Compliance is another major financial drain, as getting ready for SOC 2 Type II and GDPR requires a total redesign of the schema (data structure), extensive audit trails, complex account deletion workflows, and costly external audits.
Post-Launch Metrics and Observability
The technical piece of validating product effectiveness is the measurement of observables, metrics and results after the product has launched.
During validation, customer feedback is monitored for the following metrics: translated to signed-up customers, frequency of problems; during activation the primary metric is time from download to the first use and value realization. After the use of a product reaches a normal intake level, you survive by net revenue retention, logo churn and ARPA.
Unless you are engineering teams to collect systems observability completely differently from standard website developers in SaaS application development, you are wasting your time. You should be monitoring the same types of systems observables as other systems that use web applications. Error statistics, 95th percentile latency, queue delays and failed jobs are some of the observables that you will track. It is crucial that all observability telemetry is segmented by tenant. If the CPU of your database spikes to 99 percent, the engineering team must be able to check their dashboard and pinpoint which tenant is executing the unwanted queries that are causing the spike.
The Ongoing Reality of Software Operations
Cloud billings are always due. If your backend architecture cannot distinguish tenant data and accurately calculate resource consumption per tenant, your cloud expenses will decimate your profitability long before customer churn. Move beyond the approach of simply developing software like you are hosting a website, and put serious thought into engineering the database boundaries that are required to achieve true organizational scale.
