The premature optimisation trap
Growing pains
Your SaaS finally has traction. Pages that loaded instantly now take seconds, a big customer wants SSO, and the database migration you have been avoiding is now blocking every new feature.
Most SaaS MVPs are not killed by scaling problems: they are killed by not finding customers. Spending six months building a microservices architecture before the first paying user is not prudent engineering; it is a way to delay the hard conversation about whether the product has a market.
Build the simplest thing that could work. Then instrument it well enough to see where it actually breaks. Scale the parts that break.
Decisions that age badly if you get them wrong early
Tenant isolation model
Migrating from a single-schema multi-tenant database to a per-schema or per-database model after you have enterprise customers asking for data isolation is painful. Decide on your tenant model before you have data, not after.
Auth system
Replacing an auth system in a running production application is one of the most disruptive refactors you can do. JWT, OAuth provider (Auth0/Clerk/Supabase Auth), or your own session model: pick one and do it properly from the start.
Event sourcing vs CRUD
If your product will need audit trails, time-travel queries, or complex undo functionality, retrofitting event sourcing onto a CRUD system is expensive. If it will not, adding event sourcing upfront is unnecessary complexity.
API contract
Public APIs you change later create breakage for every consumer. If there is any chance your API will be consumed by third-party integrations or a mobile app, add a version prefix from the start.
Is your SaaS slowing down as it grows?
Get a free consultationDecisions that are fine to defer
Microservices. A well-structured monolith handles remarkable amounts of traffic and teams. Extract services when you have a clear bounded context that needs to scale independently or be deployed separately. Not before.
Caching layer. Add Redis when you have a slow query or a hot endpoint. Not as a precaution.
Search infrastructure. Elasticsearch and Typesense are excellent. They are also operational overhead. Use database full-text search until it is actually too slow.
Message queues. Background job processing can run as a simple in-process queue until job volume or reliability requirements justify Kafka or SQS. For most SaaS products, BullMQ on Redis is sufficient for a long time.
Decide now or safely defer?
A simple way to sort architecture decisions while you are still small.
Ifit affects how tenant data is separated
ThenDecide now
Ifit affects authentication and roles
ThenDecide now
Ifit is about caching or a CDN
ThenDefer until metrics say so
Ifit is about microservices
ThenDefer; a well-structured monolith scales far
Ifit is about background jobs and queues
ThenAdd as soon as work takes longer than a request
Key takeaway
Get data isolation, auth, and migrations right early. Almost everything else can wait for real usage data.
The one thing that ages worst of all
No tests. A fast MVP with no tests creates a codebase where every change risks a regression and every refactor is a risk. You will not feel the pain at 100 users. You will feel it badly at 10,000 users when you need to ship fast and cannot.
Write integration tests for your critical paths from the first sprint. Not 100% coverage, just the paths that would hurt users if they broke. That discipline compounds.
Frequently Asked Questions
Written by
Sachin Patel
Product & Engineering
