Multi-Tenancy: The Core SaaS Architectural Decision
Multi-tenancy is the property of serving multiple customers (tenants) from a shared infrastructure. The primary architectural decision in SaaS is how to implement tenant isolation: how do you ensure that each customer's data is separated from other customers' data, that one customer cannot access another's data even in the event of a bug, and that one customer's usage does not degrade performance for others. There are three main models. In the shared database model, all tenants share a single database schema, with a tenant_id column in every table distinguishing one tenant's data from another. This is the simplest model and appropriate for most early-stage SaaS products. In the schema-per-tenant model, each tenant gets their own schema within a shared database. This provides stronger logical isolation and makes per-tenant operations (backup, migration, deletion) cleaner. In the database-per-tenant model, each tenant gets a completely separate database. This provides the strongest isolation and is necessary for enterprise customers with data residency requirements, but adds significant operational complexity. For most AI MVPs, the shared database model with row-level tenant isolation is the right starting point.
Authentication and Identity in SaaS
Authentication in a SaaS product must handle user identity within the context of a tenant: not just who you are, but which organisation you belong to and what you are authorised to do within that organisation. This requires a multi-layer identity model. At the user level, authentication confirms who the user is, typically via email and password, social login (Google, Microsoft), or magic link. At the organisation level, a user belongs to one or more tenants. At the permission level, a user has a role within a tenant (admin, member, viewer) that determines what they can do. Libraries and services like Clerk, Auth.js, or Supabase Auth handle the user authentication layer. The organisation membership and role management layer typically requires custom implementation that ties into your data model. For AI SaaS products, role-based access is especially important because you may want to restrict which users can access sensitive AI features, trigger expensive operations, or export data.
Subscription Billing Integration
Subscription billing is a core component of SaaS architecture that is often underestimated in complexity. You need to handle plan creation, trial periods, subscription upgrades and downgrades, proration, failed payment retries, invoice generation, and tax handling for different jurisdictions. Building this from scratch is genuinely complex and error-prone. Using Stripe for billing, combined with a library like Stripe's official SDKs or a wrapper like Lemon Squeezy, is the standard approach for UK SaaS products. The billing system must integrate with your feature entitlement system: a customer on the Starter plan should not be able to access features reserved for the Pro plan. This entitlement layer needs to be checked at the API level, not just in the UI, to prevent bypass. For AI SaaS products with usage-based pricing (per-API-call, per-token, per-document), billing integration is more complex because you need to track usage per tenant, aggregate it for billing purposes, and handle metering accurately. Stripe's usage-based billing API supports this but requires careful implementation.
Data Architecture for AI SaaS
AI SaaS products have data architecture requirements that differ from traditional SaaS. In addition to the standard relational database for user data, product data, and billing information, an AI SaaS product typically needs a vector database for storing embeddings and enabling semantic search, a document store or object storage for user-uploaded files that will be processed by AI, and an audit log for tracking AI-generated outputs and decisions. The data architecture must respect tenant isolation at every layer. Your vector database (Pinecone, Weaviate, or pgvector in PostgreSQL) must partition embeddings by tenant so that a semantic search for one tenant cannot surface results from another. Your document store must enforce tenant-scoped access control on every file. Your audit log must capture the tenant context for every AI inference call. For regulated industries such as fintech (FCA oversight) or healthtech (NHS Digital and MHRA requirements), these audit logs may be a compliance requirement rather than just a nice-to-have.
LLM Cost Attribution and Usage Monitoring
One architectural challenge unique to AI SaaS is LLM API cost attribution. When your product makes calls to OpenAI, Anthropic, or Google AI on behalf of many tenants, you need to track which tenant is responsible for which costs, particularly if you are offering usage-based pricing or need to monitor for unusual usage patterns. Most LLM APIs support metadata tagging on requests (user_id, session_id) that helps with attribution, but aggregating this data into per-tenant usage reports requires a logging and aggregation layer in your own infrastructure. Beyond billing, usage monitoring matters for cost control. A single tenant making unusually high-volume requests could run up significant LLM API costs if not rate-limited. Building per-tenant rate limits and cost alerts into your AI SaaS architecture from the start prevents bill shock and ensures fair resource allocation across your customer base.
GDPR, UK GDPR, and AI SaaS Compliance
SaaS products processing personal data of UK or EU residents must comply with UK GDPR and EU GDPR respectively. For AI SaaS, this creates specific obligations. Each enterprise customer is likely to be both a data controller (deciding what data to process) and, through using your product, causing you to process that data as a data processor. This relationship requires a Data Processing Agreement (DPA) between you and each enterprise customer. For AI SaaS products that process personal data with LLMs, the DPA with the LLM provider (OpenAI, Anthropic) also needs to be in place. Data minimisation means you should only send to the LLM the data necessary for the task. If a user uploads a document containing personal data, consider whether you can strip or pseudonymise PII before it reaches the LLM. For UK products, the ICO (Information Commissioner's Office) provides guidance on AI and data protection. SpeedMVPs builds GDPR-aware SaaS architectures with DPA workflows, tenant data isolation, and right-to-erasure capability as standard.