Draft, not yet published
Vercel hosting costs once your AI-built app starts scaling
7 July 2026· 6 min read · by Stackbastion
Vercel got your app live in minutes, and the free hobby tier felt like magic. Then traffic grew, or you shipped a feature that hits an API a lot, and the bill started doing things you didn’t plan for. Now you want to know what Vercel really costs when an app scales, and whether it’s still the right home.
Vercel is an excellent product for what it’s built for: frontend and edge-rendered apps that want zero-config deploys. The question isn’t whether it’s good. It’s whether its pricing model fits your app’s shape as it grows.
How Vercel bills
Vercel’s plans set a base price and included allowances, then charge for usage past them. The plans, roughly:
| Plan | Base | Included, roughly | Who it’s for |
|---|---|---|---|
| Hobby | €0 | Personal, non-commercial, limited usage | Side projects |
| Pro | ~$20/user/mo | Bandwidth, function runtime, builds up to a point | Small teams, live apps |
| Enterprise | Custom | Higher limits, SLAs, support | Larger orgs |
The base is the easy part. The bill’s real shape comes from usage: bandwidth, function execution, image optimization, and a few newer line items. That’s where a scaling app gets surprised.
The line items that grow with you
- Bandwidth (data transfer). Every page, asset, and API response served counts. A content-heavy or image-heavy app moves a lot of bytes. Past the included amount, you pay per GB.
- Function invocations and duration. Serverless and edge functions bill on how often they run and how long each run takes. An app that calls a function on every request, or runs slow functions, racks this up fast. AI-built apps are often heavy here, because the generated code tends to do work in functions that could be cached or moved.
- Image optimization. Vercel optimizes images on the fly, billed per source image transformed. A gallery or catalog app can generate a surprising number of these.
- Build minutes. Frequent deploys, especially of a large app, eat build time.
- Edge requests and other newer meters. Vercel has been unbundling more usage into its own meters. Read the current pricing page, because the shape shifts.
The pattern: Vercel’s cost scales with activity, not just with having the app online. Two apps on the same plan can bill wildly differently depending on how chatty they are.
Where AI-built apps get bitten
Code generated by an AI builder often works but isn’t tuned for a usage-based host. Common patterns that inflate a Vercel bill:
- No caching. The generated code re-fetches and re-renders on every request instead of caching. On a flat server you’d never notice. On Vercel, every uncached request is a function invocation you pay for.
- Serving images through the app instead of a CDN or optimized pipeline, so bandwidth and optimization costs pile up.
- Chatty client code hitting your own API functions dozens of times per page load.
- Slow functions doing database work that could be a single query, billed by duration.
None of this is Vercel’s fault, and none of it is catastrophic. But it means the same app that costs $20 a month on a flat VPS can cost several times that on Vercel, because Vercel charges for exactly the things unoptimized code does a lot of.
The predictability trade
Here’s the honest comparison, for a small-but-growing app:
| Vercel Pro | Flat VPS (Hetzner/similar) | |
|---|---|---|
| Base cost | ~$20/user + usage | ~€7 to €20/mo flat |
| Cost under a traffic spike | Rises with usage | Stays flat until you outgrow the box |
| Setup effort | Near zero | You configure the server |
| Backups, monitoring | Add-ons / DIY | DIY |
| Predictability | Low, usage-based | High, flat |
| Best for | Frontend, edge, spiky traffic | Steady traffic, cost control |
Vercel’s strength is also its billing risk: it scales seamlessly, and the bill scales with it. For a spiky app that occasionally goes viral, that elasticity is worth paying for, you’d rather absorb a big bill than fall over. For a steady app with predictable traffic, a flat server is cheaper and the bill never surprises you. If you’re weighing hosts, we compared Render vs Railway vs Hetzner too.
What to do before you leave
Don’t reflexively flee Vercel over one scary bill. First:
- Turn on caching. Cache what can be cached. This alone often cuts function and bandwidth costs hard.
- Move images to a proper pipeline or CDN and stop optimizing on every request.
- Read the usage breakdown in your Vercel dashboard. Find the one meter driving 80% of the bill and fix that first.
If after that the bill’s still high and your traffic is steady, then a flat host is a rational move. But fix the caching first, because you’ll carry those same inefficiencies to the next host if you don’t.
A worked example
Say your app serves 100,000 page views a month, and each page load fires 5 uncached calls to your own API functions. That’s 500,000 function invocations, plus the bandwidth for every response, plus image optimization on whatever images the page shows. On Vercel, all three are metered, so the bill tracks that activity directly.
Now cache the API responses so a page load fires 1 function call instead of 5, and serve images from a CDN. Same traffic, but you’ve cut function invocations by 80% and moved image work off the meter. The bill can drop by more than half without changing a single visitor. On a flat VPS the original waste would have cost you nothing, because the box doesn’t charge per invocation. That’s the core difference: Vercel prices exactly the things unoptimized code does most, so tuning pays back fast on Vercel and barely matters on a flat host.
Or, we do it for you
If your app has settled into steady traffic and you want a predictable flat bill instead of a usage meter, we run it on Hetzner with tested backups, monitoring, and a named human on call, for one price that doesn’t spike when you get a good week. See our pricing.
FAQ
Why did my Vercel bill jump when traffic went up?
Because Vercel bills on usage: bandwidth, function runtime, and image optimization all scale with activity. A traffic spike multiplies all three at once. If your code isn’t caching aggressively, each extra visitor triggers billable work that a flat server would have absorbed for free.
Is Vercel more expensive than a VPS?
For steady, predictable traffic, usually yes, sometimes several times more, because you pay per usage instead of a flat rate. For spiky traffic that occasionally spikes hard, Vercel’s elasticity can be worth it, since it scales without you touching anything. It depends entirely on your traffic shape.
Will optimizing my code lower my Vercel bill?
Often dramatically. The biggest wins are caching responses so functions don’t run on every request, and serving images through a CDN instead of optimizing them repeatedly. Check the usage breakdown, find the top meter, and fix that. AI-generated code especially tends to skip caching, which usage-based hosts punish.
Should I move off Vercel to save money?
Only after you’ve fixed caching and checked the usage breakdown, and only if your traffic is steady rather than spiky. Moving an unoptimized app to a flat host carries the same inefficiencies with it. Fix the code first, then decide whether a predictable flat bill fits your app better than usage-based pricing.