Scaling SaaS without stalling delivery
Scaling SaaS past Series A breaks two things at once: the system, which starts to struggle under bigger customers and more data, and the team, which ships less even as it grows. The fixes interact – the architecture shapes how fast the team can move, and team structure shapes the architecture.
This is the stage I work with most: growth-stage SaaS where delivery has slowed and architecture decisions now affect revenue. I embed with the team, ship alongside it, and start with a two-week sprint.
Symptoms that you’ve hit the growth-stage wall
- Features that took two weeks a year ago take two months, and nobody can say exactly why.
- Enterprise deals stall on requirements you don’t meet yet – SSO, audit logs, data residency, an uptime commitment.
- Your biggest customer’s data is ten times anyone else’s, and their dashboard times out.
- Incidents cluster around deploys, so the team deploys less often, so each deploy is bigger and riskier.
- The two engineers who understand the core system are in every meeting and review every change.
- Cloud spend is growing faster than revenue.
How to scale a SaaS application, in the order that pays off
Teams under pressure tend to reach for the biggest change first – microservices, a new database, a rewrite. The order below is cheaper and almost always gets further:
- Measure. Put real numbers on p95 latency by endpoint, slowest queries, queue depth, and error rate per tenant. Without this you’re guessing.
- Fix the database first. Missing indexes, N+1 queries, unbounded queries on large tenants, and connection exhaustion explain most SaaS slowdowns. A connection pooler in front of PostgreSQL and a pass through the slow query log are often the highest-return week of the year. See PostgreSQL performance tuning.
- Move work off the request path. Exports, emails, webhooks and recalculations belong in background jobs, with separate worker pools so a backlog in one doesn’t starve the others.
- Cache deliberately. Cache computed results with a clear invalidation rule, not whole pages by default. The caching strategy guide covers the trade-offs.
- Isolate noisy tenants. Per-tenant rate limits and, for the largest customers, dedicated workers or databases.
- Only then split services – and only where a component has a genuinely different scaling or deployment profile.
SaaS scalability is a team problem too
A codebase that eight engineers could share informally won’t work for twenty-five. The usual fix isn’t microservices; it’s clear module boundaries inside the monolith, with an owning team for each. A modular monolith gives you most of the independence of services without the network calls, distributed transactions and on-call burden.
On the delivery side, I look at lead time from commit to production, deploy frequency, and how often deploys cause incidents – the DORA metrics. Smaller, more frequent deploys behind feature flags are nearly always safer than fewer, bigger ones, even though it feels the other way round.
Where architecture starts to affect revenue
At this stage technical decisions show up in the sales pipeline. Enterprise customers ask for SSO, granular permissions, audit logs and a data processing agreement. Moving upmarket can mean per-customer data isolation or regional hosting. Pricing changes – seats to usage, for example – can require billing data your system doesn’t record.
I help sequence this work against the roadmap so that the platform changes land just before the deals that need them, not six months after. That’s often where a technical roadmap exercise starts.
What I bring to a growth-stage team
I was an early engineer at Yola while it scaled from 10K to 11M users, building the framework, payment platform and core APIs. I architected the backend of BLU Loyalty, an enterprise loyalty platform serving 9M users across the UAE for one of the region’s largest retail groups. More recently I stepped in at Feenstra Group when a platform built for a single client had reached its scalability limits.
In practice that means I’ll be in your slow query log and your pull requests in week one, not producing a strategy deck in week six.
When you don’t need me
If your system is fast enough and incidents are rare, but you simply need more engineers, hire them. If you already have a strong VP Engineering and the problem is one specific database or migration, a narrower engagement – or a specialist – may be better value.
Questions
How do you scale a SaaS application?
Measure first, then fix the database (indexes, query patterns, connection pooling), move slow work into background jobs, cache computed results with clear invalidation, and isolate your largest tenants. Split into separate services only where a component has a different scaling need. Most products never need to go further.
Do we need microservices to scale our SaaS?
Almost certainly not yet. Most growth-stage SaaS slowdowns come from the database and from tangled code ownership, not from running as one deployable. A modular monolith with clear boundaries usually scales further, more cheaply, than an early move to microservices.
Why has our engineering team slowed down as we grew?
Usually a mix of coordination overhead, unclear code ownership, slow reviews, risky deploys and accumulated debt in the core system. Each one is fixable. The first step is measuring where time actually goes between starting a change and it reaching customers.
How long before we see results?
The two-week sprint should produce at least one visible improvement, such as a fixed slow endpoint, a quicker deploy or an unblocked project, plus a written plan. Larger architecture changes take months, but they should ship in steps that each deliver value.
Growing fast and shipping slower?
Tell me where it hurts – the database, the deploys or the team. We’ll start with a two-week sprint and fix something real.
GMT+2 · Full EU overlap · US East mornings