Building a SaaS for 20,000 Lawyers: The Architectural Trade-offs

Building a SaaS for 20,000 Lawyers: The Architectural Trade-offs

Designing a multi-tenant Law-Tech platform on a single VPS isn't about using the trendiest stack. It’s about fighting Over-Engineering and making smart trade-offs. Here is how we balanced absolute data security, high performance, and bootstrap budget:

1. Security vs. Infrastructure Cost
   The Dilemma: Law firms demand total data isolation. Creating separate servers per client (Single-Tenant) is safe but destroys our bootstrap budget.

The Trade-off: We chose PostgreSQL Schema-per-Tenant. Every firm gets its own isolated schema but shares one Database Cluster inside Docker. We get Enterprise-grade isolation at a fraction of the hosting cost.

2. Performance vs. Resource Limits
   The Dilemma: Lawyers search through massive PDFs/DOCX files daily. Normally, this requires Elasticsearch, which easily consumes 4–8GB of RAM—too heavy for a lean VPS.

The Trade-off: We built an asynchronous Background Job using Node.js Worker Threads. When a file is uploaded, the main thread instantly returns a success response. In the background, the worker extracts text and indexes it straight into Postgres using tsvector and GIN Index. We achieved instant Full-Text Search with zero extra RAM overhead.

3. Complexity vs. "What's Necessary" (The Caching Choice)
   The Dilemma: Should we add Redis for caching from Day 1?

The Trade-off: No. With 20 initial users and a hard cap of 20,000 nationwide, Postgres Read/Write split (Master-Replica) can easily handle the load. Adding Redis early introduces the nightmare of Cache Invalidation—where a lawyer might see outdated, risky financial data. We chose Next.js client-side caching and Cloudflare CDN instead.

The Golden Rule: Good architecture is not about how many tools you can add; it's about how much you can accomplish with what you already have. Keep it lean until it hurts.