When you need Terraform (and when you don’t)

When you need Terraform (and when you don’t) is a commercial call, not a maturity badge. Terraform earns its keep when rebuildability, reviewable change, and not depending on one person’s console memory start to matter. Until then, console clicks, a few scripts, or a managed PaaS can be the honest choice.

When Terraform earns its keep

You need it when more than one person can change cloud, or you have more than one environment that must stay alike. You need it when a rebuild has to be possible without archaeology, when change should be reviewable in git, or when blast radius (IAM, networking, databases) is big enough that “I think I fixed it in the console” is not a plan.

I’ve seen Friday outages where the only map of production lived in one engineer’s browser history. Security groups edited by hand, a database parameter changed “just for tonight,” and nobody could say what staging still matched. That is the moment Terraform stops being fashion and starts being insurance.

Eight Mile’s house rule on SaaS builds is blunt: infrastructure lives in git, not in somebody’s memory, and servers are rebuilt, never hand-fed. The infrastructure and cloud work is Terraform, pipelines, and accounts you own, UK and EU regions by default, with monitoring and someone still on the other end after apply.

When you don’t need it yet

Skip Terraform for a single-box MVP you might throw away next month. Skip it when a managed hosting platform is carrying the product and you have no ops appetite. Skip it when one founder and a quiet weekend of console work still match the risk. Introducing IaC too early burns calendar on state backends, modules, and pipeline theatre while customers still don’t exist.

Good enough without it looks like: a short runbook, named who holds root, backups you have restored once on a copy, and a deliberate date to add Terraform before the second hire or the second environment. That is patience, not laziness. A PaaS that owns the platform so you can ship product is also a fair temporary answer, as long as you know when ownership of the account becomes the next problem.

What goes wrong if you wait too long

Click-ops scales with memory until it doesn’t. Hand-fed servers drift. Staging lies about production until a security group or RDS parameter only exists in live. A restore that was never rehearsed fails on the day you need it, with the backup file present and nobody sure of the steps. Agency “we host it” stacks leave you without the account. The cost of staying in the console is not the missing .tf file; it is the outage you cannot reproduce and the person who left with the mental model.

The other failure is Terraform theatre: state on a laptop, modules nobody understands, apply from a laptop after a beer. If you adopt it, treat it as the source of truth with remote state and a pipeline, or don’t bother. Half-done IaC is often worse than honest click-ops with a written runbook.

Which one do you need?

If you are asking when you need Terraform (and when you don’t), start without it while the product is disposable and one person owns the cloud. Move when team, environments, rebuild, or audit pressure shows up. Don’t adopt it to impress a LinkedIn post or because a podcast said every serious company uses it.

Console for a throwaway. Terraform when the product is real and more than one brain can break it.

If you want infra in git on AWS accounts you own, with someone who still answers after apply, contact Eight Mile and say what is click-ops today.