The deploy process that worked at 5 engineers breaks at 15
Every engineering team runs manual deploys at some point, and for a while it's fine. One or two people know the steps, the checklist lives in a Notion doc, and releases happen when someone has a free afternoon. Then the team grows past 15 engineers, release frequency goes from weekly to daily, and the exact same process starts producing incidents.
We see this pattern constantly: a team that shipped safely for two years suddenly has a bad month. Not because anyone got worse at their job — because the process never scaled past the headcount it was designed for. Manual deploys are a single-point-of-failure system wearing the costume of "how we've always done it."
The question we get isn't "should we automate?" Everyone already agrees on that. The question is what to automate first, because teams that try to fix everything in one sprint usually stall out and ship nothing. Here's the order that actually works, based on the pattern we see across growth-stage teams.
Fix the deploy path before you touch infrastructure
The instinct when things feel fragile is to reach for infrastructure-as-code first — Terraform everything, get the servers under control. That's the wrong first move. If your deploy process is still "SSH in and run a script," Terraforming the box it runs on doesn't fix the actual failure mode: a human doing a repeatable task by hand, under time pressure, without a rollback plan.
The first automation dollar should go to CI/CD: a pipeline that runs on every push, runs the same tests every time, and deploys the same way every time. Concretely, that means:
- Every merge to main triggers a build and a test suite — no exceptions, no "just this once" manual pushes.
- The deploy step is a pipeline job, not a person's terminal. GitHub Actions, GitLab CI, or CircleCI all handle this; the tool matters less than the discipline of using it every time.
- Rollback is a button, not a person remembering the last-known-good commit hash at 11pm.
Teams that do this first typically see deploy-related incidents drop noticeably within the first month, without touching a single Terraform file. The reason: most "infrastructure" incidents at this stage aren't infrastructure problems. They're process problems wearing infrastructure clothes — a config value that only exists in one engineer's head, a migration step someone forgot to run, a deploy that happened out of order with another one.
Then make environments reproducible
Once deploys are automated, the next failure mode surfaces: "it works in staging but not in production," or worse, "we can't remember how staging was set up." This is where infrastructure-as-code earns its place — not as the first fix, but the second.
Terraform or OpenTofu modules that describe your AWS, GCP, or Azure environment as version-controlled code solve a specific problem: environment drift. Without IaC, every environment accumulates small, undocumented differences — a manually bumped instance size here, a security group rule added during an incident there — until staging stops being a reliable predictor of production behavior.
The practical target isn't "automate 100% of infrastructure" on day one. It's: can you destroy and rebuild your staging environment from code in under an hour, with no tribal knowledge required? If the answer is no, that's the next thing to fix — before Kubernetes, before multi-region, before anything more ambitious.
Preview environments close the loop that CI/CD opens
With deploys automated and infrastructure reproducible, the next lever is giving every pull request its own throwaway environment. This is the step teams skip because it feels like a luxury, but it's usually the highest-leverage automation after the first two.
Without preview environments, "does this actually work" gets answered in staging, which is shared, which means every engineer's changes collide with everyone else's. QA becomes a queue. Bugs get found late, after multiple changes have piled on top of each other, which makes them expensive to isolate. Preview environments — spun up per-PR and torn down on merge — turn that queue back into parallel, independent testing. Teams that add this after fixing the deploy pipeline generally find review-to-merge time improves, because reviewers can click a link and see the actual change running instead of reading a diff and trusting it.
What to automate last, not first
Progressive delivery — canary releases, feature flags, automated rollback on error-rate spikes — is real and valuable, but it's a later-stage investment. It solves the problem of "how do we ship safely to production traffic," which only matters once shipping to production itself is already reliable and boring. Teams that build canary infrastructure before they have working CI/CD are automating the wrong risk; the traffic-shaping logic doesn't help if the underlying deploy still depends on someone running the right commands in the right order.
Kubernetes falls in the same later bucket for most growing teams. It solves real problems — autoscaling, resource isolation, self-healing services — but it adds real operational surface area: manifests, Helm charts, cluster upgrades, RBAC. Teams below roughly 20 engineers running a handful of services are usually better served by a simpler platform (ECS, Cloud Run, a managed PaaS) with solid CI/CD in front of it. Move to Kubernetes when you have enough services that the orchestration problem is real, not because it's the expected next step.
A realistic sequence, and what it costs
For a team of 15-25 engineers coming off manual or semi-manual deploys, a sequence like this one usually works: CI/CD pipeline with automated tests and one-click rollback first (typically 2–4 weeks), infrastructure-as-code for the core environments second (another 3–5 weeks, depending on how much drift has already accumulated), then preview environments and monitoring/alerting layered on top. A CI/CD setup on its own typically starts from $8,000; the full sequence — CI/CD plus infrastructure-as-code plus preview environments — typically starts from $25,000+ depending on how many services and environments are in scope — and it's a staged rollout our cloud & DevOps team scopes stage by stage rather than as one open-ended platform rebuild.
The mistake to avoid is treating this as one big infrastructure project with a single launch date. Each stage should ship independently and start paying back immediately — a working CI/CD pipeline is valuable on its own, even before Terraform exists to back it.
The bottom line
When manual deploys start breaking down, the fix isn't "get more DevOps tooling." It's sequencing: pipeline first, reproducible infrastructure second, preview environments third, progressive delivery and orchestration only once the basics are boring. Teams that automate in this order fix their worst incidents in the first month. Teams that start with the most sophisticated tool on the list usually spend a quarter building infrastructure for a deploy process that's still fundamentally manual underneath it.
