works-in-production.dev PROD Ship to Prod

--- a/works-in-staging.dev +++ b/works-in-production.dev

If it works in staging, that’s basically production.

If it works in production, that’s basically tested.

The premier platform for skipping staging, shipping on Fridays, and letting real users find the edge cases.

Ship It Now Blame Staging
  • No rehearsal
  • Actual uptime*
  • Works on their machine

*Uptime observed. Understanding not included.

A relaxed engineer in an I TEST IN PROD hoodie leans back with his feet up and a DEPLOY ON FRIDAYS mug, between a red STAGING monitor listing failures and a green PROD monitor where everything is Fine. A cat sleeps on a stack of books, a rubber duck in sunglasses holds an LGTM sign, and the sun sits low over the city outside.
FIG. 01 / AVAILABILITY ≠ UNDERSTANDING

A complete stack of irreversible decisions

Customer-Driven Testing

Thousands of unpaid testers, working around the clock. Bug reports arrive in real time, mostly in capital letters.

Feature Flags as Emotional Support

Ship everything dark, switch it on at 16:59, and call it a controlled experiment.

Roll-Forward Recovery

Rollbacks are for people with a previous version that worked. We roll forward, confidently and repeatedly.

Trusted by people who ship on Fridays

Fictional people. Familiar pager alerts.

“We turned off staging to save money. Now we save time, too.”

Jordan, Staff EngineerHasn’t seen staging since 2023

“Our lead time to production is zero. Our lead time to apology improves every quarter.”

Sam, CTOBelieves in velocity

“I learn about every release from our customers. It’s the most reliable changelog we have.”

Riley, Support LeadHears about releases first

100%

real traffic

Every request is a test case

0

staging environments

Budget reallocated to apologies

∞

edge cases

Found by customers, free of charge

“A bold new definition of ‘tested.’”

— Definitely Not Gartner™ Either

01 / Your next irreversible decision

All the confidence.
None of the rehearsal.

Take the pipeline for a spin. The only thing at risk is your weekend.

ship-it-friday.sh production

./deploy --env=production --skip=staging

  1. 00:00[SKIP]Build: it compiled on Tuesday.
  2. 00:01[SKIP]Tests: customers will report back.
  3. 00:02[SKIP]Staging: last seen at works-in-staging.dev.
  4. 00:03[LIVE]Production: shipped at 16:59 on a Friday.
  5. 00:04[INFO]No servers were contacted. This is a demo.

Ready. Staging was not consulted.

02 / In case of customers

Emotionally prepared.
Operationally, less so.

Documentation is written after the fact, like all the best fiction.

IncidentsSev: YOLO

It worked in production.
Eventually.

A fictional incident report. Any resemblance to your Friday is entirely deployed.

Read the timeline
  1. Merged straight to main. Review: vibes.
  2. Deployed to production. Laptop closed.
  3. Customers begin exploratory testing.
  4. Hotfix deployed. Also to production. Also untested.
  5. Stable. Nobody knows why. Nobody asks.

Runbookslast tested: live

Have you tried
the next version?

A battle-tested recovery procedure. Every battle took place in production.

Open the runbook
  1. Roll forward.
  2. Roll forward again, with feeling.
  3. Look for the rollback button.
  4. Remember nobody built one.
  5. Roll forward. Set the status page to “Monitoring”.

Escalation path: works-in-staging.dev, who will say it works for them.

Postmortemsblameless, mostly

It’s not a bug.
It’s real-world validation.

Turn an outage into a document proving it was nobody’s fault, least of all production’s.

Read the retrospective
Summary
A routine release received immediate feedback from forty thousand users.
Root cause
Staging differed from production by not having users.
What went well
Customers found it before monitoring did.
What we learned
Staging wouldn’t have caught this. We didn’t check.
Action item
Decommission staging. Owner: Finance.

03 / Environment parity

Two environments.
One argument.

Our upstream, works-in-staging.dev, insists everything passed. We insist everything shipped. Both statements are true, which is exactly the problem.

Staging Production you are here
TestsAll passedNot run, technically
UsersNoneAll of them
Test dataSeeded in 2019Arriving live
BlamesDNSStaging
ConfidenceUnearnedAlso unearned
ParityDisputedDisputed
Roll back to staging

Also available at /rollback, for muscle memory.

The enterprise tier of consequences

Community-tier planning.
Enterprise-grade consequences.

Unlimited deploys. Live customer feedback. Absolutely no staging.

$0/ staging environment

Billed per incident, in reputation.

Start shipping

No credit card. No actual product. No staging.

The fine print. The only thing we tested.

This is a satirical, static website and the companion to works-in-staging.dev. The testimonials, metrics, incidents, and product claims are fictional. The deploy console is a local browser simulation: it doesn’t contact a server, change infrastructure, or ship anything.

No accounts, payments, analytics, tracking cookies, or external libraries. For the record, staging is good, actually. So are feature flags, gradual rollouts, and rollbacks that work. The joke is the bravado, not the people who clean up after it. Take care of your on-call humans.