Vercel vs Netlify: What Actually Decides Your Bill

Vercel and Netlify are both function-based platforms built for JAMstack and modern frontend frameworks, but they price things differently, and that catches people out. Vercel is optimised for Next.js and charges more sharply once you scale past the free tier, especially on bandwidth and edge middleware. Netlify is framework-neutral, its overage behaviour is more transparent, and it tends to suit teams running a mix of static sites and non-Next.js frameworks. Neither is "cheaper" in any absolute sense. It depends entirely on your build frequency, traffic pattern and team size.

What actually drives the bill on each platform?

Forget the headline "from £0" pricing on both homepages. What matters is what happens after the free allowance runs out. On both platforms the meter runs on a handful of dimensions: bandwidth served, serverless or edge function invocations, build minutes consumed, and the number of team seats you need. Image optimisation and edge middleware sit on top of that as separate line items on Vercel, and as add-on or included features depending on plan with Netlify.

I've had clients move off both platforms mid-project because nobody read past the marketing page and looked at the actual pricing table. If you want the full line-item breakdown for Vercel specifically, we've laid it out at /vercel-pricing rather than repeating every tier here, because those numbers shift and I'm not going to print stale figures.

How do bandwidth and function invocations actually compare?

Both platforms include a bandwidth and function allowance in their free and entry paid tiers, and both bill overage beyond that. The practical difference is how aggressively each one bills at scale, and how the metering is bundled. Vercel splits things into separate meters for bandwidth, function execution and edge requests, which gives you granular visibility but also means a spike in any one of those can move your bill independently. Netlify bundles bandwidth and function usage more simply within its plan tiers, which is easier to reason about for a non-technical stakeholder but can obscure which part of your app is actually driving cost.

Running a content-heavy site with unpredictable traffic? Check the overage rate on both official pricing pages before committing. That's the number that turns a cheap plan into an expensive one during a traffic spike.

Build minutes: which one punishes slow builds more?

Build minutes are the quiet killer on both platforms. If your project has a slow build, large image pipelines, heavy static generation, a huge number of pages, you'll burn through the included allowance faster than you'd expect. Vercel's build environment is tightly coupled to its own infrastructure and tends to be fast for Next.js specifically, because that's the framework it's built around. Netlify's build system is framework-agnostic, so build speed depends more on your own configuration and caching setup than on the platform doing framework-specific optimisation for you.

For any project with more than a handful of pages, run a real build on both platforms before you commit to a plan. Don't trust a demo repo, use your actual codebase with your actual dependency tree.

How does seat and team pricing change the real cost?

This is the one people forget until the invoice arrives. Both platforms charge per seat once you move past a solo or hobby tier, and for agencies running client sites, seat costs add up fast if every developer and every client stakeholder needs access. If you're an agency managing dozens of client projects rather than one product, it's worth comparing this model against a reseller or VPS setup where you control the infrastructure and don't pay per head, something I've written about in Reseller Hosting vs VPS: The Real Agency Owner's Guide.

Image optimisation: convenient, but who's paying for it?

Both Vercel and Netlify offer built-in image optimisation, and both meter it separately once you go past the free allowance. This is genuinely useful if you're not already running an image CDN, but it's also an easy way for costs to creep up on an image-heavy site without anyone noticing until the bill lands. If your site is mostly static assets and images, check whether a dedicated static host with its own CDN, covered in our static hosting guide, works out simpler and cheaper than paying per-transform on either platform.

Edge functions and middleware: where the real lock-in lives

This is the section that decides a lot of architecture decisions. Vercel's edge middleware and edge functions are built around its own runtime and are deeply tied to Next.js conventions, which is great if you're all-in on Next.js but makes migrating away genuinely painful later. Netlify's edge functions run on Deno and are more portable in principle, though you're still writing to a platform-specific API either way. Neither vendor makes this easy to leave once you've built real logic into their edge layer, so think about how much business logic you want living there before you commit.

What happens when you go over your limits?

Overage behaviour is the part nobody reads and everybody regrets. On both platforms, going over your included bandwidth, functions or build minutes results in metered charges rather than the site going down, which is the good news. The bad news is neither platform makes it trivial to set a hard spending cap by default, so a traffic spike, a bot crawl, or a bad deploy loop can generate a bill you didn't budget for. Set up billing alerts on day one, not after the first surprise invoice. I've seen this catch out clients who assumed a "generous free tier" meant they were safe indefinitely.

Does framework fit actually decide the winner?

Mostly, yes. If you're building on Next.js, Vercel is the path of least resistance, because the framework and the platform are developed in tandem, features land there first, and the deployment pipeline is genuinely tighter. That's the whole case laid out in our Next.js hosting guide, with alternatives if you don't want to be locked into one vendor. If you're running Astro, Hugo, Eleventy, plain static HTML, or a mix of frameworks across different client projects, Netlify's framework-neutral approach removes the subtle bias you get from a vendor optimising primarily for its own framework. Broader JAMstack comparisons across more providers are covered in our JAMstack hosting roundup if you want more than two options on the table.

Preview deploys and how much lock-in you're actually signing up for

Both platforms give you automatic preview deploys per pull request, one of the best workflow improvements either has brought to frontend development, and both do it well. The difference isn't the feature, it's what's underneath it. Vercel's preview infrastructure and edge config are proprietary and Next.js-specific in places, so a heavy investment in Vercel-specific features (image optimisation config, edge middleware, ISR behaviour) makes migrating away a real project, not a weekend job. Netlify's setup is comparatively easier to replicate elsewhere because it leans less on framework-specific magic. Neither is "no lock-in", but Vercel's runs deeper if you lean into its Next.js-specific tooling.

Frequently asked questions

Is Netlify cheaper than Vercel?

Not universally. Entry-level pricing on both platforms looks similar on paper, but the real cost difference shows up in overage rates for bandwidth, functions and build minutes once you scale, and those change over time on both official pricing pages. Check vercel.com/pricing and netlify.com/pricing directly rather than trusting a comparison chart that might be out of date.

Should I use Vercel if I'm not building with Next.js?

You can, Vercel supports other frameworks fine, but you lose the tight integration that makes it worth the premium in the first place. If your stack isn't Next.js, Netlify's framework-neutral approach generally makes more sense, and it's worth comparing both against the wider field in our JAMstack hosting guide before deciding.

Which platform is harder to migrate away from?

Vercel, generally, if you've built heavily on its edge middleware, image optimisation and Next.js-specific integrations. Netlify's approach is a bit more portable by design, though any platform with proprietary edge functions creates some degree of lock-in once you've written real logic against their API.

Are these platforms suitable for WordPress sites?

No, neither is built for a traditional PHP and MySQL stack like WordPress. If you're comparing hosting for a WordPress site, you want a managed WordPress host, and our SiteGround vs WP Engine comparison covers that decision properly. Vercel and Netlify are for static sites, JAMstack and serverless frontend frameworks, not traditional CMS hosting.