Stop Over-Engineering for Scale You Don't Have
We've consulted on the architecture of about 20 SaaS products, and the most common mistake is over-engineering. Startups with zero users building Kubernetes clusters with 15 microservices, event sourcing, and CQRS. That's not engineering — that's resume-driven development. At 0-100K users, your architecture should optimize for speed of iteration, not theoretical scale.
Here are the decisions that actually matter at this stage, based on what we've seen work and fail across those 20 products.
The Monolith Is Your Friend
Start with a monolith. Not a microservices architecture, not a modular monolith, not "microservices but deployed together." A plain old monolith. One codebase, one deployment, one database. We've seen too many early-stage startups waste 3-6 months building microservices infrastructure that they didn't need for another two years.
Our default SaaS stack: Next.js (frontend + API routes in one codebase), PostgreSQL on Supabase or RDS, Redis for caching and job queues, and Vercel or AWS for hosting. This stack handles 100K users comfortably. Our monitoring product uptimeMonit runs on essentially this stack and handles thousands of concurrent connections without breaking a sweat.
When should you start breaking the monolith? When deploy times exceed 15 minutes, when teams are stepping on each other's code regularly, or when you have a specific component that needs to scale independently (like a data processing pipeline). Not before.
Multi-Tenancy: Get It Right Early
Multi-tenancy is the one architectural decision you should make correctly from day one, because retrofitting it later is incredibly painful. We've helped three startups migrate from single-tenant to multi-tenant architectures, and each migration took 3-5 months. If they'd started multi-tenant, it would have been zero additional effort.
For most SaaS products at this stage, we recommend shared database with Row-Level Security (RLS). Every table has a tenant_id column, and a PostgreSQL RLS policy ensures that queries only return rows belonging to the current tenant. Supabase makes this particularly easy with built-in RLS policies. You get the cost efficiency of a single database with the data isolation of separate tenants.
Authentication: Don't Build It Yourself
We've seen startups spend 6-8 weeks building custom authentication. JWT generation, email verification, password reset, OAuth integration, session management, brute-force protection. All of this is solved by Auth0, Clerk, Supabase Auth, or NextAuth.js. Use one of them. We prefer Clerk for SaaS products (excellent multi-tenant support and pre-built UI components) or Supabase Auth for simpler applications.
The one exception: if you're building for the Indian enterprise market and need SAML SSO for your customers' IT departments. Most auth providers support SAML, but the configuration UX varies. Clerk's SAML setup is the smoothest we've used. WorkOS is another good option if SAML is your primary concern.
The Payment Stack
For Indian SaaS: Razorpay for payment processing, with their subscription billing product. It supports UPI autopay, card recurring, and emandate — all essential for the Indian market. For global SaaS: Stripe, no question. Their subscription billing, usage metering, and customer portal are years ahead of alternatives. We typically integrate both: Razorpay for Indian customers, Stripe for international. The billing logic sits behind an abstraction layer that normalizes events from both providers.
What To Defer
Things that don't matter at 0-100K users but will consume months if you pursue them now: microservices, Kubernetes, custom CI/CD pipelines (use Vercel or Railway), custom monitoring (use Sentry + simple uptime monitoring), and elaborate caching strategies (add Redis caching when you actually see database bottlenecks, not before). Ship the product. Get users. Optimize when you have data showing what actually needs optimization.