How to Know When Your SaaS Has Outgrown Its Infrastructure

Infrastructure rarely fails loudly at the moment it stops being adequate. It degrades into a tax: every feature takes slightly longer, every release needs slightly more coordination, and one or two engineers quietly become the people who know how deploys work. The signals below are the ones we see most often in companies between 10 and 50 engineers.

1. Deploys are scheduled around a person

If releases wait for a specific engineer to be online, your deployment process contains undocumented knowledge. The fix is not more documentation — it is removing the steps that require judgement. A deploy should be a pipeline run with an automatic rollback path, not a procedure.

2. Environments have drifted

Staging behaves differently from production, and nobody can say exactly how. This almost always means parts of production were created by hand and never imported into code. Until environments are reproducible from a repository, every test result carries an asterisk.

3. Cloud spend grows faster than usage

Compare month-over-month spend growth against a real usage metric — requests, tenants, active users. If spend is outgrowing usage, you have either an architectural cost driver or accumulated waste. The distinction matters: waste is cleanup work, architectural drivers are design work.

4. Nobody upgrades the cluster

Version skew is a lagging indicator of confidence. Teams postpone Kubernetes upgrades when they cannot predict what will break, which usually means workloads lack probes, disruption budgets and resource limits. The upgrade is not the problem; the workloads are.

5. Incidents are diagnosed by intuition

If the first step in an incident is 'ask the person who built it', observability is missing. A healthy system lets any on-call engineer answer three questions in under a minute: is it up, is it slow, and what changed recently.

6. Every team has its own pipeline

Divergent CI configuration is a symptom of no paved road. It is tolerable at three services and expensive at thirty, because every security or compliance change then has to be applied thirty times.

7. Onboarding takes more than a week to first deploy

Time from a new engineer's first day to their first production deploy is the single best proxy for platform quality. Measure it. If it is longer than a week, the friction is structural.

8. Security work is a project, not a property

When least privilege, secret rotation and dependency scanning are periodic initiatives rather than pipeline defaults, they regress between initiatives. Controls that are not enforced automatically decay.

9. Senior engineers are doing operations full time

This is the most expensive signal and the easiest to miss, because the work gets done. It just gets done by the people you hired to build the product.

What to do with this list

Count how many apply. One or two are normal at any scale. Four or more usually means the next quarter of engineering output is already committed to infrastructure friction, whether or not it appears on the roadmap. That is the point at which a structured assessment pays for itself, because the sequencing question — what to fix first — matters more than any individual fix.