Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vercel Service Markup

service-markup.vercel.app

Post reply on HN
Print view View original

61–70 of 109 posts

Re: Vercel Service Markup

#61

Post by zamnos »

dmw_ng wrote: post #10

A while back I tried to reproduce a Vercel enterprise invoice using logs generated by an external service. After multiple round-trips with their support team I concluded it is actually impossible to verify what was billed even remotely reflected actual usage. It's essentially an AWS reseller in the form of a random number generator attached to some horrific contemporary JS, that the brand is so popular speaks more to…

Is it their random number generator or are the reselling that off AWS as well? Because have you tried to navigate AWS billing?

Re: Vercel Service Markup

#63

Post by jrudolph »

brundolf wrote: post #50
jrudolph wrote: post #38

The appeal of a no-ops workflow for basic frontend apps is there. We’ve got a bunch of static docs sites built with vuepress and docusaurus that are a great fit for this. Not that we can’t whip up a CDN with terraform and a CI/CD pipeline with preview environments, but my team would rather spend its energy on our core product. However we’ve been badly burned by vercel, netlify and render.com switching their pricing m…

I've been wondering what the limits of the user-based pricing actually are If it's just the number of people who can go in the UI and press the button (when it automatically gets deployed from git anyway), or change env secrets, can't you just have a single admin account and call it "one user"? That could be a single actual person (how often do you change those things?) or could even be a single account shared by the…

On netlify iirc pricing was for every git committer that was allowed to trigger a deploy.

Render.com was more lenient in a model like you describe but still we have different people manage different apps and it adds up.

Re: Vercel Service Markup

#64

Post by jrudolph »

chrisco255 wrote: post #40
jrudolph wrote: post #38

The appeal of a no-ops workflow for basic frontend apps is there. We’ve got a bunch of static docs sites built with vuepress and docusaurus that are a great fit for this. Not that we can’t whip up a CDN with terraform and a CI/CD pipeline with preview environments, but my team would rather spend its energy on our core product. However we’ve been badly burned by vercel, netlify and render.com switching their pricing m…

Amplify is the most vendor-specific locked in stack you could possibly choose. If you don't want to be burned by vendors changing the pricing model on you, don't choose a proprietary stack to build on.

I’m pretty confident of all the players in that market AWS is the least likely to pull that move.

Re: Vercel Service Markup

#66

Post by howon92 »

This is a good chart. But I’d argue using Vercel is entirely justified for many indie devs or startups. I bet most won’t get to the point where the extra cost of using Vercel really hurts. If someone is lucky to get there, they can just switch to using Upstash / Neon if they feel the benefits of Vercel’s extra layer don’t outweigh the added costs.

Re: Vercel Service Markup

#67

Post by manmal »

PKop wrote: post #56
egeozcan wrote: post #37

Earlier quoted context omitted.

> Everyone else should be preparing their plan b for what happens if they impode and Next.js, Turborepo etc development fractures or grinds to a halt. Isn't next.js too big to fail? Currently we are trying to define a modern stack for our front-end, and I always thought next.js/react to be the next java -> Perhaps Solid.js is much better (IMHO it surely is) but I probably won't get fired for choosing next. If not, wh…

Phoenix LiveView and Elixir and just run it on a server, like Fly.io

Is better tooling support for Elixir on the horizon? I’ve found eg VSCode code completion leaving something to be desired. With TS, I feel like IDEs have my back, but with Elixir I (as a newbie) keep getting stuck. There’s also a lack of readymade idiomatic solutions to common problems out there, requiring me to browse the Elixir forum a lot.

Re: Vercel Service Markup

#68

Post by the_mitsuhiko »

chrisco255 wrote: post #39
egeozcan wrote: post #37

Earlier quoted context omitted.

> Everyone else should be preparing their plan b for what happens if they impode and Next.js, Turborepo etc development fractures or grinds to a halt. Isn't next.js too big to fail? Currently we are trying to define a modern stack for our front-end, and I always thought next.js/react to be the next java -> Perhaps Solid.js is much better (IMHO it surely is) but I probably won't get fired for choosing next. If not, wh…

Next.js is open source, forkable, and self deployable.

Next.js promotes serverless deployments and in that scenario it’s not sufficiently Open Source. Vercel (or amplify) adds proprietary stuff that’s missing in next itself. There is an Open Source serverless implementation for aws lambda (open next), but it’s not official.

Re: Vercel Service Markup

#70

Post by paxys »

CharlesW wrote: post #27

This is really interesting, kudos to the creator! My only note is that Vercel is probably paying less than you and me, in which case the spread is a bit greater than the "vs. retail" comparison. As I type this the responses are mostly negative, so to balance that I'd like to point out that (1) integration is often undervalued, and (2) nothing prevents developers from using the other services directly, or even creatin…

The point isn't to care about what Vercel is paying but what you the end user are paying/saving when using the two services being compared.
Post reply on HN