Make the preview URL the review interface

Someone from product opens the pull request you asked them to check. They see 142 added lines, 38 removed, across seven files, syntax-highlighted in red and green. There is a button marked Files changed.

They scroll. They look for something they can have an opinion about. They find the copy string they recognise, leave a comment about the wording, and approve.

You did not learn anything, and neither did they. That is not a failure of their skill. It is a failure of the interface you handed them.

The diff was never a good review interface

Not even for the people it was built for. A study of what reviewers actually struggle with put it bluntly: “all current code review tools we know of show a highlighted diff of the changed files to a reviewer with no additional tool support.” The same work notes that these tools “deliver only basic support for the understanding needs of reviewers”, offering diffing, inline comments and syntax highlighting, which run out fast against anything complex.

Engineers cope because they can reconstruct the running program in their heads from the diff. That reconstruction is the skill, it takes years, and it is exactly the thing your product manager, designer and support lead do not have and do not need to acquire.

When epilot moved their whole company onto shipping code, automatic preview environments were one of the pieces of infrastructure that made it work at all, and the reason they gave was not about judgment. It was about access: if contributors cannot see and interact with their change, they cannot meaningfully contribute.

The move

Every pull request gets a URL that a non-engineer can open, use, and form an opinion about without asking anyone for help.

Note what that sentence does not claim. It does not say their judgment beats yours. It says they currently have no way to exercise any judgment at all, and that this is fixable in an afternoon.

Where their judgment genuinely is better is narrower and worth being honest about: whether the thing feels right to the person who will have to sell it, support it or explain it. That is a real contribution and you are currently making it impossible to offer.

What it looks like

BEFORE                             AFTER

  3 checks passed                    3 checks passed
  +142 −38 across 7 files            Preview   https://pr-482.preview.acme.dev
                                     Sign in   ana@acme.test  (seeded account)
  [ Files changed ]
                                     Changed routes
  reviewers: you                       /pricing            2 visual diffs
                                       /checkout/step-2    no visual change

                                     Data      forked from snapshot, never prod
                                     Expires   when this PR closes

Four things in the right-hand column, and the last two matter as much as the first two.

The URL has to need no local setup and no VPN. The seeded account matters because “log in as someone” is where most non-engineers stop. The changed routes list is what turns “go and look at the site” into a five-minute task instead of a scavenger hunt. And the expiry is what stops you accumulating forty forgotten environments holding live credentials.

Northflank documents both halves of the data question directly: you can “fork your database from a snapshot to restore pre-seeded data more efficiently”, and “The preview environment is automatically deleted when the PR is closed without merging.”

Check who can actually open it

This is the step everyone skips, and it silently undoes the whole move.

Vercel’s comments feature is “enabled by default on all preview deployments, for all account plans, free of charge”, with one catch stated in the same sentence: “The only requirement is that all users must have a Vercel account.” Inviting external users to view and comment is a Pro or Enterprise capability, and Pro is $20 a month per seat. Their Hobby tier is explicitly “restricted to non-commercial personal use”, so it is not an option for your company regardless.

Screenshot diffing prices separately again. Chromatic is free at 5,000 billed snapshots a month, then $179 a month for 35,000 on Starter and $399 for 85,000 on Pro, with overage at $0.008 per snapshot. Their TurboSnap only captures stories with associated code changes, which is what keeps that number survivable.

None of this is expensive. All of it is a decision somebody has to make on purpose, and the failure mode is not cost. It is discovering in week three that the person you built this for hits a login wall.

What it costs

Here is the part that should make you careful, because a preview environment is a machine that runs code from a pull request, and pull requests come from outside.

In a published advisory titled “Preview Deployments are vulnerable to Remote Code Execution”, the summary is as clear as these things get: “An unauthenticated preview deployment vulnerability in Dokploy allows any user to execute arbitrary code and access sensitive environment variables by simply opening a pull request on a public repository.” Fork the repo, open a pull request containing code that prints the environment, and the platform deploys it for you.

So two rules, and neither is optional. Previews get their own secrets, scoped to the preview environment and useless anywhere else. Previews never get production data, which is what the snapshot fork is for. A preview environment holding a real database credential is not a review interface, it is a public endpoint with your production keys in it.

Add one more, less dramatic: for public repositories, do not build previews automatically from forks. Require a maintainer to approve the run.

Try this week

Open your most recent merged pull request and try to answer one question: could someone who does not read code have told you whether it was right?

Then do the smallest version. You do not need a full-stack preview platform to start. If your frontend is static or server-rendered, Vercel and Netlify will give you per-pull-request URLs almost for free, and that alone covers most of what a designer or product manager wants to look at.

Add one line to your pull request template: Preview: followed by the URL, and Sign in as: followed by a seeded account. Then ask the person who last approved a diff without reading it to review the next one properly, and watch what they catch.

They will find something. It will probably be something you would have shipped.