Predictable deploys

The live site is not the product of accumulated manual edits to a running server. It is the output of a build from a specific commit in the Git repository. That means the live site is always traceable: you can look at the repository and know exactly what code is running in production, when it was merged, and who approved it.

On a server that has been manually edited over time—files uploaded via FTP, settings changed in a WordPress admin, plugins activated and deactivated—the live state and the development state drift apart. It becomes hard to reproduce the production environment locally, and hard to know what is actually running. That problem does not exist when every deploy comes from a clean build.

Vercel's build logs record what happened at every deploy: which commit triggered it, what the build output was, and whether any errors were encountered. If a deploy introduces a problem, the previous working version is one click away in the Vercel dashboard—or one revert commit in Git.

Every branch or pull request in the repository can automatically get its own preview deployment on Vercel. The URL is stable for the life of that branch, updates when new commits are pushed to it, and is accessible to anyone with the link—no VPN, no staging server credentials, no build machine to spin up.

This makes alpha testing straightforward. Internal team members or stakeholders can review a feature on a real URL before it is anywhere near production. Feedback can be given on the actual built experience, not a screenshot or a local demo that requires the reviewer to install software.

Beta testing works the same way. A trusted client or a small group of users can be given the preview URL for a new feature branch. Their feedback comes in before the merge, which is the right time to make changes—not after the feature is live and rolled back becomes a bigger operation.

The preview and the production build are produced by the same pipeline from the same configuration. What the reviewer sees on the preview URL is what users will see after the merge. There is no 'it worked on staging but broke in production' caused by environment differences.

In a traditional setup—especially one involving a separate staging CMS or a manual FTP-based deploy—the path from 'should we include this feature?' to 'someone can try it in a browser' can take days. The developer builds locally, requests a deploy to staging, waits for the process, shares credentials, and waits for feedback.

With the Git and Vercel workflow, that path is: implement in Cursor, push the branch, and share the preview URL—measured in minutes once the build completes (typically under two). The decision to ship or iterate is made on the actual feature in a browser, not on a written description of it.

This compresses the feedback loop in a way that changes how features are evaluated. Early previews are cheap to produce and throw away. The team can try five different directions before committing to one, without each attempt requiring a staging deployment and a day of waiting.

Work in progress stays on a branch. The main branch—the one that triggers production deploys—only receives changes through a pull request. A pull request is a formal request to merge, with a diff showing exactly what will change, a space for comments and review, and an approval step before anything moves.

This is the point where code review happens: checking for logic errors, catching copy mistakes, confirming that the feature matches what was agreed in the client brief. The branch's preview URL is linked in the pull request, so reviewers can click through the actual experience while reading the diff.

Branch protection rules on the Git host can enforce that a pull request has at least one approval, that automated checks pass, and that the branch is up to date with main before a merge is allowed. These are guardrails that prevent a hasty push from reaching production without review.

No deploy pipeline prevents all mistakes. What predictability provides is a clear path back. Vercel keeps a history of all previous deployments, each tied to a commit. If a production deploy causes an issue, promoting the last known-good deployment takes seconds and does not require a developer to be at a machine running Git commands.

At the Git level, reverting a merge is a standard operation that creates a new commit undoing the change. The revert goes through the same pull request and preview process as the original feature, so the rollback is also reviewed and traceable—not a panicked direct edit to a live file.

Because the live site is always the product of a clean build, there is no partial state to reason about. Either the problematic code is in the build or it is not. That binary clarity makes incident response faster than debugging a server that has been edited in place.

A WordPress site's state is split between the file system (theme files, plugin files, wp-config) and the database (posts, settings, plugin configuration). Deploying a change often means updating files on the server while the database retains settings from the previous version. Keeping these in sync is a manual coordination task that many small sites simply do not do well.

WordPress staging plugins can replicate content between environments, but they are an additional layer of complexity rather than a built-in guarantee. Migrating a database between staging and production, maintaining content parity, and making sure plugin settings transfer correctly are recurring friction points that the Git and Vercel model sidesteps entirely.

In the Next.js model, 'deployment' means running a build from a commit. The entire site—pages, API routes, configuration—is produced from that build, and the environment variables set in Vercel complete the picture. There is no database of CMS content to migrate separately, and no server-side state that can drift from what is in the repository.