The most common SaaS architecture mistake I run into is treating scale as a problem for later. Saying you'll worry about it once you have users is a perfectly reasonable thing to say, and it's also how you end up doing a rewrite you didn't budget for.
The simplest version of getting it right is to keep things separate that you'd want to scale separately. Auth away from billing. Email away from search. Background jobs away from request handling. You don't need microservices on day one. You need boundaries clean enough that you can split things when you have to.
Most early-stage SaaS hits its first wall on queue depth rather than user count. Something asynchronous starts backing up, usually email or exports or background jobs, and the system goes from fine to down over an afternoon. A real queue from the start is cheap insurance. Redis, BullMQ, even a table in SQS. Whatever your stack already supports.
Database decisions age faster than you expect. The worst call I made on Plans was running a single Postgres instance with lazy indexing for the first few months. It was fine right up until it wasn't, and migrating to something sensible took a week I didn't have. Getting indexing and read replicas right early costs very little. Doing it under pressure costs a lot.
Caching is where I'd want someone senior making the call. Most teams with scale problems also have caching that's either too aggressive and showing stale data, or missing entirely and hammering the database. It's rarely one setting for everything. Some endpoints need fresh data, some are fine at five minutes old, a few could be cached for a day. Decide per endpoint, write down why, and revisit it when the workload changes.
The less glamorous truth is that a lot of scaling problems are really code quality problems. An N+1 query that turns into a thirty-second page load at a thousand users could have been fixed in fifteen minutes during the build. Volume doesn't usually cause the wall, it just makes the existing debt visible.
If I were starting something new today I'd want separated concerns from the beginning, proper queues for anything that doesn't have to happen inside the request, indexed databases with read patterns someone has actually thought about, caching decided per endpoint, and real observability. Datadog, Honeycomb, or just OpenTelemetry pointed somewhere. None of that slows the early work down much and all of it helps the version of the business that exists in two years.
The one thing I won't do anymore is split a monolith early. I've watched four early-stage teams do it and regret it. Your monolith isn't the bottleneck until your team is big enough to need real ownership boundaries, and that's almost never at the point where scale gets interesting.