Testing for multi-tenant B2B SaaS.
Your largest customer, your next launch and your weekly release all stress the platform differently. I test for tenant isolation, noisy neighbours, release regressions and scale — before your customers find the gaps.
Where multi-tenant platforms break
Tenant isolation
Can tenant A read, modify or enumerate tenant B's objects through any endpoint, export, search index or file URL? Systematic cross-tenant checks (OWASP API1: BOLA) across the whole API surface.
Noisy neighbour
One tenant runs a 2-million-row import while others use the app. Skewed, per-tenant load tests show whether rate limits, queues and connection pools keep everyone else within SLO.
Release regression
A risk-based regression suite for critical journeys (sign-up, billing, permissions, integrations), automated in CI so every release is checked the same way.
API contracts
Public and partner APIs checked against the OpenAPI spec, breaking-change detection in pull requests, and consumer contracts between internal services.
Scaling before launches
Autoscaling lag, cold starts, database connection limits and cache warm-up tested with ramp and spike profiles before a launch, migration or big-customer onboarding.
Enterprise readiness
Test evidence your customers' security and procurement teams ask for: documented test strategy, regression coverage, performance baselines.
A typical first engagement
Most SaaS teams start with one of three questions. Each maps to a fixed-scope project.
- “Will it hold for the launch?” → load, spike and soak tests with a capacity statement.
- “Can one customer see another's data?” → tenant isolation and API security review.
- “Why do our releases keep breaking things?” → regression suite and CI quality gates.
Launch, migration or big customer coming up?
Book 20 minutes. You leave with the three highest-risk areas to test first.