Vercel: what it is great at, and where it stops

TL;DR

• Vercel is a deployment and compute platform that makes shipping a modern web app close to effortless: connect a repository and every push builds, gets a preview URL, and goes live on a global edge network.
• It is famous for frontend and Next.js hosting, and that is still where it shines, but it has grown into a full compute platform that runs backend frameworks like Express, FastAPI, and NestJS natively, with little or no config.
• The developer experience is the product. A live preview for every change and sensible defaults are why small teams ship fast on it.
• The honest edges are about the managed model: usage-based pricing that grows with you, some lock-in through platform-specific conveniences, and serverless constraints such as a request and response body size limit you design around.
• This site runs on Hugo deployed to Vercel, meets WCAG 2.1 AA, and scores 100 in Lighthouse, so this is a tool we use, not one we are selling you.

Vercel is one of the easiest ways to put a modern web app on the internet, and that is not an exaggeration. It has also changed a lot, and some of what people confidently repeat about it is a few years out of date. We use it, we like it, and we will still tell you when your project wants something else. Here is the honest shape of what it is good at and where the real edges are, as the platform actually is now rather than as it used to be.

What Vercel actually is

Vercel turns a Git repository into a running, deployed application. You connect the repo, and from then on a push becomes a deployment: it builds the project, puts the result on a global edge network, and hands you a URL. The company also maintains Next.js, the React framework, which is why the two fit together so tightly and why so much writing about Vercel is really writing about Next.js. They are not the same thing, and that distinction matters when we reach lock-in.

The out-of-date mental model is that Vercel only runs “the frontend” and a few small functions beside it. That was closer to true once. Today it is a general compute platform: alongside static and server-rendered pages, it runs full backend frameworks like Express, FastAPI, NestJS, and Hono natively, usually with no configuration, and its functions can stream responses, hold connections open, and run far longer than the old serverless stereotype allowed. Reach for Vercel’s documentation for the current specifics, because the exact limits, runtimes, and managed services move, and quoting numbers that are wrong by next quarter helps nobody.

What it is genuinely great at

Framework hosting, especially Next.js

If you are building with Next.js, Vercel is the path of least resistance, and that is by design. The framework’s features map onto the platform without you wiring anything up. Other frameworks are well supported too, and for most of the popular ones the build settings are detected for you. The practical effect is that a developer can deploy a real app without first becoming an infrastructure engineer. That is a genuine saving, not a marketing line.

A live preview for every change

This is the feature we would miss most if it vanished. Open a pull request and Vercel builds it and hands back a live URL for that exact version of the site. A designer can look at the real thing in a browser, a founder can click through a feature before it merges, and a reviewer can test the change instead of imagining it from a diff. Review stops being a conversation about code and becomes a conversation about the running site. For a small team that difference is worth a lot, because it catches the misunderstanding while it is still cheap to fix.

Edge delivery and a good default for performance

Vercel serves content from a global network, so a visitor tends to be served from somewhere near them rather than from one distant origin. Static assets are cached and delivered quickly by default, which gives you a sensible performance starting point before you have tuned anything. That matters because speed is not a vanity metric. Google measures it, users feel it, and it feeds how a page ranks. The Core Web Vitals are the published yardstick for this, and a site that loads fast and stays stable while it loads is doing well against them. A fast default does not excuse you from measuring, but it does mean you start from a better place than a single under-powered server gives you.

A developer experience that gets out of the way

For most projects the amount you have to configure is close to nothing. Connect the repository, pick the framework if it is not detected, and deploy. You are not writing pipeline YAML or managing build servers to get a site live. For a studio our size, and for early-stage teams generally, that is time returned to the actual product.

We are not describing this from the outside. This site, the one you are reading, is built with Hugo and deployed to Vercel. It meets WCAG 2.1 AA, scores 100 in Lighthouse, and uses no cookies, analytics, or third-party trackers to get there. We hold our own site to the bar we would hold yours to, which is the only honest way to recommend a tool.

Where the real edges are

A fair appraisal has to cover the edges, because that is where the expensive surprises live. None of this is a knock on Vercel. It is a platform with a shape, and the trouble starts when you commit to it without having looked at the shape.

It is a managed, usage-priced platform

You are renting convenience, and convenience is metered. Usage-based pricing is friendly when you are small and can climb in ways that surprise you as traffic, bandwidth, and compute grow. We will not quote figures, because they change; the point is to read the current pricing against your real projected usage rather than today’s usage, and to do it before a launch rather than after the first big bill. This is not unique to Vercel. It is the standard trade for any platform that removes the operational work: you pay for the work you are no longer doing.

You design around the platform’s model

Modern Vercel is more capable than the old “tiny stateless function” caricature. Functions can run for minutes rather than seconds, stream output, and hold open connections including WebSockets, and its compute model reuses instances to cut cold starts. That removes a lot of the constraints people still cite. What remains is real and worth designing for: there are limits on how large a single request or response body can be, so large uploads go to object storage rather than through a function, and you are still composing an app out of deployed functions and managed services rather than running one long-lived server you shell into. For most web apps that is a good trade. For a workload that genuinely wants a persistent, always-resident process you control, or heavy portable compute, a container you run yourself can be the better home. We wrote about the shortest path to a running service in the Railway post, and about containers in when a small team actually needs Docker.

Data services and lock-in

Vercel no longer ships its own first-party database as the default. Instead you provision data services, such as databases, queues, and object storage, through its marketplace of providers, which is flexible but means your data layer is a decision you make rather than one that comes bundled. And then there is lock-in. Next.js itself is open source and can run elsewhere, which is genuinely reassuring. But some of the smoothest conveniences are smoothest because they are done the Vercel way, and the more of them you lean on, the more a future move costs. That is a reasonable trade to make with your eyes open. It is a bad one to make by accident. Our own rule, on every engagement we take, is that you own the repository and the deployment, so if you ever want to leave a platform, the work goes with you.

How we think about it for a project

When a project is a website or a web app, Vercel is usually where we would reach first, precisely because it gets a good, accessible, fast site live without ceremony and gives everyone a preview URL to react to. When the centre of gravity is heavy, always-on background compute, or a workload that wants a server you fully control, we will say so and point at something that fits better, even though that means talking past the easy answer. Picking the right tool is the job. Defaulting to the familiar one, or to a stale idea of what a tool can do, is how projects end up paying rent on a shape they do not use.

The same discipline we apply to hosting we apply to the build itself. A site deployed on a fast edge network can still be slow or inaccessible if it was built carelessly, which is why we build accessible and performant from the first commit rather than retrofitting it later. If you want the reasoning, we laid it out in accessible from the start costs less.

If you want this done right

Vercel is a great place to ship a web app, and used for what it is good at, it lets a small team put a fast, accessible site in front of real users quickly, with a live preview for every change along the way. The edges that matter are the managed-platform ones: cost as you scale, the services you bolt on, and how much platform-specific convenience you want to depend on. Knowing those going in is most of the value.

That is the kind of call our website work is built around, and you can see the full shape of what we do on the services page. If you want a site built accessible and fast and deployed somewhere sensible, with the repository handed over as yours, start a website project and tell us what you need. A real person reads every message.