Your SaaS hit 1,000 users, and everything slowed down. Queries take 8 seconds. Support tickets pile up. Users churn. I had to turn to SaaS product development services to rebuild three products after making these mistakes.
Here’s what kills user retention before you even notice the revenue drop.
Multi-Tenancy Done Wrong: The 40% Resource Waste
Most founders choose between full isolation (each tenant gets dedicated infrastructure) or full sharing (everyone uses one database). Both approaches waste resources.
The mistake: Tenant A uses 2% of resources but pays for dedicated infrastructure. OR 100 tenants share one database, and one heavy user crashes everyone.
Not all resources need the same tenancy model. Compute can be shared while storage stays separate. AWS runs SaaS environments where some services share resources while others don’t.
How to fix it:
- Use hybrid tenancy (shared compute, isolated storage per tenant);
- Implement shuffle sharding to limit blast radius;
- Sharded databases let you confine tenant data to single shards, reducing rows searched and improving per-tenant performance.
The middle ground saves money and protects users. One customer’s analytics query shouldn’t freeze everyone else.
Database Sharding Without a Plan: When Scale Makes Things Slower
Sharding by the wrong key destroys performance at scale.
Customers grow unevenly, one shard gets overloaded, and you need to migrate tenants between shards while the business runs 24/7. Every 100ms of database latency reduces customer engagement by 7%. When multiple shards fulfill a single query, network and CPU overhead add up fast.
The numbers that matter:
Salesforce handles 150+ billion transactions daily using intelligent tenant-based sharding. They didn’t get there by guessing.
How to fix it:
- Shard by tenant_id to keep all tenant data on one shard;
- Avoid frequent-update columns as shard keys (moves between shards destroy performance);
- Design so joins stay within single shards; crossing shards runs queries serially, not parallel.
Cross-shard queries kill performance. If you need data from three shards, you’re making three separate database calls. The network latency alone adds 50-100ms before you touch any actual data.
The JWT Session Trap: Security Theater That Leaks Credentials
JWTs became popular because “stateless is better.” That’s not always true.
The security problem:
Compromised signing keys let attackers hijack any account, and you can’t revoke JWTs without maintaining state anyway. Storing JWTs in localStorage means XSS through any dependency exfiltrates every active session trivially.
The performance lie:
Modern caches (Redis, DynamoDB) achieve 1-5ms lookup times; JWT validation takes CPU cycles too, no free lunch. Most web frameworks cryptographically sign session cookies automatically; you already have JWT’s signature benefit without the downsides.
When to use JWTs:
- SSO across multiple domains
- External API authorization
- Cross-domain authentication
- Mobile apps without cookie support
For web apps, use this instead:
- httpOnly session cookies (XSS can’t access them)
- Server-side sessions in Redis or your cache layer
- Refresh tokens with short-lived access tokens if you must use JWTs
Reserve JWTs for true stateless needs. Your standard web app doesn’t need them.
Premature Microservices
Starting with microservices for a pre-revenue MVP multiplies costs and complexity.
The real numbers:
Each microservice needs its own test suite, deployment pipeline, hosting infrastructure, and monitoring; costs multiply exponentially. Monolith on $200/month instance vs 10 microservices at $50 each equals $500/month, plus $100 for API gateway, $150 for logging, equals $750/month (3.75x increase).
Network calls between microservices add a minimum of 24ms latency per hop. Make four internal service calls to render one page? That’s 96ms before you do any actual work.
The cautionary tale:
Amazon Prime Video monitoring reduced infrastructure costs by 90% by moving from microservices back to a monolith. They’re Amazon. If they benefit from consolidation, you probably do too.
Decision framework:
- Start with a modular monolith (organized code, single deployment).
- Extract microservices only when specific services need independent scaling.
- Microservices become cost-effective when you can scale individual services horizontally on demand, not the whole app.
Microservices make sense when different parts of your system scale unevenly. Payment processing spikes at month-end, reporting runs overnight, and user auth is constant. Until you hit that point, you’re just paying more to move slower.
Ignoring The Noisy Neighbor Problem: How One Customer Ruins Everyone’s Day
In a pooled architecture, one tenant can destroy performance for everyone else.
What happens:
An enterprise customer runs an analytics query that locks tables for 45 seconds while 200 small customers wait. Slow queries trigger connection pool exhaustion. New requests queue. Health checks fail. Orchestrator restarts service. Everyone goes down.
The cascade effect you don’t see coming:
Your monitoring shows CPU at 40% and memory at 60%. Everything looks fine. Then one customer imports 500,000 records, and your connection pool maxes out in 3 seconds.
How to fix it:
- Implement query timeouts (kill runaway queries before they spread);
- Use connection pooling with per-tenant limits;
- Shuffle sharding distributes tenants across shards so one problematic tenant impacts fewer others;
- Consider tier-based routing (free tier goes to cheaper, rate-limited infrastructure).
Slack isolates large workspaces on dedicated shards while small teams share resources. This way, one customer shouldn’t be able to take down your entire platform.
Real-world mitigation:
Set hard limits on query execution time (5 seconds for web requests, 30 seconds for background jobs). Log which tenant triggered the timeout. If one customer hits limits repeatedly, move them to isolated infrastructure before they damage your reputation.
What To Do Next
These mistakes compound. Bad multi-tenancy leads to sharding problems, which hit cross-shard query issues, tempt you toward microservices, and multiply your infrastructure costs.
Start with hybrid tenancy, defer sharding until you need it, use session cookies for web apps, and build a modular monolith. Scale only what’s breaking.
