Staging

Staging is the empty house next door.

Production has guests. Real clicks. Real data. Sometimes real money. Staging is a near-copy of that house — same build, same wiring, fake or extra-careful data — where you are allowed to explode. You deploy there first. You click every button. Then you promote.

Localhost is not staging. Your laptop is shaped like your laptop. Staging is shaped like production, minus the guests. That's the whole point of a twin: catch the thing that only breaks when the env is real. CORS, empty databases, the callback URL you forgot to add — those fail on the twin, not in front of the room.

Three beats, when you have time

1. Break it on your machine. Private.
2. Push to staging. Walk the demo like a judge.
3. Promote to production on purpose, not by accident.

"Push to staging first" is not bureaucracy. It's the same instinct as a pull request: prove it in safety, then let it touch reality.

Hackathon honesty

At a hackathon, staging is a luxury. You will deploy straight to production. That's fine. Make the first deploy early, while the app still says "hello," so the second deploy is a habit instead of a boss fight. Rollback is the fire exit when the habit fails. CI is how teams later make the three beats automatic.

The builder's deploy options are just "which lobby." If the platform gives you a preview URL per branch, that preview is staging with a nicer name. Use it. Send the preview to a teammate. Don't send production to a judge until you've clicked the preview yourself.

What this unlocks

Until you have a twin, every ship is a coin flip in front of guests. After you do — or after you treat the first production deploy as a rehearsal — you stop discovering CORS, missing env, and empty databases on opening night. Rehearse there. Ship here.