If you own a business and your developers keep arguing about "environments," here is the argument translated into plain terms. The staging environment importance they are pushing on comes down to one idea: you want a rehearsal copy of your system where changes get tested before real customers ever touch them. Skip it, and every update is opening night with no rehearsal, live, in front of a paying audience.

I have cleaned up enough Friday-evening disasters to feel strongly about this. A staging environment is one of the cheapest forms of insurance a software business can buy, and it is one of the most commonly skipped, usually to "save time." The time it saves is an illusion. The time it costs, when things go wrong in front of customers, is very real.

Let me make the case in language that does not require you to be an engineer.

The theater rehearsal metaphor

Think of your live website or app as opening night of a play. Real audience, tickets sold, no do-overs. Now imagine the director says: "We will just change the script, move the set, and swap two actors, and see how it goes during the actual performance." You would fire that director.

That is exactly what "testing in production" means. Production is your live system, the one customers use. Testing in production means making changes directly on it and finding out whether they work by watching real customers hit the bugs.

A staging environment is the dress rehearsal. It is a separate copy of your system, set up as close to the real one as practical, where the team runs the full performance first. If the new set collapses, it collapses on an empty stage. Nobody bought a ticket to that.

The three environments most teams use map cleanly to this:

  • Development is the writers' room, where each person drafts changes on their own machine.
  • Staging is the dress rehearsal, a shared copy that mirrors production, where everything is tested together before release.
  • Production is opening night, the live system your customers use.

Real horror stories of skipping it

These are anonymized, but the shapes are painfully common.

A retail chain in Tangerang pushed a "small" change to their online store checkout on a Friday afternoon, straight to production, no staging. The change quietly broke the payment step for one popular card type. Because it was Friday evening, nobody was watching closely. By Monday they had lost a weekend of sales and, worse, a chunk of customers who tried once, failed, and never came back. The code fix took ten minutes. The trust did not come back in ten minutes.

A distribution company updated their internal ordering system directly on the live server to "just fix one field." The fix had a side effect that corrupted how new orders were saved. Nobody noticed for two days because the app still looked fine. Untangling the bad data cost far more than the feature was worth.

The pattern is always the same. The change looked tiny. Tiny changes are exactly the ones that get pushed without rehearsal, and tiny changes have side effects nobody predicted. A staging environment is where those side effects show up cheaply.

What it costs versus one bad deploy

Owners resist staging because it feels like extra cost and extra time. Let us put honest numbers to it.

Cost of a minimal staging setup:

  • A second, smaller server or hosting instance. For most Indonesian SMEs this is on the order of a few hundred thousand to low millions of rupiah per month, often less if it can be modest.
  • A one-time effort to script the deploy so pushing to staging, then production, is repeatable rather than manual.
  • A little discipline: changes go to staging first, get checked, then get promoted.

Cost of one bad production deploy:

  • Lost sales for every hour the checkout, or the core function, is broken.
  • Staff time spent firefighting instead of doing their jobs.
  • Data cleanup, which can be far more expensive than the original bug.
  • Customer trust, the hardest line item to price and the slowest to recover.

One broken Friday deploy can easily cost more than a year of running a modest staging environment. This is the same logic behind the case for boring technology: unglamorous, predictable practices quietly prevent the expensive drama. Staging is boring on purpose. That is the feature.

A minimal setup that is genuinely enough

You do not need a big enterprise pipeline to get most of the protection. A pragmatic starter setup:

  1. One staging copy that mirrors production closely. Same software versions, a realistic copy of data with anything sensitive scrubbed. The closer it mirrors production, the more bugs it catches.
  2. A rule everyone follows: nothing reaches production without passing through staging first. No exceptions for "small" changes, because small changes are where the damage hides.
  3. A quick checklist to run on staging before promoting. Does the core flow still work? Can a customer complete a purchase or the main task? Did anything obvious break?
  4. A simple, repeatable deploy step. So promoting from staging to production is one reliable action, not a nervous manual scramble.
  5. Avoid Friday and end-of-day deploys where you can. If something slips through, you want people awake and available to fix it.

This is enough to catch the large majority of self-inflicted outages. You can always mature it later.

The practical takeaway

The staging environment importance your developers keep raising is not technical vanity, it is basic risk management stated in code terms. A rehearsal copy of your system lets breaking changes fail on an empty stage instead of in front of paying customers. The setup is cheap and boring; the disaster it prevents is expensive and memorable. Insist that every change, especially the small ones, passes through staging before it reaches production, and keep risky deploys off Fridays. It is one of the highest-return, lowest-glamour decisions you can make about your software.