What is a press check?

In commercial printing, a press check is the step that "takes place after a printing press is set up but before the print run is underway." The buyer or designer inspects the first real sheets coming off the actual press and approves the run only when the color, corrections, and positioning are right. Applied to teams, it means evaluating one real unit of your work under real production conditions before you ship it at scale — not approving a preview and hoping.

Why does my email or site look different in production than in the preview?

Because the preview is rendered under different conditions than the real thing. A screen shows RGB color; a printer or another device may render it completely differently — and an email has hundreds of thousands of possible renderings across clients like Outlook, Gmail, and Apple Mail. Staging and demos can't reproduce real data volume, real load, or real configuration, so some differences only appear on the actual press. That's why a press check evaluates the real output, not the proxy.

What's the difference between a soft proof and a press proof?

A soft proof is a simulation on a monitor — cheap, fast, and approximate. A press proof is a test print made directly on the production press, under real conditions. The soft proof maps to your preview or mock; the press proof maps to a real instance of your work in production. Approving the soft proof is necessary but never sufficient — the press proof is what tells you the truth.

What should a press check include before launch?

Four things: (1) the real production conditions written down — data volume, devices, load, users; (2) one real unit produced under those conditions, such as a 1% canary, a seed-list email send, or the deck on an actual phone; (3) the decision-maker reviewing that real output live, together, not via a forwarded screenshot; and (4) an explicit sign-off only when it's actually right, with the approved state recorded as the baseline.

The Press Check: How to Catch What Previews Hide

Q: Why do demos break in production?

A demo runs the one path the builder knows works, on clean data, at small scale. Production runs every path, on messy data, at full scale. Google's SRE team notes that test environments "aren't 100% identical to production" and that most incidents are triggered by the change itself — exactly the part a rehearsed demo never exercises. The demo is a soft proof; production is the press.

# The Press Check: How to Catch What Previews Hide

For fifty years, software has sold you a promise printed into the acronym: WYSIWYG — what you see is what you get. It was never quite true. When Xerox PARC built Bravo, the first WYSIWYG editor, in 1974, the screen ran at 72 pixels per inch and the printer at 300. The monitor never showed the real page — a gap engineers ended up calling WYSIMOLWYG: "what you see is more or less what you get." Printers have fought that gap for a century, and they have a fix with a name: the press check.

Your team lives in that gap. You approve a Figma mock, a staging build, a test email to yourself, a rehearsed demo — then you ship it to thousands of real people under real conditions, and it breaks. The slide that looked clean is unreadable on a phone. The feature that flew in staging falls over in production. The email that was perfect in your inbox is a wall of broken HTML in everyone else's.

Here's how that fix works. Before a commercial printer runs fifty thousand copies, someone stands at the machine and inspects the first real sheets coming off the actual press — not a screen, not a proof — and signs off only when it's right. This is a how-to for running a press check on your own work, before "looks good" turns into fifty thousand wrong copies.

The proof is not the press

Printers don't approve work in one step. They approve a proof — a stand-in for the finished job — and then, separately, they approve the press. The distinction is the whole game.

A soft proof is the file on a monitor. It's the cheapest check and the least trustworthy, because a screen mixes light in RGB and a press lays down ink in CMYK — two different color spaces that simply do not contain the same colors. A hard proof gets closer: it's printed on paper. But only a press proof — ink on the real stock, on the real machine — tells you what will actually come off the run. As one prepress reference puts it, a contract proof is just "a color reference guide for adjusting the press before the final press run." It guides the run. It is not the run.

Map that onto your work and the failure mode jumps out. Your preview is a soft proof. Your staging environment is a hard proof — closer, still not the thing. Production is the press. Every artifact you approve before launch is rendered under different conditions than the version your users get. So here's the sacred cow worth challenging: "it's been reviewed and approved" is not the same as "it will be right." Review is good — keep it. But a green review only proves the parts exist and look right in the preview. It can never prove they hold up on the press. That second approval — the one on the real output — is the press check, and most teams skip it.

Why "approved" keeps surprising you

The instinct is to fix this with a better proof — a higher-fidelity mock, a more realistic staging environment. It helps, but it can't close the gap, and the data is blunt about why.

Google's own site-reliability engineers say it plainly in the SRE Workbook: "Your test environments aren't 100% identical to production, and your tests probably don't cover 100% of possible scenarios. Some defects will reach production." They add that "a majority of incidents are triggered by binary or configuration pushes" — that is, the change itself, the one thing your steady-state proxy never contained.

That gap between the proxy and the press is exactly what a press check is built to expose. It gets worse for the ideas you're most sure about. When teams measure their "obviously good" changes on real traffic instead of trusting the preview, most of them don't win. Microsoft found that "roughly one-third of their ideas yield negative results, one-third yield no results, and one-third yield positive results." Netflix "believes that 90% of its ideas are wrong." Google reported that "96.1% of their ideas fail to generate positive results." Every one of those ideas passed a review. Smart people approved the proof. The press disagreed.

This is the counter-intuitive part: the more convincing the proof, the more dangerous it is. A polished mock earns a faster yes — and a faster yes means fewer people are still looking for the gap when it ships. The cost of that gap doesn't disappear; it just moves downstream, where it's most expensive. The 2002 NIST software-errors study found "over half of all errors are not found until 'downstream' in the development process or during post-sale software use." And when McKinsey and the University of Oxford analyzed more than 5,400 IT projects, they found they "run 45 percent over budget... while delivering 56 percent less value than predicted." The proof promised more than the press delivered.

How to run a press check before you ship

A press check isn't a longer review. It's a different kind of check: you stop evaluating the stand-in and start evaluating one real unit, under real conditions, before you commit to the run. Here's how to do it on any launch.

1. Name the real press

Write down the production conditions the proof can't reproduce: real data volume, real devices and email clients, real users, real load, the real network. The proof lies in predictable places — list them first, so you know exactly what your press check has to expose. This is the honest version of a launch readiness checklist — not "did we build the parts," but "have we seen them under load."

2. Pull one real sheet off the line

Produce a single real instance under those conditions. Roll the feature out to 1% of traffic behind a flag. Send the email to a seed list of real inboxes. Open the deck on an actual phone, not the desktop preview. Run the migration against a copy of production-scale data. You are not looking at a preview anymore — you're looking at the first real sheet, the way a printer reviews "the sheets as they come off the press."

3. Put the decision-maker on the real output — together

The person who signs off looks at the real thing, in the same working session, not a forwarded screenshot. This matters more than it sounds, because of the curse of knowledge: the person who built it demos the one path they know works, and it always works for them. A press check breaks that spell — everyone is looking at the same real sheet at the same time, including the path nobody rehearsed.

4. Sign off at zero, not at "looks good"

The press operator doesn't approve a run because it's mostly right. They approve when the color matches, the corrections are verified, and every element is positioned correctly — then both parties keep a signed copy. Borrow the standard: "feels done" is not a sign-off. Approve the press, not the proof, and only when the real output is actually right. (This is the closeout discipline behind the punch list method — finishing is a list, not a feeling.)

5. Keep the signed sheet

Record what "good" looked like: the approved render, the baseline screenshot, the metrics at sign-off. The next run has something to match, and the next argument about "is this right?" has an answer. It's the same logic as the readback rule — a decision isn't real until it's confirmed and written down where everyone can see it.

A press check is the last slice in your Swiss cheese model: every other layer catches problems in the abstract. This one catches them in the real.

The email press check, in one worked example

Email is the cleanest place to see why a press check beats a better preview — because you literally cannot preview your way out of it. According to Litmus, every email you send has "approximately 15,000 potential renderings (and that's using conservative math)" — and by their updated count, "more than 300,000 potential renderings for an email," across "about 1,000 webmail clients... plus roughly 250 mobile email apps."

You are not going to eyeball 300,000 renderings. As Campaign Monitor puts it, "each of these email clients plays by its own rules, meaning they can each render your emails differently" — so "test your emails before you send." That's the entire press check in two lines: the preview can't tell you, so render the real email across the real clients before the full send goes out. The version your team approved in Gmail is a soft proof. The version that lands in a customer's Outlook is the press.

Run the press check where the team can actually see it

Distributed teams have it worse, because the sign-off itself happens on a proxy. Someone drops a screenshot in Slack, three people thumbs-up it asynchronously, and the launch proceeds — everyone approved the proof, and no one ever saw the press. One engineer put the danger perfectly on Hacker News: "When production falls over, but it worked in staging, then staging gave unwarranted confidence."

The category is starting to build for this. On June 4, 2026, Figma shipped "Check designs," which "compares your designs against your design system, flags what's off, and suggests the correct fix" — flagging hard-coded values, contrast violations, and detached components automatically. It's a press check for design vs shipped UI, and it exists because "the approved mock doesn't match what ships" is now a problem big enough to build a feature around.

A remote press check needs three things in one place: the real output, the people who sign off, and a record of what "good" was. That's exactly what a live video session with a shared canvas and contextual AI is for — everyone looks at the real render together, the AI flags the drift the way Figma's checker does, and the approved state gets captured on the canvas. It's the same reason a tech rehearsal beats a stack of green checklists: a checklist proves the parts exist; only a run-through proves they connect. Coommit is built for that live run-through — the press check async tools quietly skip.

The takeaway

WYSIWYG was always a promise the screen couldn't keep, and your preview, your staging, and your demo are all soft proofs — useful, and never the press. The teams that ship clean aren't the ones with the prettiest proofs. They're the ones who insist on seeing one real sheet, off the real press, before they commit to the run.

Build the press check into your launch — name the real conditions, pull one real unit, get the decider on it live, sign off at zero — and "looks good" stops being a gamble. A press check costs you one real sheet; skipping it costs you the whole run. The next time your team is about to ship to everyone, don't approve the proof. Get everyone looking at the same real sheet, at the same time, and approve the press.