Vercel or Netlify: choosing where the frontend is served

Both take a repository, build it elsewhere and serve the result from many machines; for a static site they are near-interchangeable. The difference appears when the frontend needs something that runs on a server, and again the day you want to leave. Vercel fits an application whose server layer is part of the product; Netlify fits pages, forms and redirects, with the data in a system you already run.

What is actually being deployed?

Not a folder of files but an artifact: the platform reads the repository, builds it in a clean environment, keeps the output and serves it from many locations.

What differs is what the artifact contains. A pure static build is HTML, CSS, images and JavaScript. When a page must answer with data — an order looked up by number, a delivery price that depends on the wilaya — the artifact also contains code the platform runs per request. At that point the two stop being the same product.

Do you need server functions, or only files?

A contact form does not need one: a form service takes the submission, forwards it and keeps a copy, which covers most brochure sites.

A function earns its place when the submission must write into the stock system, hold a credential the visitor must never see, reserve a quantity, or call a provider that requires a secret key. Netlify runs functions properly. The difference is architectural: on Vercel the framework's server layer and the deployment are designed together, so routing, caching and per-request code share one configuration; on Netlify the function sits beside a static output as a separate concern. Fine for a handler, friction when half the pages render per request while the other half are pre-built and the cache rules for both must agree.

Which pricing model fits the way you work?

A build-minute model charges for producing the artifact: builds are capped, reproducible, cheap when the site changes a few times a week. A fixed server charges for a machine that stays on whether or not anyone deployed.

What matters is the work each assumes. A site that changes with a campaign is a build, published and forgotten. A process that wakes at night to send invoices, holds a queue, or keeps a connection open for a workshop screen is a machine with state, and a function that must finish inside a time limit and remembers nothing between calls is the wrong place for it.

Are branch previews worth the move on their own?

For a team of more than one, yes. Every branch and pull request gets its own address, built from that commit, with its own environment, so a client can open the Arabic page of a change on a phone before it merges.

The gain is not deploy speed. It is that review happens on the artifact rather than on a description, and a problem costs a comment instead of a rollback. For a one-person site that changes monthly, it is worth less than it sounds.

Where does the lock-in actually live?

Not in the vendor's name. In how much of the site is written in the host's own vocabulary: redirects in one vendor file, headers in another, image resizing that exists only at the edge, forms that post to a vendor endpoint.

None of those is a trap alone. Together they decide what leaving costs. A site of HTML plus one build command moves in an afternoon; a site whose routing, redirects, image pipeline and forms are all vendor configuration moves as a rewrite.

The exit test fits in a line: can a developer who has never seen the repository rebuild the site on a plain server — one process, one reverse proxy, the same variables — in a day, without asking the vendor? If yes, the lock-in is small enough to ignore. If no, you bought a format rather than a host.

What does performance look like from North Africa?

A content network helps when a copy of the page is near the visitor, and both keep points of presence in Europe, so from Algiers the two land close together. The brand does not decide the first byte; the nearest point of presence does, and beyond it the gap between them is smaller than the gap made by one uncompressed hero image.

What decides how a page feels on a phone in a wilaya is weight and work: fonts that load before the text, JavaScript that runs before the page answers a tap, images sized for the screen. The Core Web Vitals guidance is the measure to hold either platform to.

How do the two compare on the decision that matters?

Decision	Vercel	Netlify
Best fit	A framework application whose server layer is part of the product	Pages, forms and redirects, with data elsewhere
Server code	Designed in; shares routing and cache with the build	A function beside the static output
Previews	Per branch and per pull request	Per branch and per pull request
Exit	Rebuild the server layer elsewhere	Move the files, rewrite the handlers

Read the table by row: the exit row is the one that will cost you later.

How do you decide in an afternoon?

1. List the pages, and mark the ones that must read data at the moment of the request.
2. If none do, choose on previews, DNS and support, not on functions.
3. If some do, write the one function you cannot avoid and check it against each platform's documented limits: run time, memory, cold start.
4. Count the settings that would live in a vendor file. That count is the exit bill.
5. Deploy the same branch to both, open the Arabic page on a phone, compare what the browser downloads.
6. Write the exit page before signing: build command, variables, DNS records, and the person who could execute it.

Where this goes wrong

• A static site is treated as an architecture decision. Weeks go into comparing runtimes for a site that will never run one.
• One function becomes the backend. A form handler is joined by a session, then a queue, then a nightly job, and nobody reopens the question.
• Redirects and headers live only in the dashboard, so no file says where the old URLs go.
• Variables are typed into a vendor form and nowhere else. The rebuild starts by hunting for the mail key.
• DNS moves with the site. The apex is repointed, the mail records follow, and the inbox stops the same afternoon.

What this does not cover

No prices and no plan limits: both vendors revise allowances, and a figure written here would be wrong before the piece aged. It assumes the repository is the source of truth and that someone on your side reads the build log. We deploy on both platforms, resell neither, and take no commission from either vendor.

We build frontends that can be rebuilt elsewhere — repository, build settings, variables and DNS written down — so the second deployment is an afternoon instead of a project.