"It worked in staging" is one of the more common sentences in software engineering, and it's almost always a symptom of the same underlying issue: staging and production aren't actually the same shape of infrastructure, just similarly named. A reliable multi-environment foundation is designed to prevent that sentence from being necessary.
Environments should differ in scale, not in architecture
The goal isn't identical environments — production needs more capacity, more redundancy and tighter access controls than a development environment. The goal is that they're built from the same infrastructure code, with different variables, so the architecture itself — networking, IAM structure, service topology — is identical, and only the scale and safeguards differ.
This is really an argument for infrastructure as code over manual provisioning: if staging was created by running Terraform with a staging.tfvars file, and production was created the same way with production.tfvars, they're structurally guaranteed to match. If either was set up by hand at some point "to save time," that guarantee is gone, and it usually stays gone.
Network design decided once, applied consistently
VPC layout, subnet structure and routing rules should be designed once, as a module, and instantiated per environment — not redesigned per environment as new requirements come up. This is one of the areas where inconsistency causes the most subtle bugs: a security group rule that exists in production but was never replicated to staging, discovered only when a staging deployment behaves differently for reasons nobody can immediately explain.
IAM boundaries should reflect environment risk, not just convenience
Production IAM roles should be more restrictive than development ones — narrower permissions, shorter-lived credentials, more explicit approval for changes. This is often skipped for convenience ("we'll tighten it before launch") and then never revisited. Building the tighter production boundary from the start, even when it's mildly inconvenient during early development, avoids a security review becoming a pre-launch scramble.
Backup and disaster recovery need to be part of the foundation, not bolted on later
Backup strategy, retention policy and recovery procedures are far easier to build into the initial infrastructure design — as part of the same Terraform modules that provision the databases and storage in the first place — than to retrofit once real data and real dependencies exist. A foundation that doesn't include this from day one tends to never quite get around to it, until the day it's needed and isn't there.
What "done" looks like
A reliable multi-environment foundation means: any engineer can look at the Terraform for staging and production and see the same module calls with different variables, not different hand-maintained configurations that have quietly diverged. It means a new environment — a second production region, a dedicated environment for a new product line — can be stood up in hours by calling the same modules again, not rebuilt from institutional memory.
That's the actual measure of a good foundation: not how sophisticated the architecture looks on day one, but how boring and repeatable it is to extend on day two hundred.
Related services