The Real Cost of Dev, Staging, and Preview Environments

The Real Cost of Dev, Staging, and Preview Environments

When engineering leaders calculate the cost of their infrastructure, the number on the cloud invoice looks concrete. The real cost of environments does not appear on any dashboard.

It shows up in the two days a new hire spends trying to get a local environment running. In the backlog of tickets that cannot move because staging is occupied. In the 23-minute recovery time every time a developer gets pulled out of focus to coordinate an environment hand-off. None of these costs are captured in a sprint metric. All of them compound.

The numbers most teams are not tracking

Research from Bunnyshell and Release puts a rough figure on the magnitude: around 20% of product engineering time is consumed managing production-like clone environments. A similar proportion of infrastructure engineering time disappears into the same work.

For a 100-person engineering team, Okteto's analysis estimates that eight lost hours per developer per week from environment contention alone represents a 20% productivity loss, which translates to millions of dollars annually in engineering capacity that never shipped anything.

These figures align with wider developer experience research. The GetDX Developer Experience Report 2024, which surveyed 900 developers globally, found that 69% lose eight or more hours per week to inefficiencies including waiting on environments and blocked builds. Fewer than half believe their managers are aware of the scale of the problem.

The infrastructure bill is visible. The developer time lost to environment overhead is not.

The shared staging bottleneck

The most common environment problem in growing teams is also the most obvious once you name it: shared staging is a zero-sum game.

One staging environment. Multiple teams pushing changes simultaneously. Any team that deploys to staging owns it until their work is reviewed, which means every other team waits. The waiting generates coordination: Slack messages, calendar bookings, verbal agreements about who has staging today. Senior developers lose a minimum of 2.5 hours per week coordinating staging access, according to Okteto's research. That is time taken directly from work that has leverage.

The downstream effect is just as damaging. When staging is contested, developers learn to avoid deploying frequently. Changes batch up. Larger batches mean riskier releases, harder debugging when something breaks, and longer lead times. The same compounding loop described in the previous post on deployment friction applies here. The environment contention is not a symptom of a fast-moving team. It is the thing slowing them down.

One company measured 40 days average from code complete to production release. Most of that time was not spent in active review. It was spent in the queue, waiting for a staging slot.

The onboarding tax

A second, underestimated category of environment cost is what gets paid every time a new developer joins a team.

Standard developer onboarding in most organisations takes around 30 days before a new hire is fully productive. Coder's 2025 State of Development Environments report found that only 16% of organisations use standardised tools consistently across teams. The rest require new hires to navigate per-project environment setups that have diverged through months of incremental, undocumented changes.

Developers regularly spend two to five days fighting environment configuration issues that were solved months earlier on another project. Bunnyshell estimates the total cost of a standard 30-day onboarding at approximately $35,000 per hire: $20,000 in salary and $15,000 in lost productivity from setup friction alone.

Those numbers move when environments become self-service. One platform engineering team reduced onboarding time from two weeks to two hours by treating environments as a standardised, self-service product. The change was not in the stack. It was in the environment model.

What preview environments change

The architectural fix to both problems, staging contention and onboarding friction, is the same: move from shared, long-lived environments to isolated, ephemeral ones.

A preview environment is a complete deployment of the application, spun up automatically on branch push, accessible via a unique URL, and torn down when the branch merges. Each pull request gets its own environment. Teams do not compete for staging slots. Reviewers, designers, and stakeholders can access a real preview of every change before it lands, without touching production or coordinating access.

Research from ephemeral environment platforms including Bunnyshell shows teams that adopt per-branch preview environments see 50 to 70% faster QA cycles, reduced time maintaining shared staging infrastructure, and fewer bugs reaching production. The mechanism is straightforward: isolated environments eliminate the zero-sum competition for shared state, which means teams can review in parallel rather than in sequence.

Preview environments also resolve the onboarding problem indirectly. When environments spin up from a declared configuration rather than a hand-crafted setup, a new developer can run the same environment as production from day one. The two-day fight with environment config disappears because there is nothing to set up manually.

As covered when discussing why deployment still feels broken, the teams moving fastest treat their delivery pipeline, including environments, as a product that gets designed and maintained, not inherited and endured.

A cost that compounds quietly

Environment overhead fits the same pattern as most workflow friction: it is invisible until it is named.

No sprint retro captures "we lost 20% of our engineering capacity to staging coordination this week." No performance review surfaces the two days a new hire spent misconfigured. The cost accumulates in small increments, spread across enough people that no single incident triggers investigation.

The teams that address it early do so by asking the same question worth asking about deployment: if environment setup took ten minutes instead of two days, and staging was never contested, what would the team ship differently?

The answers reveal what the environment model is actually costing.

Forge's POV

Forge's developer platform treats environments as a default, not a feature. Every branch is deployable. Every push generates a preview. There is no shared staging environment to coordinate around, because every team's branch has its own.

Git-driven deploys mean environment setup is declarative, not manual: what runs in production is the same configuration that runs in every preview, which means new developers start with a working environment rather than a troubleshooting session.

The infrastructure cost of environments is visible on a bill. The developer cost is not. Forge is built around the premise that eliminating the invisible cost is where the compounding starts.