Engineering Note
Why modern SaaS is more system-driven than feature-driven
Most SaaS products don’t slow down because of missing features.
They slow down because the system underneath cannot handle growth predictably.
One Rails SaaS platform we worked on looked successful from outside.
New features were shipping continuously.
User growth was steady.
But internally, things were changing:
* Deployment time increased from ~8 minutes to nearly 45 minutes
* Sidekiq queues started building up during peak traffic
* API response time crossed 2.5s on critical workflows
* Production incidents increased almost every sprint
Nothing was “down”.
But the system was degrading.
The interesting part?
Most issues were not caused by traffic itself.
A newly added analytics feature was running heavy queries on the same DB handling transactional APIs.
At the same time:
* Background jobs were competing with user requests
* Multiple integrations increased retry traffic
* CI/CD pipelines became slower with growing code complexity
Feature growth created operational pressure.
So instead of focusing only on roadmap delivery, we shifted focus to system behaviour:
* Separated reporting workloads from core APIs
* Optimised Sidekiq queue priorities
* Reduced deployment bottlenecks
* Improved observability on critical flows
After that:
* Deployment time reduced significantly
* Queue latency stabilised
* Production incidents dropped
* Feature delivery became predictable again
Important learning:
Modern SaaS scaling is no longer only about shipping features.
It is about whether the system can continue supporting business growth reliably.
That is where architecture starts affecting product outcomes.
They slow down because the system underneath cannot handle growth predictably.
One Rails SaaS platform we worked on looked successful from outside.
New features were shipping continuously.
User growth was steady.
But internally, things were changing:
* Deployment time increased from ~8 minutes to nearly 45 minutes
* Sidekiq queues started building up during peak traffic
* API response time crossed 2.5s on critical workflows
* Production incidents increased almost every sprint
Nothing was “down”.
But the system was degrading.
The interesting part?
Most issues were not caused by traffic itself.
A newly added analytics feature was running heavy queries on the same DB handling transactional APIs.
At the same time:
* Background jobs were competing with user requests
* Multiple integrations increased retry traffic
* CI/CD pipelines became slower with growing code complexity
Feature growth created operational pressure.
So instead of focusing only on roadmap delivery, we shifted focus to system behaviour:
* Separated reporting workloads from core APIs
* Optimised Sidekiq queue priorities
* Reduced deployment bottlenecks
* Improved observability on critical flows
After that:
* Deployment time reduced significantly
* Queue latency stabilised
* Production incidents dropped
* Feature delivery became predictable again
Important learning:
Modern SaaS scaling is no longer only about shipping features.
It is about whether the system can continue supporting business growth reliably.
That is where architecture starts affecting product outcomes.