Vercel for Solo Founders: Financial Trap or the Golden Path
Despite the controversial title, my goal is to approach Vercel with curiosity. I should be biased against Vercel because of some of their marketing claims about solving the frontend cloud “problem”. Despite this, I’m not worried that I will be “automated” out of the job as an infrastructure engineer. But as an infra nerd, I am more interested in solving the modern limitations in frontend computing. And also as an ally to technical founders, I want to understand the draw of tools like Vercel to minimize time-to-revenue.
Anyways, this is an extremely high level set of ramblings and not a technical deep dive, but I might get into a little of that knowing me.
So admittedly, I am green to Vercel in my professional life.
Why haven’t I used Vercel professionally to this point?
Vercel has been huge the last few years, but hasn’t been on my personal radar. I’ve been working for startups and enterprise tech for the last 10 years. I’ve spent a large portion of that time in the backend, most recently in AWS infrastructure, platform engineering, finops, and devsecops.
I have been deep into B2B SaaS enterprise land for the past few years, helping companies scale from ad-hoc setups created by founders to building infra that can support larger customers and growing development teams, to preparing for SOC2 and setting up zero-trust security.
Maybe I haven’t encountered Vercel due to the scale at which I work, the type of companies I work with, and exactly where I like to work in the stack. Honestly, for a while I wrote Vercel off when I found out it was “just AWS lambdas” under the hood. I already had a lot of experience managing lambdas at several companies.
Vercel kept reappearing though in my own sphere. I often saw posts on “solo entrepreneur tech” subreddits on what tech stack to choose, Vercel was the top technology recommended. It is very popular with indie entrepreneurs and founders.
What is Vercel?
Vercel has evolved to become a massive suite of tools, now including agentic infrastructure, but originally came to the scene to solve the challenges of frontend cloud. Vercel was designed to manage serverless workloads that need advanced caching and availability on the edge. Vercel automates infra and scales automatically based on demand, and integrates seamlessly with CI/CD tools.
What is Next.js?
Vercel’s success could arguably be tied to the success of next.js. Vercel owns next.js. I’ve seen a lot of skepticism about Vercel because of that, but companies have been dumping money into open source for a long time. This is speaking from personal experience of working with companies whose whole success is closely tied to the success of open source. It really isn’t enough for me to write a tool off.
To summarize for my fellow infra devs, the problem next.js solved was the client side rendering problem in the React world. CSR is horrible for SEO. We know crawlers can’t do anything with an empty html page. The site gets placed into the queue for the second wave of indexing in order to run the javascript in a headless Chromium browser, which means the index might not be updated for days.
In my experience working for B2B SaaS products, aka apps you need access to via a login, CSR wasn’t as big of a deal and we were ok with the browser doing the heavy lifting. Users typically spend longer sessions interacting with the UI and navigating between views, have complex states, and require more live data. That’s fine.
But I compare this to my experience working in open source ecommerce, way back to when I first started as a dev over 10 years ago. I can see how not being able to update the index can be crippling for revenue. SEO is more important for marketing the actual tool for B2C.
So learning that next.js became the industry standard for SSR (server side rendering) for React is not a surprise. But, the hype I’m seeing around Vercel seemed almost greater than the hype for Next.js. Plus you don’t even have to use next.js, you can use vue, svelte, astro, etc. There’s actually many other tools out there for SSR.
What if you love Next.js but don’t want to run it on Vercel?
You can run next.js on your own lambdas if you choose, EC2, ECS, k8s, whatever. If you can containerize it you can ship it anywhere. Is next.js tightly coupled to Vercel? Yes. Will you face varying levels of difficulty setting that up? Yes, but you aren’t tied to Vercel if you don’t want to be.
So it seems to me that the actual platform, Vercel, is what is luring these founders in. I’m interested in understanding what Vercel offers them under the hood.
Isn’t Vercel just a wrapper around AWS products?
That’s what I thought for a long time, and while it does use AWS global infrastructure, it does more than that. I’ll explain.
Vercel solves some of the biggest limitations of AWS serverless infrastructure. Cloudfront functions have no async await and file limits for Node.js runtimes. Lambda functions have always required devs to solve issues with cold starts and often felt like they took forever to deploy (speaking from personal experience).
Vercel has a very smart (and proprietary) orchestration layer called Fluid Compute that operates as a functions router. Vercel’s edge network utilizes over a hundred PoPs in a multi-cloud env, from AWS to other commercial CDNs for static assets. They built a custom proxy mesh at the edge that reverse proxies to the Fluid Compute layer for AWS lambda executions that bypass the public internet entirely.
What is super interesting to see is how Vercel keeps their lambdas warm. Typically when you write a node.js workload you would execute it in AWS with a 1 request to 1 container inAWS’s own Firecracker VM. Vercel doesn’t dump your code directly into a lambda to run like this. Vercel has their own runtime engine inside the lambda that keeps a long lived connection open with its own function router. AWS is essentially tricked into keeping the container warm.
I am experienced with dealing with lambda’s shared timeout of 15 mins. Vercel gets around this by routing new traffic when it gets close to the timeout to a parallel execution.
For middleware they even ship in a lightweight v8 Javascript runtime on the edge to make them even faster. Their proprietary tech makes serverless workloads in Node.js execute at lightning speed.
Why are people using Vercel instead of running containerized apps?
It is kind of an obvious question, and a question I think a lot of people ask that aren’t familiar with the reasoning for using serverless (besides cost). Sure you can run an app in K8s but if you want to scale at the speed you need to for sudden traffic spikes, it takes a lot of configuration and overhead to prepare for that. For most typical setups, autoscaling may be set to a metric like CPU, a sudden spike can take a long time to spin up new pods/tasks and your app could be down. Of course there are ways to handle that such as predictive scaling and provisioned concurrency, but aren’t as simple as parallel lambdas automatically being spun up by Vercel.
So, for unexpected spikes of traffic Vercel has the competitive advantage (in a sense, but more on that later)
What problems are Vercel solving for solo founders?
Low Barrier of Entry
I’ve heard of people deploying a MVP within 10 minutes via a ‘git push’. I don’t think it gets better than that honestly for a solo founder building a MVP. As much as I’m tempted to hate on Vercel, you can’t really replicate that using home grown solutions in that sort of speed.
We all know that lean is always best when building a tech product. I don’t really need to explain agile or MVPs to most people in the tech industry. It is important not to spend too much time building the product in the beginning so you can get validation and feedback required to build a successful product. Vercel is therefore very good for A/B testing.
The Pains of Serverless
Lambdas initially were a huge lure for founders and companies for their cheapness and “ease of use”. The trade off for the cheapness of serverless was their overhead.
Lambdas are not exactly fun to maintain. Lambda layers are troublesome in CI/CD. There are cold starts (as discussed), resource exhaustion, throttling, difficult and slow deployment pipelines, cloudfront invalidations, IAM security, etc. Lambdas can’t serve HTTP traffic, so you have to figure that one out with API gateway, Cloudfront, etc
I worked with a CTO that told me that his biggest regret was choosing lambdas in the beginning of their product, because how difficult it is to maintain as your organization scales, how difficult it is to test, but that’s another story about managing technical debt.
Ease of Deployment
The CI/CD process for Vercel with Next.js is first class for GitHub with native monorepo support. It really is as simple as a git push. It also spins up immutable pre-prod environments.
And as an engineer spending what feels like years of my life in CI/CD pipelines, I can see how powerful this is for a founder or entrepreneur.
Low Initial Cost
There is an extremely low initial cost if you don’t have traffic, the devops cost is virtually 0.
It is going to be very hard do an apple-to-apple comparison between AWS native tools and Vercel Pro. We can try though. Let’s take a look at 1 million invocations in us-east-1 with x86 with the Vercel Pro equivalent, iad1, and assuming overages of the free 1 million invocations.
AWS Lambda (us-east-1)
- $0.20 per 1 million requests
- $0.06 per GB-hour (memory is proportional to CPU)
Vercel On-Demand (iad1)
- Invocation Fee: $0.60 per 1,000,000 requests
- Active CPU Rate: $0.128 per Active CPU-Hour
- Provisioned Memory Rate: $0.0106 per GB-Hour
So let’s do some thought experiments. A lightweight API endpoint with minimal CPU overhead and a low memory profile — 512 Mb of memory and 200ms execution at 1 million requests — Lambda comes out on top:
| AWS Lambda | Vercel Pro | |
|---|---|---|
| Invocations | $0.20 | $0.60 |
| Compute | $0.06/GB-hr = $1.33 | $0.128/Active CPU-hr + $0.0106/GB-hr = $7.40 |
| Total per 1M reqs | ~$1.53 | ~$8.00 |
Now let’s up the resource profile for a more standard example: SSR loading with 1024 Mb and 1000ms execution:
| AWS Lambda | Vercel Pro | |
|---|---|---|
| Invocations | $0.20 | $0.60 |
| Compute | $0.06/GB-hr = $13.33 | $0.128/Active CPU-hr + $0.0106/GB-hr = $38.50 |
| Total per 1M reqs | ~$13.53 | ~$39.10 |
As we said, memory is cheaper in Vercel Pro, so the gap between AWS Lambda and Vercel Pro gets smaller.
What about an AI agent or a heavy worker where you have to load large SDKs and dependencies into memory? These types of lambdas are both memory intensive and CPU heavy. I’ve used strands agents heavily in lambdas before for prior jobs, and they often spike CPU during orchestration and tool execution. But when it is waiting for the LLM (Bedrock to respond), this is an IO wait event, and CPU drops to zero.
The active CPU billing is a huge advantage to Vercel in situations like this. Let’s try 2047 Mb and 4000ms execution (very generous, IMHO):
| AWS Lambda | Vercel Pro | |
|---|---|---|
| Invocations | $0.20 | $0.60 |
| Compute | $0.06/GB-hr = $106.67 | $0.128/Active CPU-hr + $0.0106/GB-hr = $165.78 |
| Total per 1M reqs | ~$106.87 | ~$166.38 |
Now let’s up the resource profile for a more standard example: SSR loading with 1024 Mb and 1000ms execution:
| AWS Lambda | Vercel Pro | |
|---|---|---|
| Invocations | $0.20 | $0.60 |
| Compute | $0.06/GB-hr = $17.07 | $0.128/Active CPU-hr + $0.0106/GB-hr = $8.57 |
| Total per 1M reqs | ~$17.27 | ~$9.17 |
As we said, memory is cheaper in Vercel Pro, so the gap between AWS Lambda and Vercel Pro gets smaller.
What about an AI agent or a heavy worker where you have to load large SDKs and dependencies into memory? These types of lambdas are both memory intensive and CPU heavy. I’ve used strands agents heavily in lambdas before for prior jobs, and they often spike CPU during orchestration and tool execution. But when it is waiting for the LLM (Bedrock to respond), this is an IO wait event, and CPU drops to zero.
The active CPU billing is a huge advantage to Vercel in situations like this. Let’s try 2047 Mb and 4000ms execution (very generous, IMHO):
| AWS Lambda | Vercel Pro | |
|---|---|---|
| Invocations | $0.20 | $0.60 |
| Compute | $0.06/GB-hr = $136.47 | $0.128/Active CPU-hr + $0.0106/GB-hr = $45.86 |
| Total per 1M reqs | ~$136.67 | ~$46.46 |
Like I said, we just can’t just compare raw lambdas to just Vercel. CPU costs the most, but memory is cheap on Vercel per GB hour. It may be cheaper but Fluid Compute’s warm instances will cost more anyways because you have to account for the lifetime of it, not just the duration of the request which you would account for in lambdas. If there are multiple requests at once in lambdas they can be executed in the same firecracker vm and you are just charged for 1, but those would be multiple lambda executions.
If your app is spending a lot of time on IO (calling 3rd party apis, database queries, etc) then CPU billing is paused in Vercel.
Of course these were calculations for raw lambdas, there are other costs to run in native since lambdas don’t serve traffic alone. You have to take into account cloudfront distributions, API gateways ($3.50 per million). If your lambda is in a prod VPC then you need a NAT gateway to call external APIs. Also don’t forget those Cloudwatch logs. When you include all of this, Vercel looks extremely close in price.
If there is a commercial cliff for using Vercel, where is it?
As a solo founder it is hard to predict the future and how you will need to scale, and when. Vendor lock is a classic problem in the tech world, and this is no exception. Like most vendor locked tools, you reach a point where architectural limitations and cost limitations block you from scaling.
What’s the break-even point?
I’ve heard that around 2 Tb of bandwidth, AWS becomes much cheaper. Also AWS has more predictable spending limits when you start to manage your budget more closely as you scale (i.e., have a finops team)
AWS doesn’t have seat fees, so even as you scale as an org you will be paying extra spots just for seats (which may be peanuts to some companies, but still). There’s no reserved instances with Vercel unfortunately. There also comes a point where you may need to consider abandoning serverless architecture in favor of longer running architecture.
Some other caveats, if you need to migrate a region to somewhere else, the rates are much higher but AWS regional differences aren’t much closer in price to each other so it won’t be a surprise.
But often migration changes are necessary in tech. If you thought you were going to stay with the same architecture as when you built your MVP, you are in for a world of hurt.
The Vercel Decision Matrix
If I was evaluating using Vercel for my product, at any scale, I would ask the following questions:
| Question | → Vercel | → AWS / alternative |
|---|---|---|
| Am I heavily invested in Next.js? | If yes, Vercel makes life way easier | Otherwise, AWS |
| Is my product B2B SaaS behind auth or B2C? | B2C needs SEO and SSR | B2B SaaS doesn’t need Vercel, use AWS |
| Is my traffic spike bursty or sustained? | Bursty is better for Vercel | Sustained is better for ECS |
| Do I need serverless in the first place? | Yes → Vercel maybe | No → cheaper/simpler |
| Can I afford to lose a week of dev velocity to manage infra? | If no, use Vercel | If yes, choose AWS |
| Can I tolerate a surprise bill of >$1k? | If yes, Vercel works | If no, AWS has budget automation, Vercel only has alerts |
| Is my monthly Vercel bill approaching $1k? | — | Egress costs of AWS start to make more sense |
| Do I need VPC isolation? | Vercel for static IPs | AWS for VPC isolation (Enterprise is expensive) |
| Will my team scale past 10 developers? | Otherwise, Vercel | If yes, AWS (no seat fee) |
Final Thoughts
Obviously there is a lot to unpack here and I feel like I barely scratched the surface of what Vercel offers when it comes to their full product offering. It is hard to challenge an honestly fantastic product that empowers developers to build and test their MVP in the real world that quickly. I think that is completely admirable and their active CPU billing is pretty awesome.
For myself, I would be very challenged to use Vercel considering I have the infrastructure knowledge I need to deploy apps. I personally am a big IaC user (terraform) so a lot of this infra doesn’t take too long to set up. But I understand how the “devops” opportunity tax for people that are seasoned with Vercel would push someone in that direction. For myself, I’m not building products that use SSR heavily at the moment that are heavily based on SEO. I don’t like the idea of getting a surprise bill, but even AWS doesn’t even guarantee that you won’t get one (looking at you NAT gateways and forgotten RDS snapshots).
Managing this type of complexity is my bread and butter and I prefer having more control on how infra is deployed so I can easily (or not so easily) pivot to the right architecture for the situation if I need to.
If you don’t have the time to set up an AWS account, deal with everything on the frontend infra side of the SDLC, CI/CD, use Vercel. If you choose to stay with Vercel as you scale, you will likely be paying more than AWS but of course this is completely subjective. Sometimes these tools are worth the price if you can scale revenue. If the opportunity cost is too high to manage the frontend infra yourself, Vercel is where you should be.
I think even a hybrid solution could be interesting. For most scenarios, I feel that Vercel could potentially be enough, except for of course the edge cases that tend to ruin our days as engineers.
Ultimately for me it comes down to control over convenience, and I prefer the former. But I can’t say that Vercel isn’t tempting.