---
title: "The Twelve-Factor App and the staging environment finance wants to cut"
description: "Most of Twelve-Factor quietly became the sane defaults, and dev/prod parity is the factor teams still trade away when the cloud bill comes up."
url: "https://michael.zazon.us/notes/the-twelve-factor-app-and-the-staging-environment-finance-wants-to-cut"
published: "2026-01-19T12:00:00-05:00"
kind: "book-notes"
subject: "architecture"
tags: ["cloud","team-design"]
---
I don't like when we write code and throw it over the fence to the ops engineers. In my opinion, every developer is an ops engineer. I hear people say, oh, management is cheap, they just want people who can do front end, back end, and devops, and all of this at the same time. And I think there's trade-offs in everything we do. I also think part of your job as an engineer is understanding how what you wrote actually gets served and used by the public. And if it breaks, how do you fix it?

That fence has a name: the personnel gap. It's from [The Twelve-Factor App](https://12factor.net/), a methodology put together by some Heroku engineers in 2011 for building SaaS apps.

This has become in a lot of ways the sane defaults. We talk about best practices, but this is the sane defaults.

Putting all your configuration in environment variables and writing logs to stdout is just what people do when they run containers now, it's not called a methodology anymore. There's still the [dev/prod parity](https://12factor.net/dev-prod-parity) thing to negotiate, which asks that you keep your environments as similar as possible and close the time/personnel/tools gaps between your laptop and production.

When you're looking at your cloud bill every quarter and wondering why staging is such a big line item when it's never served a single customer, you have some choices. You could shrink it down to run on cheaper instances, keep it the same size as production, or get rid of it entirely and just test in production behind feature flags.

Sometimes it is cost prohibitive to have a dev or a staging environment that's in parity with production. It's typically far less expensive than the actual engineering staff that is having to deal with the fact that emerging problems come up, or the potential cost of outages.

The bill for staging is easy to see (it's monthly, and it has a number).. the incident it prevents never has one.

There are now ways that you can kind of cheat production parity in that maybe your system is so big and so complex and there's no way to actually reproduce a dev or a staging version of it, but there's clever ways that you can actually honor this while not having to actually double your spend.

You can use feature flags, canary releases where you send a small slice of real traffic to your new code before you roll it out, but the worst thing you can do is to shrink your staging environment until it's a different system.

Before I say something's a production release, I should test it on the equivalent of production hardware.

If your staging environment has drifted so far from production that it quietly fails the standard, deploys keep passing through it.. yet the release only meets real production hardware for the first time on release day. Is anyone still testing there, or is it just a ritual with a line item?