The most common SaaS-architecture mistake I see is treating scalability as a future problem. "We'll worry about scale when we have users" is a reasonable thing to say, and it's also a slow rewrite waiting to happen. Scale isn't something you do; it's a habit you build.
The habit, in the simplest form: keep things separated that you'd want to scale separately. Auth from billing. Email from search. Background jobs from request handlers. You don't need a full microservice architecture from day one — you need clean boundaries that let you split when the time comes.
Most early-stage SaaS hits its first wall not at user count but at queue depth. Something asynchronous starts piling up — usually email, exports, or background jobs — and the system goes from "fine" to "down" in an afternoon. The cheap fix is a real queue from day one. Redis, BullMQ, even an SQS table. Whatever your stack supports.
Database choices age faster than you think. The biggest mistake I made on Plans was a single Postgres instance with lazy indexing in the first few months. It worked beautifully until it didn't, and the migration to a saner pattern took a week I didn't have. The cost of getting indexing and read-replicas right early is small. The cost of doing it under pressure is enormous.
Caching is a senior decision. Most teams that hit scale problems also have inappropriate caching — either too aggressive (showing stale data) or absent (hammering the database). The right pattern is rarely uniform: some endpoints need fresh data, some can be five minutes old, a few can be cached for a day. Decide on a per-endpoint basis, write it down, and revisit when the workload changes.
The unfashionable truth: most SaaS scaling problems are actually code-quality problems. A slow N+1 query that becomes a 30-second page load at 1,000 users could have been fixed in fifteen minutes during the build. The reason teams hit scale walls isn't volume; it's accumulated debt that volume reveals.
What I'd build into any new SaaS today: a clean separation of concerns from day one, proper queues for anything that doesn't need to happen in-request, indexed databases with explicit read patterns, per-endpoint caching, and a real observability stack (Datadog, Honeycomb, even just OpenTelemetry into something). None of this slows you down. All of it speeds up the version of your business that exists in two years.
The thing I won't do anymore: premature microservices. I've seen four early-stage teams split their monolith too early and regret it. Your monolith isn't your bottleneck until your team is big enough to need true ownership boundaries — and that's almost never at the user-count when scale becomes interesting.