Vercel and Next.js
The quote says Next.js on Vercel. That's two decisions, not one.
The short answer
Next.js and Vercel get said in one breath, but they're two products. Next.js is an open-source framework for building websites and applications, and it runs on plenty of hosts. Vercel is the company that maintains it and a hosting platform tuned for it. You can take one without the other.
A quote lands saying your site will be built in Next.js and hosted on Vercel, as though that were one line item. It's two, and they don't commit you to the same things. Telling them apart is most of what a non-technical buyer needs before agreeing to either.
Go deeper
Two products, said in one breath
Next.js is a framework. It's open source under the MIT licence, and it runs on hosts that have nothing to do with Vercel, including servers you rent yourself.
Vercel is a company and a hosting platform. It maintains Next.js, and its platform is tuned to run it better than a generic server does. One company makes the free thing and sells the convenient place to run it.
They arrive together, so separate them yourself. The framework shapes how the code is written and is expensive to reverse. The host is an arrangement, and arrangements get changed by people who don't write code.
What a framework is doing for you
A framework is a pile of decisions somebody already made. Where the code for a given URL lives, how data reaches a page before it's drawn, how all of it gets sent to a browser.
React, the piece underneath, draws interfaces in a browser and stops there. Next.js wraps it with the parts a real site needs anyway.
This matters to a non-technical buyer for hiring reasons, not engineering ones. A codebase built on common decisions can be picked up by somebody who wasn't there when it was written. One built on private decisions can't be.
Server rendering, and who it's really for
There are two ways to get words onto a screen. A server can send a finished page, or it can send a near-empty page plus a program that draws the words once the browser has run it.
The second way is fine on a fast laptop, and it costs you twice. A crawler that receives finished HTML reads the page without running anything. A phone on a weak connection has to fetch and run that program before a single word appears.
Next.js does both, and the choice gets made page by page. A pricing page can be served as finished HTML. A dashboard behind a login can be drawn in the browser, because nobody is trying to rank it.
The browser, or a crawler
What the reader gets
Receives HTML it can read straight away, without running your code first.
Next.js, on a server
Where the work happens
Picks the template for the URL, fetches what that page needs, and returns finished HTML, ahead of time or on request.
Your content and data
Where the facts live
A CMS your team edits, a database, another company's system. The framework reads from these. It isn't where they live.
Where the pair earns its keep
The strongest case is one codebase holding both the public pages and the signed-in product. Same components, same wording, one deploy. When a pricing page has to know whether the reader is already a customer, keeping it in a different system from the product it describes is how it goes out of date.
The second is content that changes without a developer. Copy can live in a CMS your team edits, with the framework reading from it. That's a build decision rather than a property of the framework, so it belongs in the scope.
The third is review. Vercel gives every branch its own URL, so whoever approves copy can read a change before it's live.
When it's overkill
A brochure site. A dozen pages, no accounts, and a marketing lead who wants to fix a typo on a Tuesday. This stack puts an engineering dependency in front of a problem that never had one.
A project where nobody will own the code. With no in-house engineer and no arrangement with whoever built it, a custom codebase is a liability on a delay. Nothing breaks on day one. Then a dependency goes out of support, the build fails on a new machine, and the person who held it in their head has gone.
And a project chosen because the framework is popular. Popularity is a hiring argument, not an architecture argument, and it's fair to ask which one was meant.
Site builder
Your team edits, nobody deploys
Hosted CMS with a theme
Content is yours, the platform isn't
Next.js on a managed host
Your code, somebody else's servers
Next.js you host yourself
Your code and your operations
Nothing to maintain
You own the software
- Nothing to maintain
Site builder
Your team edits, nobody deploys
Hosted CMS with a theme
Content is yours, the platform isn't
Next.js on a managed host
Your code, somebody else's servers
Next.js you host yourself
Your code and your operations
- You own the software
Who has to be available in year two
This is the constraint that decides whether the choice was right, and it's rarely in the proposal. A codebase needs somebody available. Not full time, not urgently, but reliably. Dependencies get updated, and a failed build gets read by somebody whose job that is.
There are two honest versions of that. Somebody in-house picks it up, or there's a standing arrangement with whoever built it. A handover document isn't a third option, however thick it is.
Settle that before the framework question. A business with nobody available in year two is better served by a platform it can't break.
The questions this page doesn't answer
How this compares with WordPress is the comparison most businesses are actually running, even when the proposal never says so. That guide sits underneath this page, and the Webflow comparison sits on the Webflow page.
If neither is your question, ask a narrower one: what would have to be rewritten to move this build off Vercel?
Worth knowing before you start
Ask whoever's quoting which pages get rendered ahead of time and which get drawn in the browser. If they've thought about it, that's a one-minute answer, and it tells you whether search came up before the build.
Ask what happens to a wording change after launch. If the answer involves a developer and a deploy, somebody chose that, and it's cheaper to change now than in six months.
Get a one-page list of every host-specific feature the build relies on. That's your portability map, and if nobody can write it, that's your answer.
Vercel documents that preview deployments are excluded from search indexing by default and that every branch gets its own URL. Use that for copy review.
Common questions
No. Next.js is an open-source framework, and it runs on a rented server, your own hardware, or another host. Vercel maintains the framework and sells a platform tuned to run it. Using one doesn't oblige you to use the other.
No. Next.js publishes a self-hosting guide, and running one server is well-trodden ground. Running several is an ongoing operations job. Worth doing if you employ people who run infrastructure, and not if you don't.
The page is assembled into finished HTML before it reaches the browser, so a crawler and a phone on a weak connection both get something readable without running your code. Drawing it in the browser instead is fine behind a login and costly on a page you want found.
Only if the build was made that way. Content can sit in a CMS your team edits, with the code reading from it. If the words are written into the code, every edit becomes a release, and somebody chose that.
Usually. The test isn't how many pages you have, it's whether any of them has to know who's looking at it. If none do, and nobody in your business will own a codebase, a platform your team can edit serves you better.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.