Every growing infrastructure team starts the same way: one repository, one state file, and a handful of engineers who know exactly what every resource does and why. Two years and two hundred modules later, almost nobody can say that anymore.
The gap between using Terraform and using Terraform at scale isn’t really a technology problem. It’s an organizational one, and most enterprises hit it later than they expect, usually right around the point where a second team, then a fifth, then a fifteenth starts writing infrastructure code without ever agreeing on how.
The standardization gap, in the data
The State of Platform Engineering Report, an independent survey of 281 platform engineering professionals, put a number on this. 47.54% of respondents named a lack of standardization in their DevOps setup as a primary reason for building a platform team in the first place. Only 12.18% describe their platform function as an optimized, cross-functionally integrated ecosystem. 8.82% still run it on voluntary or temporary staffing with no dedicated funding at all, and 55.84%, more than half, say their platform team has existed for less than two years.
That last number is the one worth sitting with. Standardization isn’t a side effect of maturity. It’s close to a precondition for it: organizations that get infrastructure right are almost twice as likely to have a team whose job is to make sure it stays consistent, and the ones that never build that team stay stuck at the level where every group solves the same problem differently.
Terraform inherits that gap directly, because it’s a tool that rewards structure rather than enforcing it. Shared modules, consistent naming, a clear line between what an application team owns and what a platform team owns: none of that comes for free. Without agreement on it, “using Terraform” just means writing HCL, and code written without agreement scales the way any codebase does with fifty unsupervised contributors. Unevenly, and worse over time.
Where it actually breaks down
The failure points are consistent enough across enterprises that they’re worth naming individually.
Modules get reinvented instead of reused. Three teams need a virtual network, so each team writes a slightly different virtual network module, with its own assumptions about subnetting and tagging baked in. None of them is wrong on its own. Together, they make it impossible to answer a simple question like “how many networks do we actually run” without a manual audit.
State files are drawn along convenience lines rather than ownership lines. A project starts small, so a single state file covers the database, compute layer, and networking. Eighteen months later, that project has grown into three unrelated services with three different owners, all still sharing one state file and one blast radius, because splitting it was never anyone’s assigned job.
Naming and tagging drift until cost attribution becomes guesswork. This sounds cosmetic until finance asks which team is responsible for a spike in cloud spend, and the honest answer is that nobody can say for certain, because half the resources in the account were tagged by whichever engineer happened to write that module first.
And changes ship without anyone responsible for the platform as a whole ever seeing them. A risky change to a shared network rule or an identity and access management (IAM) policy is reviewed by the team that wrote it, because there’s no gate that routes it elsewhere first.
None of these are Terraform bugs. They’re what happens when a fast-moving practice outruns the operating model meant to support it, which is exactly the pattern behind the broader cloud complexity numbers enterprises report more generally.
The fix is a team, not a wiki page
The instinct at most organizations is to write the standard down: a wiki page describing how modules should be structured, a naming convention document, a Slack channel for infrastructure questions. This rarely survives contact with a deadline. Documentation describes a standard. It doesn’t enforce one, and by the time a team is under pressure to ship, the documented way and the fast way stop being the same thing.
What that data suggests instead is closer to what the mature organizations already do: an actual owned layer between individual Terraform configurations and the infrastructure they produce, not just a reference for how that layer should theoretically work. In practice, that layer needs three things a wiki page can’t provide: a module registry that tests every shared module before anyone is allowed to consume it, shared configuration that stacks inherit rather than copy and paste, and policy that runs the same way no matter which team pushed the change.
Spacelift structures this around stacks, where each stack bundles a Terraform or OpenTofu configuration with its state and inputs, and stacks can depend on each other through an explicit graph rather than an informal understanding of which one has to run first. Settings that should be shared, like which cloud credentials a group of stacks uses, live in reusable contexts instead of getting copied into every new project by hand, and Open Policy Agent rules, attached in the same reusable way, enforce the standard on every run instead of only the ones someone remembered to review manually.
Drift gets checked on a schedule and can be reconciled automatically rather than just flagged for someone to notice later, which matters far more at 200 stacks than at 2. None of that replaces the platform team, the data points to. It gives that team something real to enforce standardization with, instead of a policy nobody has time to check by hand.
Building that doesn’t require solving the whole problem on day one. It starts small: identify the ten or so resource patterns every team ends up writing anyway, turn them into modules with a single owner, and require new stacks to start from one of them instead of a blank file. That alone closes most of the gap between the 42% of organizations with a real platform function and the majority still improvising one team at a time.
