Vercel is just a layer on top of AWS, and they charge 100-200% more than what AWS charges. So, why do people pay for it when they can use AWS directly?
The snarky answer is that it's easier to be a full stack developer if your stack starts and ends with JavaScript. It's also the real answer - most webapps create value in the instant of views or clicks, so being charged solely on those metrics (even 200%) can make a certain amount of business sense, and if your business doesn't have need for redundant data stores or major backend services, you can get a lot of mileage out of a vercel based infrastructure.
I personally can't stand it, and actively work to excise it from front-end applications though _because_ it's difficult to work with it as a 'part' of your world. Like a lot of dev-experiential products/business models, their moat only exists if they can keep you "in" vercel, the moment they become just nodejs + lambda to a customer, then their value-add ceases; So they make it difficult to "grow up" out of vercel -- for many shops that's fine, it will be all they need from it, so a premium for a polished nodejs+lambda+deployment+cdn experience is worth it.
But if you're a micro-arch with backend services running on your own cloud, vercel will always be the wart in your infrastructure making everything from network policy to authentication and monitoring or tracing more difficult.
> The snarky answer is that it's easier to be a full stack developer if your stack starts and ends with JavaScript.
That doesn't need to be snarky. I know JavaScript and a variety of other languages, but if I'm picking a stack to work on the whole of, it's going to be a whole lot less context switching to use one language throughout, so JavaScript (in fact, TypeScript) it generally is.
I find C# and TS to largely be "congruent" and rather easy to switch between [0].
I think the biggest "growing pain" is that C# runtime is multi-threaded so devs that are used to single-threaded Node.js environment need to understand object lifetimes. (Of course there are other differences as well, but the biggest IMO is understanding threading and object lifecycles in the underlying runtime.)
Syntactically identical promises/futures; syntactically identical lambdas; largely congruent tuples, classes, interfaces, generics, anonymous objects. C# 13 collection initializers are going to largely feel like JS array initializers.
Minor syntax differences can be picked up quickly. Frameworks like Nest.js are super similar to .NET Web API.
My biggest hurdle when trying C# (along with a very select few other languages) is that it’s very difficult to get working properly in my own environment.
I use an apple computer and prefer to write my code in a simple text editor. Getting C# (or god forbid C++) just running in such a way that I can just focus on the code and not the surrounding environment or build tools took me long enough the last time I tried, that I decided to just not use C#.
When was the last time you tried C#? These days, it's as simple as getting dotnet and executing "dotnet new <template> -o MyNewProject" to make a new project. Then "dotnet run" or "dotnet watch". Also, the VSCode extension (with C# Dev Kit) is pretty good nowadays compared to other languages (I personally find it as good as rust-analyzer), but certainly not as good as Rider for enterprises; I mainly use VSCode in fact.
brew install dotnet-sdk
dotnet new console -o ConsoleApp --aot
cd ConsoleApp
dotnet publish -o .
./ConsoleApp
(it may take extra time for bulding it for the first time, particularly pulling in IL Compiler dependency, but all subsequent compilations will be fast)
Feel free to comment out `PublishAot` property in .csproj file if you don't want AOT (i.e. using libraries that want JIT), or use dotnet watch and run commands for quick iteration.
Note that for rich editing experience you do not need C# Dev Kit (which requires an account), only a baseline C# extension which has all the good bits. For running and debugging the project out of VS Code - upon first F5 press it will suggest generating config assets for .NET project it managed to find in an opened folder - just agree and it will work on the next F5 press.
The reduced type of complexity is operational complexity, the need to at least have surface understanding of how to integrate/use a CDN, deployment tooling etc.
Lets say you have an idea and want to make money from it. Does it make sense to spend weeks trying to get your infrastructure right vs. just start solving your problem domain? In a lot of cases it's worth the extra cost just to have something up and running quickly. Iterating over your software instead of your infrastructure.
It's the same for a lot of similar things, Deno land, cloudflare workers/pages, etc. Things that reduce the friction to get something running online can be beneficial. They all have practical offsets and negatives too.
It's not a bad decision so much as a decision of where you derive value, and how much.
Sooooo we're an agency specialized in Next.js stuff.
We're essentially a bunch of passionate engineers but none of us care for ops work including myself, I really want to focus on the code, not on the deployments.
Vercel actually kind of saves us money because the apps we work on are mostly internal tools that don't have millions of requests per minute and developer time is expensive. If vercel saves us one hour of engineering work per month compared to aws it's already cheaper and it definitely saves more than one.
This aligns with my own experience. I do deep backend systems stuff in my day job (just bringing this up to refute the whole "people just don't want to learn Linux" thing, I've even done kernel and eBPF work in the past and can still see value in Vercel), but still support some mostly front end Next.js apps for some small clients from back when I was freelancing.
The vercel ecosystem is perfect for that kind of work. I don't want to (and probably don't have the time) to be managing a bunch of cloud infrastructure for several varied small businesses outside of my day job. I need something where I get a call, go in and make a change, send them a nice preview link to preview the change, then deploy. Vercel makes that kind of business very easy to manage for me, and realistically none of these clients have the kind of traffic where a 100% price difference over managing it yourself would be saving them a lot of money or have a material impact on their finances or my pricing.
My clients get more value from retaining my services this way because I have more free time to help them make actual changes, and less time taken up managing their infra, which they wouldn't see and wouldn't understand and shouldn't have to care about. They pay me a pretty average to below average web guy amount to be their "web guy", not their "server/cloud guy".
If I switched from Vercel and started managing it all myself in AWS or Hetzner or something and trying to pinch pennies, I probably wouldn't be able to substantially lower my prices (time opportunity cost), but I WOULD probably have to drop some clients that have been with me a long time and that I feel some responsibility for.
Things like web scrapers and lots of nodejs bits get caught out by the Vercel limits (like mb of RAM) don't they though? Or is that a thing of the past now?
I say this because, I develop moderately complex applications. We just always end up with some level of server side functionality, and even though Next.js is beautiful, the prevalence of these issues lead up to us self hosting. We do incur occasional issues scaling up, but so far, and despite intense applications with 5 figures of users, had had no issues with single/dual instance set ups. Any running a dockerized next.js application with auto restart is very easy for us.
I emphasize a lot with you - I too hate dev ops. But I suppose that comes from once spending 10 days migrating a service from VPS to AWS (back in the 10s mind - it would be easier now due to the standardization of environments)
But as to next.js features which can be caught out by the vercel resource limits - Do you not encounter those limitations, or do you work around them?
Check out Google Cloud Run and Azure Container Apps for backends.
These have really generous free tiers. 180,000 vCPU seconds/mo, 360,000 GiB seconds/mo, 2m requests/mo. Resets each month.
The trick is that they scale to 0. So you can run a pretty sizable indie project/low volume internal tools for free. I run a bunch of stuff on GCR this way.
i've a script kiddie at best with a lot of half baked projects. I don't want to learn anything about platform / infra / aws. I want to get up into prod as quick as possible and I am finding it super easy with Vercel and Supabase.
Sandwhich shop is just a layer on top of the Grocers, and they charge 100-200% more. So, why do people pay for it when they can use the Grocers directly?
In infra case there is ton of marketing and momentum pushing people to not do their own. Sandwich case is not really similar in this aspect imo, generally it is more of a bragging point to make your own healthy sandwiches.
For example renting bunch of bare metal machines and running rke kubernetes implementation is orders of magnitude cheaper compared to using aws kubernetes, food has very low margins comparatively.
I don’t see how bare metal is order of magnitude cheaper. ECS + EC2 would be 2x maybe 3x more expensive than bare metal. Add auto-scaling and tooling (VPC, CF, terraform, Systems Manager, etc) and difference can be zero if not negative.
I have to buy a whole roast chicken just to make one sandwich, and I don't have a sandwich press at home so now I've got to spend $30 on one of them too.
As someone who does NOT know infra, I used to run things on Heroku, but since it's not improved in a decade while getting more expensive at the same time, and I had over a dozen personal projects there, I decided to move things out. It was also a good chance to get better at devops stuff!
The ROI so far from a "financial" point of view has been terrible, I've spent probably close to 40-60 hours just to set up things and it's still held by stitches. My apps go down from time to time, deploying takes 5x the time and each new website/app I try to migrate is 1~3h from beginning to end vs a few minutes it'd be in Heroku.
I started with DigitalOcean+Dokku, but I'm thinking about investing another 20~50h and learn Coolify, I have only heard amazing things on Twitter (my main concern is that it's "the new cool kid in the block" and maybe not as good as people make it seem).
Edit: the ROI of learning new things has been amazing though, I wish I had done this earlier.
Vercel has hired many key figures in the Javascript space such as Rich Harris and pays talking head Dev YouTubers willing to accept undisclosed sponsorships. That's why you'll see NextJS videos routinely get millions of views, and channels that solely shill NextJS.
If the site has no users and it's just you, it's like $20/mo.
If you have enough traffic that your bill is > $1,000, put some time into switching.
But I can have my entire site deployed with CI/CD on Github to Vercel in less than an hour. If I'm doing client work, my clients can go preview new work immediately. I can test and build deployments on different branches and send test builds to stakeholders. It's got a lot to like and it ends up saving you a lot of money.
What is right for just starting out is rarely right for scaling up. Too many people wasting too much time on AWS instead of shipping their app first.
Ansible and Hetzner may cost 3$ a month, but it also costs several hours of dev time to set up and probably a few hours per year to keep up with certificate renewal, domain name renewal, maybe doing some package upgrades in response to newly discovered CVEs (that you ARE checking regularly, right? RIGHT?), etc.
If your time is free, great. If you REALLY like ansible and want to do it at a discounted rate, also fine. But for most people and companies, dev time comes at a rate of ~50$ per hour. For that amount of hours you don't even get scalability, documentation, failover and a host of other things that Vercel provides.
This seems like a good trade compared to wasting hundreds of hours on a failed migration because Vercel decided beta features are ready for production.
Not to mention you’re learning transferable skills and not a proprietary stack from a company that may not exist in ten years.
Why would you waste hundreds of hours migrating to a setup that takes at most 10 to create? And if your team is indeed incompetent enough that it takes them hundreds of hours to migrate away from Vercel, what makes you think they can successfully manage a bare metal setup on Hetzner without shitting the bed sooner or later?
Also Ansible was quite hip 10 years ago but I'd hardly call it a transferable skill anymore. Most shops seem to have migrated away from it already.
Which costs even more dev time (and thus more money) to build, especially if you want the automation to be dependable enough that it can run without constant monitoring. Again, fine if you are doing it as a hobby and your time is free but a very questionable use of your time if it costs any normal amount of money.
This comes down to a skill issue. Not as in “you don’t have the innate skill to do this,” but as in “you haven’t learned the skill such that it doesn’t take forever to do.”
If you want to fork money over to Vercel every month, fine, but assume that this can’t be done reliably and safely while also not taking forever. Did I invest a lot of time in the past learning and honing these skills? Of course. Now they’re useful for something beyond a hobby.
I’ve found that a lot of developers would rather not have to think about where their application is going to run. This is a real shame, especially when there are free tools like SST that bridge the DevOps gap, making things like AWS and IAM less of a pain.
Even better, there are complete self-hostable platform solutions like Supabase or the classic Docker Compose. However, the shared downside with these solutions is that they require some setup when it comes to deploying, unlike the magic of Vercel.
I do wonder when we started losing interest about where our code is actually being executed ?
> when we started losing interest about where our code is actually being executed
I don't think we did - it's more that new programmers aren't forced to learn it, and a lot of them are lazy and only here for the money. The result is a lot of people who think all that matters is shipping quickly. To them, it doesn't matter that this will result in lots more work down the road once the product needs to scale up.
Not scaling up until needed is a fine strategy. Most products fail, so they don't ever need to scale up and spending the engineering hours to make it bulletproof is literally wasted effort. Wasting time and money at the start of a companies lifetime makes it more likely the business will go up in the first place. If you need to scale up, you will have lots more revenue to pay for that work than you do at the beginning.
As someone outside the ecosystem it is bananas to me. My only exposure to Vercel is endless crypto fake airdrop scams hosted on their free tier. They need to stop hosting their free tier on their main trademark (subdomain of vercel.app), or hire a real trust and safety team, because their brand is rock bottom for me after seeing it used for so many scams. If I see anything visibly hosted on Vercel I immediately assume it is a scam
Services like Vercel are the result of decades of ignorance/resistance against learning basic Linux Skills. Yes, they provide convenience but we have gone too far off in the other direction in the last decade or so. No one needs to host bare metal servers in their own basement but most people also don't need to use AWS let alone Vercel etc that are another wrapper/layer and charge excessively.
The balanced approach is to learn basics of Linux, get a decent VPS or even a dedicated server (rented) and setup the stack. Plenty of documentation everywhere. Just ensure that you have good backups running.
And no, most people don't need complex setup or expensive hosting. We just choose to do so because either it is the cool thing to do OR we don't know any better.
I'm frequently surprised by how little most software engineers know about IT, infrastructure, or hardware. The floor for basic familiarity outside of support is shockingly low.
I started as a BSD/Linux systems programmer / sysadmin, which required a working knowledge of infrastructure. Lack of ubiquitous resources meant higher stakes for correctness of work for the "whole stack". Now, there are as many abstraction and translation layers between the "code" and the hardware as people can come up with, despite there being excellent native tools (albeit, not sold by a vendor).
It's not worse or wrong, as long as you can afford it, but despite working on PaaS and IaaS up until a few years ago, I still don't understand why so many seem allergic to fundamental auxiliary skill sets like administration.
Devil's Advocate answer... why should someone creating a web based application ui care about the underlying operating system it's running on? I daily drive Linux personally, but TBH, for the most part, I don't care about a lot of the underlying details when working on a project, and I do care more than most.
Even for stuff I deploy, my preference is a pretty bare host OS, and just using Caddy + Docker to deploy and reverse-proxy applications. It works fine at the small scale, and you can vertically scale a lot. But I'm not sure I would take that approach for a lot of various applications. It really just depends.
No one is saying don't use these expensive services. My argument is that most applications don't need them and people do it anyway. It works well for a while and then suddenly you get an email saying your bill is going up 1000%.
If you have a hammer, everything looks like a nail. Vercel type services are not necessarily the right answer in many cases just because it is easy to start with.
Most applications don't need more than them either. It's also easy enough to migrate off to self-hosted docker behind a load balancer if you need that as a stop-gap.
I have to agree... I really find it hard to believe that AWS themselves haven't invested more into creating a similar UX in house.
I do hope that the likes of Vercel, AWS Lambda, Cloudflare Workers and others start to align more from a developer perspective. I know hono.dev has worked to smooth over some of the edges a bit.
I'm also hoping to see similar efforts for other developer toolkits, I know there's several out there, but nice to see all the same. I think there may be some strides with WASM in the future too. shuttle.rs definitely looks interesting.
Strong "Dropbox is just FTP/rsync, who would need that" vibes.
Look, I'm an SRE by heart and mind. I love tinkering with Linux, have around 10 different physical boxes (mostly Pi/NUC sized) running various distros for the fun of it.
Just because I want to and can doesn't mean everyone should DIY everything. For a random developer working on a business thing, or a side project, any time not spent developing is a time that doesn't bring any value - it doesn't help them advance on their work.
Managing a VPS is not trivial. Yeah, maybe you can get away with unattended upgrades and FTPing PHP files to it, if you're lucky. If you're not you'll pick the wrong VPS provider whose datacenter will go up in flames. Hope you remembered to do backups of everything.
Many tutorials/docs, and hell, whole pieces of software are "now draw the rest of the owl" style, with terrible security and reliability defaults. You cannot expect a random developer to be aware of the intricacies of what it means to not bind to localhost only (reminder that e.g. MongoDB used to by default to bind to all interfaces, and start without a password, so you got an insecure unauthenticated DB on the internet by default; another reminder that Docker automatically port forwards all your Docker containers' exposed ports to all networks, so same thing).
Yeah, it's not that hard, but you need a ton of knowledge to know how not hard it is, and even then there are caveats and tricks depending on a ton of things.
> but most people also don't need to use AWS ... that are another wrapper/layer and charge excessively
Yeah, this is bullshit. Yes, AWS is a wrapper around infrastructure, but unless your needs start and end with "VM with storage and a network", having pretty much any piece of software you can desire available at an API call with a clear billing structure is pure magic. How long will it take you to set up a a reliable object store? Message broker? Trace storage? PostgreSQL? All reliable, backed up, regularly updated, properly monitored. How much time will you spend in maintenance on all of those? A random small project probably doesn't need all of those, but arguing "most people" don't need AWS is like arguing "most people" don't need fancy high level languages which are just wrappers and should just code everything in assembly.
I know my comment has that vibe and I get it. But I still am going to stick to the fact that infra is not the boogeyman that companies like Vercel etc want us to believe. Not saying they don't have a purpose but they are not the default answer in many cases. There has to be a middle ground if you don't want to be held hostage if these companies suddenly spike your price by 1000% (and they do).
If people want to run Next.js for some reason, especially with react server components, then there is plenty of complexity that Vercel handles. For example, the version mismatch between the long-living client in the user's browser, and the server that is updated any time new changes are pushed. Vercel calls it the skew, and helps with it by keeping old servers alive for a while, and routing traffic to them from appropriately old clients. One would have to architect something similar on his own on AWS if he chose a similar tech stack.
I have a UI app with a backend API server. Sometimes I want clients to update their UI to get new features (UI payload is cached in the browser)
I have a version in the UI and the backend. If the UI is on an older version then I can either force reload the client or display a prompt to the user saying there's a new version of the app.
As a www user who does not run Javascript, the only delay I experience when accessing web sites, if any, is connection and retrieval (download) of the page. There is no "loading". With the client I use, there is no auto-loading of resources. No images. No CSS.
The Vercel sites on 76.76.21.0/24 IP addresses seem faster to me than many other sites submitted to HN.
If a site is particularly fast to connect, I will sometimes check to see what CDN/hosting it is using. I have done this with several sites that turned out to be using Vercel.
AWS is just a layer on top of bare-metal, and charges similar markup. Businesses pay for convenience. Vercel is much more convenient than AWS, if your problem space fits inside Vercel. If you're (for example) a physical toy company and you just need some product marketing pages, Vercel seems like an amazing fit.
You aren't just paying for convenience, you're paying for dynamic scalability. With the likes of AWS (and Vercel for that niche) you can stand up and tear down network, compute, and storage without having to own, host and manage the underlying physical infrastructure.
Yes, if you really want to save cost and forgo the convenience, bare-metal is also available on-demand, but you're going to end up building and managing your own subset of AWS on top of it, and that itself comes with a cost.
Yup. The reason businesses are willing to pay for convenience is because otherwise they'll have to hire someone to do the job (or reallocate someone from other work to do the job); they're paying in money or opportunity cost regardless.
The fact I can just run `vercel` on many frontend projects, and it just works without having to think about iam, policies, service accounts, s3 configuration, cloudfront.
Time is money, and sure, once you reach some scale it will be efficient to move stuff to AWS, but for most projects it is not.
> on many frontend projects, and it just works without having to think about iam, policies, service accounts, s3 configuration, cloudfront.
Sure, but if you're going to use it on "many" projects, then just learning these things once and building an appropriate abstraction layer for them pays for itself very quickly.
The premium for the "vercel flavored" wrapper around these necessary components is way too high.
If your plan is for none of them to /ever/ make money, then this is logical. If your hope is that one of them somehow does make money, you'll probably want your code to be flexible enough to be moved to a platform that won't destroy your profit margin over pay-as-you-go billing. At which point, the investment of effort will have paid for itself.
There's the problems you currently have, then there's the problems you want to have.
I just migrated our app from Vercel to AWS Amplify.
We’re updating everything to use SSO so we can do BeyondCorp-style auth on SaaS platforms. Vercel wanted to charge >$10k / year to get on their enterprise plan for SAML access, vs bill prior to that was ~$2.5k / year. The migration took ~30 mins and we expect our bill to drop to $500 / year. the toughest part was making sure we didn’t miss any build variables / secrets.
Is this as cheap as running base metal? No. But 30 mins to save $10k / year was worth it. And maybe the bigger point: what value are they really adding if it’s this easy to migrate off?
Would never consider the Vercel tax, we're hosting our new .NET Apps on Hetzner Could as that was the best value Hosting Provider we evaluated [1].
We can fit close to 40 .NET Docker Apps on a single 2vCPU/8GB RAM/20TB Bandwidth Server for €14.40/mo, which works out around $0.40/mo per .NET App. After a one-time setup to install Docker compose lets us deploy new .NET Apps by publishing to a new GitHub Repo and setting a few GitHub Action Variables.
Since we use SQLite and litestream.io for streaming replication to R2 we also avoid any expensive managed DB hosting costs.
We've also deployed a hono.dev/TypeScript/React/JSX Web App with Cloudflare Workers which at ~60k reqs/day fits within Cloudflare's 100k/day free quota so doesn't cost us anything yet. It's a pretty nice managed dev UX that I'd use again for any future (non .NET) Apps we want publicly accessible from the Internet.
It's surprising how many people seem to be happy to eat these kinds of charges just to avoid having to actually understand the infrastructure they run on.
Even AWS can be pretty expensive compared to other hosts, when most of the services are just amazon versions of readily available tools like Postgres or RabbitMQ that you could install on any cheap linux VPS and save a chunk of change. You just might have to learn a bit of linux sysadmin instead of stacking a teetering jenga tower of "abstraction".
This is an amazingly steep hill to climb for someone with absolutely no server admin experience, someone who used terminal all their life to just paste in curl commands from tutorials to pipe in bash install scripts and run npm. I think we come from a time where tech circle was smaller and people covered more fronts, nowadays with YouTube attention economy the circle is very large and fragmented with people becoming good at a subset of stuff and being totally oblivious to the other parts, like server admin.
Eh, not really. You can literally ask Claude how to do this and do it from zero to working within an hour. Sure, if you're building a massively scalable solution running in multi regions with serverless and non-serverless, k8s, and RabbitMQ, sure that's hard. But half the people in these comments are running basic front-end apps with zero need for anything more complex than a small server somewhere.
Also, the truth is, for most small businesses, they don't need half the shit they are paying Vercel for. Most small businesses barely have any traffic so they're paying Vercel for a worldwide CDN and caching etc when a single AWS-micro instance in a single region would be fine, and setting up a single instance in AWS doesn't need complex server admin experience.
> like Postgres or RabbitMQ that you could install on any cheap linux VPS and save a chunk of change
Spoken like either someone who has never ran those at scale, properly available, or has for so long they've forgotten how much they've learned along the way.
I’m really curious about the percentage of total software projects that have real scalability concerns.
The majority of my career has been working on products that barely get 100k monthly active users. These projects don’t really need to worry about scalability because it’ll never happen. It hasn’t happened in the last 30 years, unlikely to happen in the next two years.
With that in mind why spend so much resources on complexity where the only benefits are to the engineers that get to add another buzz word to their resume?
I’m guessing the total percentage is less than 5, probably 1% seeing how Wordpress is still the most used framework on the internet.
I’ve worked at companies that cared about complexity and it was baked into the code. After the product was released we only got 500 users when the initial projection was 10,000 (this was a company selling Medicare advantage plans). The org was eventually disbanded.
We probably spent $20 million in additional “engineering” effort that was never used.
At some point you have to question why things are done a certain way if there aren’t material benefits.
100k monthly active users can result in wildly different numbers of queries/requests/operations depending on what you're doing.
100k MAU for a static blog and 100k MAU for an online game simulating a real world economy will have vastly different usage patterns of the underlying databases/message queues/etc.
> With that in mind why spend so much resources on complexity where the only benefits are to the engineers that get to add another buzz word to their resume?
It's not the only benefits, it's making things potentially easier down the line; more often than not it can be premature optimisation (preparing for a future that never comes), but there are also plenty of examples of companies outgrowing their initial infrastructure and having to spend lots of time on rearchitecting everything. A lot of that time can be saved by thinking a little bit beforehand and making things theoretically scalable.
I really disagree on making things "easier," that's kinda my point. Forcing in solutions that work at Google or Facebook or Twitter into an experience that gets 0.01% of the traffic is bad engineering IMO.
This example of a 100k MAU was for a company that was 150+ years old. They know their customers, they know the business, they know the growth projections. The only people that didn't know this was the technology leadership team that was given a blank check to "modernize" while all it did was create a clusterfuck of services using technology that requires even more workers to maintain rather than going for pragmatic solutions.
I completely reject the notion that you think every project requires "thinking" as if workers there don't actually know what the business entails or what future growth projections were (hint, they haven't been changing much for nearly 70 years).
You don't need fancy bleeding edge solutions for 99% of businesses out there. You engineer for what you have, not what you want.
It makes sense from a financial perspective for a small company that’s trying to grow. The most precious resource at such a company is engineering time. It’s very limited - you only have X number of engineers, it’s hard to hire good engineers, and they’ll only work so much. Engineers create the thing that makes money and they are in the critical path for nearly every single product experiment that a growing startup needs to perform to figure out its PMF. So nearly all of the small startup’s engineering time should be spent on things that differentiate its product, not stuff like serving frontend code, which is a solved problem. Traditional VC-funded startup economics assumes exponential growth after PMF, which means that engineering work required to reach PMF has potentially compounding returns.
Engineers know this too, which is why they choose Vercel over rolling their own infra. Frontend engineers get paid for building nice UXs that people will pay for, not mechanically implementing routing policies. So they’ll outsource that work to Vercel. It’s similar for backend engineers. What compounds this effect is that, at a small startup, you are on call in perpetuity. So you need to aggressively farm out support work for nonessential systems to service providers or else you risk being overwhelmed.
As programmers I think its hard to understand why others buy what we would sometimes build. But you all deeply underestimate yourselves! I'm also guilty of this as well. It is expensive to a business to do all those steps, to say nothing about the expertise to know what steps to take! For early-stage companies it makes sense to offload these tasks to tools, but as your company grows the cost-calculus shifts in favor of bringing the expertise in-house.
To take several numbers and examples from other threads, if you simply train on a technology for a week (40 hours) at $50/hour (@ $100,000 TC), that's $2000 for that week. Compare and contrast to some of the services ($1,200/year, $10K/year for SAML, etc) and you can begin to see the order(s) of magnitude difference between these "expensive" tools compared to a relatively "inexpensive" developer. From a business perspective, it can be a better ROI to have your developers work on products and buy the Operations.
Convenience and abstraction, it's a tradeoff between handling servers yourself and effectively outsourcing it. On top of this vercel also has some convenient tools for deploying websites.
You will likely find that it targets a similar audience as heroku et al.
Vercel did a great job on onboarding for more junior developers, and its a great place to start a project.
- Near instant Git deploys with links for each deployment
- Really easy to setup templates with "Deploy with Vercel" deeplinks
- Easy to setup web framework that works seamlessly with the platform
- All the add you need as your app grows (and yes, some you probably don't)
Once you're on its a pain to switch so its easy to stay on, so that's why so many people just continue.
If you liked Rails convention over configuration, you will likely appreciate Vercel. The only issue IMO is the full stack JS/TS approach. The JS ecosystem can be, let's just say, tough to navigate sometimes :)
in as much as I dislike or hate the "enterprise" frameworks like next etc. I think vercel brings value to teams that say are collaborating with design, product etc ... since you can immediately have hot deploy many versions of the same site at once etc ... without doing a lot of mechanics in terms of infrastructure. that's way cheaper than hiring an engineer.
but if you're in the stick to simple stuff - and not into the optimizing clicks business - deploying to cloudflare pages or just vps or cdn isn't much of a hustle.
VPS is just a layer on top of physically maintaining servers. That doesn't mean anything. People are paying for convenience.
Using a Platform as a Service (PaaS) is a much better experience over using cloud service providers like AWS. The amount of premium that one pays for using the former and whether it's justified is a separate discussion.
Have you used vercel before? It's a lot more than just a layer on AWS. They really understand specifically what Front end engineers need to be productive with their external stakeholders (ie: design, product, etc). I'm sure other products do this now but they were, as far as I know, the first to automatically deploy a version of your app by PR, for example.
Can you do this yourself? Yeah, obviously. But it's a build vs buy conversation and for a lot of people the value that this tooling gives you immediately is worth the buy.
Their website with pricing plan crashes shortly after opening in Firefox with "Application error: a client-side exception". Yes a static website crashes in web browser on a PC in 2024. I guess this solves the problem entirely.
I personally can't stand it, and actively work to excise it from front-end applications though _because_ it's difficult to work with it as a 'part' of your world. Like a lot of dev-experiential products/business models, their moat only exists if they can keep you "in" vercel, the moment they become just nodejs + lambda to a customer, then their value-add ceases; So they make it difficult to "grow up" out of vercel -- for many shops that's fine, it will be all they need from it, so a premium for a polished nodejs+lambda+deployment+cdn experience is worth it.
But if you're a micro-arch with backend services running on your own cloud, vercel will always be the wart in your infrastructure making everything from network policy to authentication and monitoring or tracing more difficult.