Vercel

Vercel is a cloud platform for deploying and hosting web applications, built by the team behind Next.js. You connect a Git repository, and every push gets built and deployed automatically, with a preview URL for each branch and pull request. It handles the build pipeline, a global edge network for serving your app, serverless and edge functions for backend logic, and the surrounding pieces (environment variables, custom domains, analytics) so you do not run your own servers.

Where it fits

Vercel is for teams shipping front-end-heavy web apps and marketing sites, and it is at its strongest when you are on Next.js, since the two are built by the same people and the integration is seamless. It suits anyone who wants to push to Git and have a live, fast deployment appear without touching infrastructure, plus per-branch preview URLs that make reviewing a change (or handing a client a link before it is live) genuinely easy.

It fits solo builders and small teams especially well, because the whole point is that you do not staff a platform team to keep it running. It is less of a fit if you are running heavy backend workloads, long-running processes, or a stack that wants a traditional always-on server, since serverless functions are not the right shape for that. If your app barely uses the front end and lives mostly in a database or a job queue, Vercel is solving a problem you do not have.

The honest take

The strength is that the deploy experience is close to frictionless: connect the repo, push, and the preview-to-production flow simply works, which removes a category of fiddly DevOps from your day. The edge network makes apps fast by default, and preview deployments change how you review work because everyone sees the real thing, not a description of it.

The trade-offs are real too. Pricing can climb as usage and bandwidth grow, so a project that starts cheap is worth watching as it scales, and you want to understand how the metered pieces are billed before you commit. There is genuine lock-in: leaning on Vercel-specific features means moving away later is work, not a config change. And the serverless model imposes its own constraints (cold starts, execution limits) that you have to design around rather than ignore. None of this is disqualifying, but the convenience has a cost, and you should price it in with eyes open rather than discovering it on an invoice.

INTERVIEW EWOUD: What is your overall verdict on Vercel, and your star rating out of five?

INTERVIEW EWOUD: Is Vercel in your own stack, and if so, what do you actually use it for and why did you pick it?

INTERVIEW EWOUD: What is the one line you would tell a peer who is deciding whether to deploy on Vercel?

Developers and lean teams deploying frontend apps, sites, and serverless functions on a global edge network

This guide gets you from a blank account to a production front end that ships itself: every push deploys, every pull request gets its own live preview URL, and the thing you put in front of customers is fast by default. It is written for founders and small teams who build web apps or marketing sites in a modern framework (Next.js, Vite, SvelteKit, Astro) and want the deploy layer to disappear so they can spend their attention on the product. If you run a portfolio of sites the way I do, Vercel is the layer that lets one person operate many fronts at once.

Getting set up

Start by connecting Vercel to your Git provider (GitHub, GitLab, or Bitbucket) rather than deploying by hand. The whole value of Vercel is the Git integration, and skipping it means you give up the previews, the rollbacks, and the audit trail that come for free. Link the provider once, then import a repository as a Project.

The decision that matters most at setup is the project-per-app model. One repository can hold many apps, but each deployable app should be its own Vercel Project with its own root directory, build command, and domain. This keeps a change to one site from rebuilding and risking another, and it keeps environment variables scoped to where they belong. If you run a monorepo, point each Project at its own sub-directory and let the build only run when files in that path change.

The second decision is environment variables, and you want to get the three scopes right from the start: Production, Preview, and Development. Put real secrets in Production, safe-to-leak or staging values in Preview, and local values in Development. Never paste a production database key into the Preview scope, because preview URLs are shareable and a leaked key there is a leaked key everywhere. Set the variables before your first real deploy, not after a build fails.

Framework detection usually picks the right build command on its own, but confirm it. Set the Node version explicitly if your app needs a specific one, pin the root directory, and add your custom domain early so DNS has time to propagate while you build.

How to actually use it

The core loop is simple and you run it in this order. You push a branch, Vercel builds it and gives you a unique Preview URL, you open that URL and check the change on the real surface, and only then do you merge to your production branch, which triggers the production deploy. The Preview URL is the heart of this. It is a real, running copy of your app on that branch, so you review the actual rendered result, not a screenshot or a promise that it works.

Wire previews into how you review. Every pull request gets a comment with its live link, so a reviewer (or you, an hour later, with fresh eyes) clicks through and drives the change before it reaches customers. Treat the preview as the place where "done" is proven. If the feature has two paths, drive both on the preview before you merge.

Production deploys happen automatically when you merge to your production branch, and this is where you lean on instant rollback. If a deploy misbehaves, you promote the previous deployment back to production in seconds, because every past build is kept and addressable. That safety net is what lets you ship often without fear: a bad release is a thirty-second reversal, not an incident.

Add a custom domain and let Vercel handle the TLS certificate. Once the domain points at the Project, every production deploy serves on it and every preview keeps its own URL, so your live site and your work-in-progress never collide.

Power moves

Use serverless and edge functions to put logic next to your front end instead of standing up a separate backend for small jobs: form handlers, webhook receivers, lightweight API routes, auth callbacks. For latency-sensitive work like redirects, geolocation, or feature flags, run it at the edge so it executes close to the visitor.

Lean on Incremental Static Regeneration when your content changes but not on every request. You serve a static page (fast and cheap) and let it rebuild in the background on a schedule or on demand, so you get static performance with dynamic freshness. This is the move that keeps a content-heavy marketing site quick without a rebuild for every edit.

Treat preview URLs as a sharing tool, not just a review tool. A stakeholder approves a redesign on the actual running page, a client signs off on a feature before it goes live, and nobody needs a local environment to do it. Protect those previews with deployment protection when the work is sensitive, so the link only opens for people you have authorised.

Finally, read the build and runtime analytics. Vercel surfaces real Web Vitals from real visitors, which tells you whether the site is actually fast for the people using it, not just fast on your machine. Set a budget and watch it.

Where it fits your stack

Vercel is the compute and delivery layer; it pairs with a data layer and the rest of your tooling rather than replacing them. A typical growth stack runs Supabase or a hosted Postgres for data and auth, with the app hosted on Vercel calling that data through serverless functions or directly from the client. Your CI lives in the Git provider, and Vercel sits downstream of it as the deploy target, so a green check and a passing preview are two halves of the same gate.

It connects cleanly to analytics and tag managers on the front end, to webhook-driven tools through its functions (Stripe events, form submissions, CRM syncs), and to your domain registrar through DNS. The mental model is: Git is the source of truth, Vercel turns each commit into a running surface, and everything else plugs into that surface.

Pitfalls to avoid

The most common mistake is leaking secrets through the Preview scope. Preview URLs are shareable by design, so a production key set at the wrong scope is exposed the moment you share a link. Scope every secret deliberately.

The second is letting serverless costs creep without watching them. Functions are billed on execution, so a chatty client hammering a route, or a heavy function on a hot path, runs up a bill quietly. Cache what you can, push static where you can, and read the usage.

The third is treating the production push as the test. The point of previews is that you verify before you merge; if you only ever look at the site after it is live, you have thrown away the safety the platform gives you. Drive the preview first, every time.

The fourth is over-stuffing one Project with multiple apps to save setup time. You lose scoped variables and independent deploys, and a change to one site can break or rebuild another. Keep one Project per deployable app.

INTERVIEW EWOUD: How is your Vercel set up across the portfolio , one team with a Project per app, how do you scope environment variables, and what is your custom-domain and DNS arrangement?

INTERVIEW EWOUD: What is the one Vercel workflow you rely on most when shipping (preview-review-merge, instant rollback, on-demand revalidation), and walk me through how you actually run it day to day?

INTERVIEW EWOUD: What is your hard-won tip , the thing you learned the painful way (a cost surprise, a secrets mistake, a build-config trap) that you would tell someone setting up Vercel today?

Vercel is a cloud platform for deploying and hosting frontend applications and serverless backends, with a global edge network and automatic Git-based CI/CD. It is built around modern JavaScript frameworks (it maintains Next.js) and is aimed at developers and teams shipping web apps and sites. Pricing scales from a free Hobby tier to per-user Pro and custom Enterprise plans.