Dev, Staging, and Production: Software Environments Explained

Sit near a software team for a day and you'll hear it: "that's still in dev," "it's on staging now," "we don't test in prod." It sounds like they're describing rooms in a building — and honestly, that's a good way to picture it. Each of those words is a separate, complete copy of the software, and each one exists for a different reason.

An environment is a full working copy of an app plus everything it needs to run — the code, the settings, the database, the connections to other services. The same app can live in several environments at once, each a little different from the others. Those differences are the whole point, and they're also where the surprises hide.

We'll use one running example the whole way through: a website that sells concert tickets. We'll start at the environment that matters most and work backward.

Production ("prod") — the real thing

Start at the end, because everything else exists to serve it.

Production is the live version. It's the site real customers actually visit, running on real servers, with real ticket inventory and real credit-card charges. When someone buys a seat to a show on a Friday night, that happens in prod.

Because it's real, mistakes here are expensive in a way they aren't anywhere else. A bug in prod isn't a red line on a screen — it's a fan who can't check out, a card charged twice, or two people sold the same seat. That's why "don't test in prod" is close to a commandment on most teams. You don't rehearse in front of the paying audience.

Takeaway: Production is where real people and real money are, so it's the one place you never want to be discovering problems.

Development ("dev") — where the work happens

Now go to the opposite end.

Development is the copy that lives on a developer's own laptop. It's where new features get built, and it's meant to be messy — half-finished, restarted, broken on purpose to see what happens. No customer is anywhere near it.

Dev is also the environment that looks least like production. It usually runs on fake data (a handful of made-up shows, not the real catalog), with the developer's own settings, on one laptop instead of the big servers prod runs on. That gap is where the famous phrase "it works on my machine" comes from. The code really does work — on that one laptop, with that fake data. Whether it works anywhere else is a separate question.

Takeaway: Dev is the safe, messy workshop. "It works on my machine" isn't a lie — it just only proves the code works in the one place least like production.

Staging — the dress rehearsal

Between the messy workshop and the live show, teams put one more environment in the middle.

Staging is a near-copy of production, built to look and behave as much like the real thing as possible — similar servers, a realistic (but not live) database, the same connections switched on. Nothing a customer does touches it. The job of staging is to be the last place you can catch a problem before it's in front of real people. It's the dress rehearsal: same stage, same lighting, no ticket-buying audience yet.

Here's the catch worth understanding early. Staging is like production, but it is never exactly production. Maybe its database is a copy from last week. Maybe it talks to a "test mode" version of the payment company instead of the real one. Those small differences are why you'll sometimes hear "but it passed staging" right after something breaks in prod. The change was fine — in a place that was almost, but not quite, the real thing.

Takeaway: Staging catches most problems because it mimics production, but the small ways it differs from production are exactly where the last surprises live.

The three environments at a glance

Here's the whole cast in one place:

Environment	Who's there	How real is the data	What it's for
Dev	One developer, on their laptop	Fake / made-up	Building and breaking things safely
Staging	The team, testing	A realistic copy, not live	The dress rehearsal before customers see it
Production	Real customers	Real — real orders, real money	The actual live product

Read it left to right and the pattern is clear: as a change moves from dev toward prod, the data gets more real, the audience gets bigger, and the cost of a mistake goes up.

Takeaway: The environments form a ladder from "safe and fake" to "real and public" — and a change climbs that ladder one rung at a time.

Following one change from dev to prod

(Developed example — a simple scenario.)

Let's make this concrete by carrying a single change all the way up the ladder. The concert-ticket team wants to add a small feature: a "hold my seats for 10 minutes" timer at checkout, so a fan who's still typing in their card details doesn't lose their seats to someone else.

In dev. A developer builds the timer on her laptop. She adds a show called "Test Band" with ten fake seats, clicks through the checkout, and watches the countdown work. It holds the seats, releases them after ten minutes, all good. On her machine, the feature is done. What dev proved: the basic logic works. What dev couldn't prove: how it behaves with the real catalog, real traffic, or the real payment step — because none of those exist on her laptop. This is the "works on my machine" gap in action.

In staging. The change moves to staging, which has a realistic copy of the ticket catalog and a test version of the payment system. Now the team tries the things one laptop can't easily fake: two people grabbing the last two seats at the same moment, a countdown that expires while someone is on the payment page, a customer clicking "back." Staging catches a real bug here — when the timer runs out mid-payment, the seats get released but the customer still gets charged. That's exactly the kind of problem you want a dress rehearsal to find. The team fixes it and re-tests.

In production. The fixed change is promoted to prod, and it's live for real fans buying real tickets to real shows. Even now the team watches closely for a day, because prod has things staging didn't: the actual payment company (not its test mode), real traffic spikes when a popular show goes on sale, real customer behavior. This is why teams often do a quick check right after a change goes live — a fast look to confirm nothing obvious broke. (That five-minute check has a name; see smoke testing.)

Notice what each environment did: dev proved the idea, staging caught the mid-payment bug, and prod was the only place the change met real money and real crowds. Skip a rung and you hand that rung's job to your customers.

Takeaway: Each environment catches a different kind of problem, and the "works on my machine" gap is real — a change can pass on a laptop and still fail the first time it meets real data.

The one question that predicts surprises

When a change passes staging and still breaks in prod, it feels like bad luck. It usually isn't. It's a difference nobody looked at.

So the single most useful habit — long before you know how to test anything — is to ask, for whatever environment you're standing in: "How is this different from production?" The differences are where surprises hide. On our ticket team, the answers would be plain: staging uses last week's catalog, staging uses the payment company's test mode, staging never sees the on-sale rush. Each of those is a spot where a change might behave one way in staging and another way in prod.

You don't need to be technical to ask this. You just need to treat "it's like production" as the start of a question, not the end of one. Every gap you can name is a surprise you can plan for instead of discover live.

Takeaway: "How is this different from production?" is the question that turns a mysterious prod failure into a difference you could have named in advance.

How a change moves up the ladder

Putting it together, the normal path for any change is dev → staging → prod, and it's a promotion, not a leap. Something is built and tried in dev, moved to staging where the team tests it against a realistic copy, and only then promoted to production for real customers — often with a careful watch for the first little while. Many teams automate the hand-offs between these steps so a change moves up in a consistent, repeatable way. If you've heard the term "CI/CD," that's the machinery that does it, explained in CI/CD in plain English. And the moment a change actually reaches customers is bigger than clicking "deploy" — what a release actually involves walks through that.

Takeaway: Changes get promoted up the ladder one environment at a time, each rung doing a job the one below it couldn't.

What to remember

Environments are separate copies of the same app, each more real than the last. Dev is the safe, messy workshop where features get built and where "works on my machine" is born. Staging is the dress rehearsal — realistic, but never quite identical to the real thing. Production is the live show, with real customers and real money, and the place you least want to be finding problems. Changes climb from dev to prod one rung at a time, and the differences between each environment and production are where the last surprises wait. Learn to ask "how is this different from production?" and you'll understand most of what these three words are really about. When you're ready for what to actually check at each rung, testing strategies that scale picks up there.

Sources

This article is an original explainer built from widely used software-delivery conventions (the standard dev -> staging -> production promotion path). The concert-ticket walkthrough is a composite scenario written to illustrate the concept, not a record of a specific company or product.

Keep learning. This article is part of the Start Here path in the ShiftQuality Learning Center.