Frequently Asked Questions
What is multi-tenancy and why does it matter for SaaS architecture?
Multi-tenancy means a single deployed system serves multiple customers (tenants), with data isolation between them. There are three main approaches: shared schema (all customers in the same tables, filtered by tenant_id), schema-per-tenant (separate schema per customer in the same database), and database-per-tenant (separate database per customer). The choice determines infrastructure cost per customer, migration complexity, isolation strength and compliance posture. Shared schema is cost-efficient but requires rigorous access control. Database-per-tenant is expensive but offers the strongest isolation.
How do we architect billing for a SaaS product?
Stripe is the standard starting point — Stripe Subscriptions for seat-based billing, Stripe Billing with meters for usage-based pricing. The billing architecture must handle: subscription lifecycle (trial, active, past due, cancelled, paused), proration when customers upgrade or downgrade mid-cycle, usage metering with real-time or end-of-period aggregation, dunning (automatic retry and customer notification for failed payments), and pricing model flexibility so you can change pricing tiers without a rebuild.
How do we implement SSO for enterprise customers?
Enterprise SSO uses SAML 2.0 or OIDC. SAML is the older standard, widely supported by corporate identity providers (Okta, Azure AD, Google Workspace). OIDC is the modern standard. Most enterprise SaaS products support both. Implementation: tenant-level IdP configuration, SAML assertion validation (Audience restriction, signature verification), JIT (just-in-time) user provisioning on first login, attribute mapping from IdP claims to your user model, and SCIM for automated user provisioning and deprovisioning.
When should we implement usage-based pricing vs seats?
Seat-based pricing is simpler to implement and easier for customers to predict. Usage-based pricing aligns cost with value — customers pay more as they get more value. Choose usage-based when: your value metric is clearly tied to a measurable action (API calls, records processed, emails sent), your target customers have highly variable usage patterns, or you want to remove adoption friction for new customers. Usage-based requires real-time metering infrastructure and more complex billing logic.
What does SOC 2 compliance require technically?
SOC 2 Type II tests controls over a period (typically 6-12 months). Technical controls required: access management (least privilege, MFA, access reviews), change management (code review, deployment controls, audit trail), availability monitoring (uptime SLA evidence, incident management), logical access controls (authentication, authorisation, session management), data protection (encryption at rest and transit, backup and recovery), and vendor risk management. Building these controls into the architecture from day one is faster than retrofitting after a gap analysis.
How do we handle API versioning in a SaaS product?
URL versioning (/v1, /v2) is the most common approach for SaaS APIs — explicit, easy to route, and allows breaking changes with a migration period. The policy must include: what constitutes a breaking change (removing fields, changing types, removing endpoints), minimum deprecation notice period (typically 6-12 months), sunset headers on deprecated endpoints, and a clear migration guide for each breaking change. Maintain previous versions long enough that enterprise customers with slow procurement cycles can upgrade.
How do we build webhook delivery that enterprise customers can rely on?
Reliable webhook delivery requires: persistent event queue (not in-memory), at-least-once delivery semantics with idempotency keys, retry with exponential backoff on failure (typically 3-5 retries over 24 hours), per-endpoint delivery logs accessible to customers, configurable delivery timeout, HMAC signature verification payload so customers can validate authenticity, and event ordering guarantees where required. Webhook delivery failures that silently lose events are an enterprise deal-breaker.
How do we approach GDPR compliance for a SaaS product?
GDPR compliance for SaaS requires: a data processing agreement (DPA) template for customer execution, data residency controls (EU customer data stays in EU regions), right-to-deletion implementation that removes all PII across all data stores (including backups and logs), data portability (export of customer data on request), consent management for any direct marketing, and a data breach notification procedure. Technical implementation: tenant-level data residency configuration, deletion workflows that cascade across all storage systems, and audit trails of data access.
What is SCIM provisioning and which customers need it?
SCIM (System for Cross-domain Identity Management) allows enterprise customers to automatically provision and deprovision users in your SaaS product from their identity provider (Okta, Azure AD). When a new employee joins, they are automatically added to your product. When they leave, they are deprovisioned — preventing orphaned accounts. Enterprise security teams often require SCIM before signing. Implementation requires a /scim/v2 endpoint supporting User and Group resources with CRUD operations, mapped to your user management model.
How long does a SaaS product take to build?
A production SaaS product with multi-tenancy, billing, authentication, core features, API and basic observability takes 16-28 weeks from architecture to launch. Enterprise features (SSO, SCIM, audit logs, SOC 2 controls) add 6-10 weeks. Products with complex data models, custom workflow builders or marketplace components take longer. We deliver in two-week sprint cycles with staging environment releases at each milestone.
