VercelProduct Thinking6 min readA URL that argues better than a screenshot
Every push becomes a live environment someone can click.
- The surface
- Pushing a branch, the preview deployment that appears, the bot comment on the pull request, and the promote to production step.
- What the user wants
- I want the people reviewing my change to look at the real thing running, without anyone setting up an environment.
Connect once
Setup connects a Git repository and, for common frameworks, detects the build settings rather than asking the user to declare them.
Convention over configuration
The configuration screen is where most infrastructure products lose the person who just wanted their site online. Detecting the framework means the default path needs zero decisions. The settings remain available for the minority who need them, which is the correct order.
A deployment per push
Every commit to any branch produces its own build at its own persistent URL, rather than a single shared staging environment that the newest branch overwrites.
Remove the shared resource
A single staging slot creates queueing, and queueing creates batching, and batching makes every change harder to review. Giving each commit its own address deletes the contention entirely. It also means an old preview stays valid as evidence of what was reviewed.
The comment on the pull request
A bot posts the deployment status and the preview link into the pull request thread, updating in place as builds complete.
Meet the workflow where it already lives
Nobody adds a second tab to their review routine voluntarily. Pushing the link into the thread the reviewer already opened means adoption costs nothing. Updating the same comment instead of posting new ones respects the thread it is borrowing.
The build log
A failed deployment surfaces the build output, and the failing step is reachable from the same status that reported the failure.
Diagnose where you notify
A red status with no path to the cause makes the user hunt, and hunting is where they blame the tool. Linking the failure directly to its log keeps the debugging loop inside one click. The log is raw on purpose, because the user's mental model here is a terminal.
Promotion and rollback
Merging to the production branch deploys to production, and a previous successful deployment can be promoted back from the dashboard.
Make the undo as cheap as the do
Teams ship carefully in proportion to how expensive a mistake is to reverse. When rollback is one action on an artifact that already exists, the cost of being wrong drops and release frequency rises on its own. This is a psychological change delivered through an infrastructure feature.
Preview as a review object
The preview URL is shareable with people who do not have access to the codebase, which puts designers, writers and stakeholders into the review loop.
Widen the reviewer pool by lowering the entry cost
Most useful feedback on a change comes from people who will never read a diff. A link they can open on their phone converts them from a meeting into a comment. The product grows by making non-engineers dependent on an engineering workflow.
A queue, or a copy each
What not to copy
- Usage pricing is hard to forecast before you are exposed to it. Bandwidth and function invocation costs are legible after a traffic spike and vague before one, and that asymmetry lands on the customer.
- Preview URLs are public by default on many setups, which means a branch containing unreleased work or seeded data is one guessed link from being read. Password protection exists and sits behind a plan.
- Previews run the frontend honestly and the data layer approximately. Reviewers approve behaviour against a database that does not match production, and the difference surfaces after merge.
- The convenience is the lock-in. Framework detection, routing conventions and platform-specific primitives make a later move to generic hosting a rewrite, and the cost is invisible on day one.
The takeaway
If review is slow, check whether people are queueing for a shared resource you could just give everyone a copy of.
Finished the teardown? Bank it and the day counts toward your run.
Where the principles come from
- Accelerate (deployment frequency and lead time), Nicole Forsgren, Jez Humble, Gene Kim
- The Design of Everyday Things (feedback loops), Don Norman
- Growth.Design case studies, Growth.Design
Written from public behaviour of the product, not from inside it. Interfaces change often, so treat the flow described here as of the time of writing and check the live product before quoting it.