Your Vercel Preview Deployed. That Does Not Mean It Works.

The failure

Your pull request shows a green Vercel deployment. The preview URL loads. Someone merges.

Three hours later, support hears that checkout cannot complete — or that login rejects valid credentials — or that a multi-step form loses state on the last step.

Nothing about the green deploy was lying. The build compiled. The platform served HTML. The customer-critical workflow was still broken.

Build success is not behavioral correctness

A deployment pipeline answers a narrow question: Did this artifact start successfully in an environment?

It does not answer:

• Can a user sign in and stay signed in?
• Does add-to-cart still update totals?
• Does the form submit reach a real confirmation state?

Those are browser-level, stateful, multi-step questions. Unit tests and compile checks are necessary. They are not the same question.

Why the preview URL matters

Preview deployments create a uniquely useful boundary:

1. The code under review is reachable at a concrete URL.
2. Production is not yet exposed to that change.
3. The merge decision still sits in the pull request.

That combination — real build, isolated URL, pre-merge decision — is where critical-flow verification belongs. Endia’s preview docs describe treating the preview URL as the base URL for recorded browser flows (preview deployment docs).

What a critical flow is

A critical flow is any journey where failure is immediately expensive:

• money cannot move (checkout / payment)
• access is wrong (auth / session / protected routes)
• work is lost (wizards, uploads, scheduling)

You do not need fifty of them. You need the few journeys your product cannot afford to discover are broken from customers.

Endia’s public examples library maps nine of these journeys to concrete checks — including authentication, checkout, and multi-step forms — as demonstration workloads, not customer case studies.

What common controls miss

| Control | What it proves | What it misses | | --- | --- | --- | | Compile / typecheck | Code builds | Runtime UX | | Unit tests | Isolated logic | Browser orchestration | | Deploy status | Platform accepted the build | User can complete the journey | | “I clicked around once” | Anecdote | Repeatable evidence on every PR |

The practical model

Treat merge as a four-step decision, not a vibe:

1. Deploy — preview is reachable.
2. Verify — run the recorded critical flow against that preview URL.
3. Inspect evidence — screenshots, step trace, failed assertion context.
4. Merge — only when the journey completed (safe to merge); otherwise treat as regression detected.

That is a merge signal derived from execution outcome — not a decorative badge.

Limitations

• This article does not claim a measured percentage of teams that ship broken checkout after green deploys.
• Preview verification still requires repeatable fixtures and stable test data.
• A green critical-flow check does not prove every edge case in the product.

Checklist

• [ ] Name the 1–5 flows that would hurt if broken tomorrow.
• [ ] Confirm each PR’s preview URL is the verification target.
• [ ] Require evidence (not a verbal “looked fine”) before merge.
• [ ] Distinguish infrastructure failure from product regression when interpreting results.