We have built SaaS products for clinic chains in Lahore, referral platforms in the US, dental data systems in Sweden, and event management platforms in Texas. The tech stacks differ. The business contexts differ. But the architecture mistakes are almost identical every time.
These are not mistakes made by incompetent teams. They are made by smart people who are optimizing for the wrong constraints — usually moving fast at the expense of foundations that are genuinely cheap to get right early and genuinely expensive to fix later.
1. Building multi-tenancy as an afterthought
The most common and most painful mistake. A team builds a great single-tenant application, gets their first client, then tries to add a second. Suddenly the data model, the authentication system, the file storage, the background jobs — everything needs to be refactored to be tenant-aware.
Multi-tenancy is a day-one architectural decision. Whether you use separate databases per tenant, a shared database with tenant_id columns, or a hybrid — that decision shapes everything. Make it on day one, even if you have a single client in mind.
2. Ignoring database indexing until performance degrades
PostgreSQL and SQL Server are forgiving at small scale. A missing index on a 10,000 row table is imperceptible. On a 2 million row table it is a 4-second query that your users feel every time they open a screen.
Real Case
In a clinic management system we inherited, the patient search query was doing a full table scan on 800,000 records. Adding a composite index on (clinic_id, name, phone) reduced query time from 3.2 seconds to 11 milliseconds. No code change required.
3. Storing everything in a single monolithic database table
The "users" table that grows to contain billing information, application preferences, audit fields, social login tokens, and notification settings is a sign that the data model was never designed — it was accumulated. Schema design matters and the cost of redesigning it at scale is high.
4. No background job infrastructure from the start
Email sending, report generation, third-party API calls, AI processing — all of these belong in background jobs, not in API request handlers. Every synchronous operation that doesn't need to block the user response should be async. The infrastructure for this (a queue, a worker process, retry logic) is cheap to set up at the start and expensive to bolt on later.
- →Use BullMQ or similar for Node.js background processing
- →Every job should be idempotent — safe to run twice with the same result
- →Build dead-letter queues from day one so failed jobs are never silently lost
- →Monitor job queue depth as a core business metric — a growing queue is an early warning system
5. Treating authentication as a solved problem without understanding it
Using NextAuth or Clerk or Supabase Auth is fine. Using them without understanding session management, token refresh, role-based access control scope, and how they interact with your specific data model is where problems start.
We have seen critical authorization bugs — where a user in organization A could access data belonging to organization B — shipped to production on platforms using reputable auth libraries. The library was correct. The integration was wrong.
Authentication is not a library. It is a security posture. Understand it before you ship it.